Backups¶
Scrutinizer includes backup and restore scripts in its /home/plixer/scrutinizer/files directory.
The scripts are intended to be executed on the instance, by the plixer system user, with sufficient storage available at $BACKUPDIR or /var/db/big/restore by default.
Local Backup¶
Scrutinizer includes a backup script located at /home/plixer/scrutinizer/files/backup.sh on the filesystem.
The script is intended to be executed on the instance, by the plixer system user, with sufficient storage available at $BACKUPDIR or /var/db/big/restore by default.
Remote Backup¶
Remote backups between two Scrutinizer instances can be performed by mounting $BACKUPDIR via sshfs. It’s important that the Scrutinizer versions of the two instances match.
See how to perform a Remote Backup.
Restoring from a Backup¶
It’s important to restore to an instance whose version matches that of the backup file. e.g. If your backup is that of Scrutinizer v19.2.0 use a freshly deployed v19.2.0 instance as the restore host.
Scrutinizer includes a restore script located at /home/plixer/scrutinizer/files/restore.sh on the filesystem.
Some steps beyond what the restore utility provides are required and will vary depending on what type of Scrutinizer node is being restored.
Before using the restore utility¶
Be sure a backup file is available at the expected location, $BACKUPDIR or /var/db/big/restore by default. The utility will attempt to find Scrutinizer backup files in the directory and prompt for restoring from any it finds.
Warning
Restores are destructive to both the existing Scrutinizer instance AND THE BACKUP FILE ITSELF. It’s best to restore from a copy of a backup.
Considerations after Restore¶
You will need to re-register the restored instance from the Scrutinizer Primary Reporter. If the deployment is stand alone that will mean registering the instance with itself.
Distributed deployments will require ssh access from the Primary Reporter to the restored
instance.
If you are restoring the Scrutinizer Primary Reporter itself and its Machine ID differs from that of the backup instance a new license key will be required.
Certificates¶
For restorations where DB connection issues are observed, a command should be run to recreate database certificates.
From the primary reporter run:
scrut_util --rotatecerts
Warning
It’s important that this is run on the primary reporter.
Permissions and Ownership¶
For pre-19.0.0 installs, or cases where back.sh encounters permissions errors, look at the following directory permissions:
Create a directory /var/db/big/restore and make sure it is owned by postgres:postgres.
Note
For older installs /var/db/big/ was owned by root so backup is unable to create this directory when run as the plixer user
Make sure all files in the /var/db/big/pgsql/data are owned by postgres:postgres.
Note
If installs/upgrades have been run as root some configuration files (along with their backup and .new counterparts) may be owned by root.