Configuring the data archive
Data Archive backs up the audit data that Guardium captured, for a specified date, to another location. Typically, data is archived for the previous day, which makes sure that if there is a catastrophe, only the data of that day is lost. This practice also saves disk space and boosts appliance performance. Configure and schedule the archive mechanism during the implementation stage to run nightly: to archive the last day’s data.
About this task
Data Archive files can be used for data restoration for forensic purposes when data for a limited number of days needs to be restored. Restoring archived data does not override the existing data. You can restore data on an appliance that already has data, but you can't restore data on the same unit if data for that day still exists.
In an aggregated environment, data can be archived from the collector, from the aggregator, or from both locations. Most commonly, the data is archived only once, and the location from where it is archived varies depending on your requirements.
The audit data is stored in a normalized way in an internal database of an appliance. The audit data that changes constantly is referred as dynamic data, and the audit data that stays relatively constant is referred as static data. For example, profile data is static and audit data is dynamic.
To save space on storage
servers, Guardium uses an incremental archive strategy. The dynamic audit data is archived when it
is observed. Static audit data is archived only when the data is observed for the first time. This
incremental approach considerably reduces the size of archive files. The tradeoff is that a single
archive file might not contain all audit data that needs to be restored back to the appliance. To
compensate for this tradeoff, the archive process generates a full (not incremental) archive file
the first time the archive process runs, and then again the first day of every month. If you want to
have a full archive for the next archive run, use this CLI command: store
archive_static_table=on. After that run, the parameter switches back to be
off
. To check whether the static data is archived in the next run, run the CLI
command: show archive_static_table.
The data archive is set to archive data older than one day and ignore data older than two days. In this scenario, each run archives only the data from the previous day.
Guardium’s archive function creates signed, encrypted files that cannot be tampered with. Do not change the names of the generated archive files. The archive and restore operations depend on the file names that are created during the archiving process.
Archive uses the system shared secret to create encrypted data files. Before information encrypted on one system can be restored on another, the target restore system must have the shared secret that is used by the archiving system during file creation. . Data can be restored on the same unit type it was archived from: collector data on a collector, aggregator data on an aggregator.
- <day of data>-<Guardium system name>-w<time of zip>-d<execution date>.dbdump.enc
- <day of data>-<Guardium system name>-w<time of zip>-d<execution date>.agg.<sql ver>tar.gz.enc
Procedure
What to do next
- Verify whether the operation was successfully completed. Click . Each archive operation shows multiple activities. Check that the status of each activity is Succeeded.
- AWS archives only. Check that the files were uploaded:
- Log in to the AWS Management Console http://aws.amazon.com/console/ with your email address and password.
- Click S3.
- Click the bucket that you specified in the Guardium UI. Verify that the files are there.
- EMC Centera archives only. Check that the files were uploaded to the EMC Centera. You need the name of the files and a ClipID.