Skip to main content
Every ConfigView server you host runs a nightly backup of its database and a daily test that the backup can actually be restored. Both are installed and switched on by default.
The backups are yours. They are stored in a storage bucket in your own cloud project. ConfigView never receives them, cannot read them, and has no access to that bucket. Under your agreement you are responsible for backups and disaster recovery of your environment and your data, so you own this bucket, its access, its cost, and watching that it keeps working. ConfigView provides the tooling that makes it easy; it does not hold or monitor your copy.

​
What is backed up

  • The ConfigView database: everything your server has collected and stored, your dashboards and saved queries, your users, schedules, settings and activity log. It is a full copy, taken as a consistent snapshot while ConfigView keeps running.
  • Not included: the server itself, its operating system, your TLS certificate, and the contents of Google Secret Manager (your integration credentials and the database password). Secret Manager is already durable on its own. Take a disk snapshot of the VM if you also want a copy of the machine.

​
Where it goes and how long it is kept

You pay normal Google Cloud storage prices for these files. A backup is typically a few percent of the size of the live database, and 30 days of them is small.
You can change the retention by editing the bucket’s lifecycle rule in your own project. Re-running the install script puts it back to 30 days.

​
How you know it is working

  • The restore test. Every day the newest backup is loaded into a throwaway database on the same server, its table count and the row counts of the largest tables are compared with the live database, and the throwaway copy is deleted. A backup that is empty, cut short or corrupt fails the test. The test needs free disk space for a second copy of the database; if there is not enough, it says so and fails rather than risking your disk.
  • Failure emails. If the backup, the restore test, or the freshness check fails, ConfigView emails the notification address set on the Email page of your ConfigView, and the matching systemd unit shows as failed (systemctl --failed). If you have not set up email, you will not get that message, so set it up.
  • A stale-backup alert. A separate check emails you if the newest backup in the bucket is older than 36 hours, which catches the case where the nightly job has stopped running altogether.
You should also glance at the bucket now and then, and add your own cloud monitoring or alerting if your policies require it.

​
Restoring

Use this for a bad change, deleted data, or corruption, when the server itself is fine. (If the whole server is lost, rebuild it with the install steps and restore a backup into the new database.) Run these on your ConfigView server with an account that can use sudo, and an account that can read your bucket.
Check that you can sign in and your data looks right, then drop configview_before_restore and delete the file from /tmp. To recover just one table, load the backup into a scratch database (gunzip -c ... | sudo mysql scratch) and copy the rows you need.
The SET SESSION innodb_strict_mode=0 line matters: a few ConfigView tables are wider than MySQL’s strict mode allows when they are re-created, and without it the restore stops with ERROR 1118 (Row size too large). It affects only that restore session.
If your database is named something other than configview, use that name throughout.

​
Setting it up on an existing server

New servers get this automatically when they are provisioned. For a server that was set up before this existed, run once, as a user with sudo and a Google Cloud login that can create buckets in your project (the Storage Admin role):
The script is safe to run again. It creates the bucket if it is missing, applies the 30-day retention, gives the server’s service account permission to add and read backups, and installs the three timers. If you cannot grant those permissions yourself it prints the exact commands for someone who can. You can also create the bucket yourself first and run the script with --bucket <name>.

​
Backups to other clouds

Today the backups go to Google Cloud Storage, which matches where ConfigView servers run. Support for other storage (such as Amazon S3 and Azure Blob Storage) will follow the hosting options for those clouds.