Aqua Data Management: Cleanups & Backups

1. Cleanup and the Aqua PostgreSQL DB


Cleanup is an important part of managing your Aqua Data. Cleanup prevents your Database from becoming so large that it is difficult to manage, even untenable. Ensuring you keep only that data which you need, and only for as long as you need it, will prevent your Postgres DB from getting overly full. With an agile database, you can quickly and effectively pull DB backups, and restore copies from backup, in a much shorter period than had it grown unchecked.

Determine the number of days you'd like to keep audit logs for compliance, then ensure that number is set in the UI.

IMPORTANT: do not set the cleanup numbers to a very low number if you have a large database, or currently have a lot of data. We suggest lowering this by increments (10 days every 24 hours). This is to limit the possibility of write errors in Postgres during very large data operations.

Aqua's strong recommendation is to generate and store a full backup of Aqua's "Scalock" and "Audit" PostgreSQL Databases. This will minimize the chance of data loss due to corruption, outage, etc.

image
2. Configuration Backup (import/export)


In addition to backing up your Database, we also recommend backing up your Aqua Data and Settings. This can be accomplished quickly and easily through the import/export feature of Aqua.

image

3. Deployment File Backup

Deployment files are just as important as your Database and files, but are often overlooked. We recommend you work "declaratively" to avoid your Aqua configuration variables from being wiped out, or your settings lost.

Declarative Deployment Management means that you never change live Aqua Deployment YAMLS. Instead, you make changes to YAML files that are stored in a repository of some kind, such as Git etc. They are then "checked out" and used as-is to spin up a new deployment.

If you wish to perform testing, you can certainly make changes to the local copies of your deployment YAMLs. There is no danger of it being wiped out this way, although it's important to have a single "source of truth" to avoid having multiple divergent copies floating around.

Working this way will prevent upgrades from accidentally wiping out the configuration changes you had made to your live Kubernetes system, but had not saved to a file.