QRadar backup is one of the most important feature to use by each system administrator. There are two types of backups – configuration backup and data backup. It is highly recommended to do backups on regular basis and by default, QRadar creates a backup nightly but you can reschedule and adjust it to your needs.
Default settings
By default, automatic data backups run at midnight and will contain logs and flows archived in the earlier 24 hours in the QRadar event database. If the data backup is cancelled or fails, the process backs up only data that was stored after the last backup ran. While you can back up the event and flow data using the Backup and Recovery feature, you must restore the data manually.
If you want run your QRadar Backup, navigate to the Admin tab in the System Configuration section. Choose the Backup Archives window, and select option to manage Backup and Recovery:
On-demand Backup. This kind of backup saves only QRadar settings including asset and offense data. It is like database dump but apart from settings stored in the QRadar PostgreSQL it also includes more files, which are listed below. The Name for the backup you can set up to 100 characters long. For the name use only letters, numbers, underscores, dashes, or periods. After start you can watch the process of backup on displayed progress bar. On finish newly created backup, appears in the Existing Backups list. The following files are included in package with PostgreSQL database dump:
/etc/.product_name /root/.ssh/known_hosts /opt/qradar/conf/appid_map.conf /opt/qradar/conf/ariel_query_server.frameworks.properties /opt/qradar/conf/nva.configservices.conf /opt/qradar/conf/Q1LABS-MIB.txt /opt/qradar/conf/ssl.cert.conf /opt/qradar/conf/iptables-nat.post /opt/qradar/conf/iptables.post /opt/qradar/conf/iptables.pre /opt/qradar/conf/host.token /opt/qradar/conf/patch_list /opt/qradar/conf/ssh_impl.conf /opt/qradar/conf/ip_context_menu.xml /store/configservices/.gitignore /store/configservices/host_tokens.masterlist /store/configservices/deployed/deployment.xml /opt/qradar/conf/uis /opt/qradar/conf/trusted_certificates /opt/qradar/conf/key_certificates /opt/qradar/conf/templates/configservices/pluggablesources /store/reporting/templates /store/reporting/reports/logos /store/configservices/productdescs /store/configservices/scannerdescs /store/configservices/wincollect_patches /store/configservices/deployed/globalconfig /store/users /etc/httpd/conf/certs /store/sessions
When QRadar backup created, you can download a backup archive, using right-click on the backup Name and save it to external storage. This feature has size and time limitations and much more effective is copying over using command line. Remember that all configuration files restored on console, will be copied over to each Managed Host during process of deploying changes, so any current settings on hosts will be overwritten.
Backup options
The following options in the Backup Archives window are:
- Restore: which restores a backup file. When you recover a backup on the console, QRadar creates pre-recover configuration backup as a first step toward restoring. This helps in the case if anything would go wrong and restore of backup would not work. Restoring process can take several hours and it is depending on the size of the backup archive. During restore, the process executes following steps:
– Back up of existing files and database tables.
– Shut down of Tomcat service (display engine).
– Stopping other system processes.
– Extracting files from the backup archive and restore to disk.
– Restore database tables.
– Restart of other system processes.
– Tomcat restarts.
The special case of backup is when it was taken on a high availability (HA) cluster. In order to restore full functionality of HA cluster, after restoring files on the primary component you have to Deploy Changes to copy cluster configuration to secondary component. The secondary host should immediately start synchronizing data from the primary system. Until the full process is complete do not restart the Console. After that navigate to the ‘System and License Management’ in the Admin tab, select the Console’s row with the ‘Unknown’ status from the table and click the ‘Restore’ action from the ‘High Availability’ menu. This action will cause the system to be temporarily unavailable while the system restores the High Availability configuration.
Restoring backup
After restoring the backup, you must restart the hostcontext service on the host. Type the following command on every managed host:
# service hostcontext restart (for 7.2.x) # systemctl restart hostcontext (for 7.3.x)
Data backup from the events database (Ariel) cannot be recovered using this process. Recover event data, from a data backup, manually by extracting the events database structure from the data backup archive, back to storage.
tar -zxpvPf /store/backup/backup.<name>.<hostname_hostID>.<target date>.<backup type>.<timestamp>.tgz
Remember that every QRadar processor maintains its own Data backup archives, and you might have to repeat the procedure on every processor.
- Delete: which deletes backup file from the list.
This option listing only entries in database marked as existing backups, but not files which are present in the backup folder on hard drive. If you manually drop the file using Linux rm command from disk, it still exists in the backup window as long as not deleted from User Interface. To cut a backup archive, select it and click Delete in the toolbar. This frees disk space on the host. - Configure: Configure the automatic backups. Each backup archive has label with the hostname from where the backup created
Backup recovery configuration - Browse and Upload: QRadar lists backups in the window where you can view and manage all successful backup archives. Upload an off-line backup archive to restore a system. This feature has size file limitation of 512 MB. If your backup exceeds this value, you can copy backup archive directly to /store/backupHost/inbound folder. You can see that soon after, system process the backup, which moves to /store/backup/ and creates an entry in the database. If for some reason backup would not process then QRadar moves it to store/backupHost/invalid.
What if backup fails
A QRadar backup might fail because of lack of the free space on storage. The process determines necessary free space with the assumption that it needs three times more free space than took the previous backup. If system can’t find previous file, the process starts the backup anyway.
Among the other reasons of backups fail, some are below:
- Unable to initialize Backup Recovery Engine,
- Can’t clean up the database after the backup failed,
- Not able to clean up bad backup archive after backup failed,
- Not enough free disk space to do backup,
- Unable to release running lock,
- Unable to execute backup request,
- Backup: A backup description corruption,
- The last scheduled backup exceeded execution threshold.
The time taken by backup can be quite long, depends on number of data and resources available in system. You can set the lenght of time, that you want to allow the backup to run. The default is 180 minutes. If the backup process exceeds the configured time limit, the backup process cancels automatically for configuration backup. For the data backup, the default value is 17 hours (1020 minutes). You can increase these values, but for no longer than 24 hours. I could see some cases raised to support by customers, in which they couldn’t finish backup on time.
Rsync instead backup
Execution threshold in a busy environment with a large value of daily received data to back up can easily exceed values mentioned above. In this case, it is better to use rsync for syncing data periodically using the following command:
# rsync -azP /store/ariel/ root@remote_IP:/store/ariel
On each Managed Hosts in distributed deployment you can repeat the same method.
It is also a good idea to mount backup folder to off-board storage instead of copying backup files every night after the backup finish. To get this functionality, you need to run rpcbind service on QRadar using the following commands
systemctl enable rpcbind systemctl start rpcbind
After restart add the following line to the QRadar /etc/fstab file to mount folder.
nfsserver:/nfs/export/path /store/backup nfs rw,soft,intr,noac 0 0
You should never mount QRadar backup share on external storage as you can run into troubles (especially in HA devices). Mount external share in QRadar instead as described above.