From 77643a92cd8bb80070f6237bbf8805af92b7c750 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Tue, 9 Feb 2021 16:16:39 -0600 Subject: [PATCH] Updated Backup & Restore (markdown) --- Backup-&-Restore.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Backup-&-Restore.md b/Backup-&-Restore.md index 4557357..d4c3279 100644 --- a/Backup-&-Restore.md +++ b/Backup-&-Restore.md @@ -4,9 +4,11 @@ ./gravity-sync.sh backup ``` -Added in version 2.1, `./gravity-sync.sh backup` will perform a SQLITE3 operated backup of the `gravity.db` on the local Pi-hole. This can be run at any time you wish, but is also be added to the system's crontab by the `./gravity-sync.sh automate` function to run once a day, at an hour of your choosing. If you do not wish to use this automated backup, you can disable it by setting the value to `0` during setup, or by manually editing your crontab file and removing the entry. +This will perform a SQLITE3 operated backup of the `gravity.db` on the local Pi-hole, as well as copying Local DNS and CNAME record settings if those are enabled. This can be run at any time you wish. Keep in mind that as part of the regular sync operation, when changes are detected to either Pi-hole, this backup will happen automatically. -By default, seven (7) days worth of backups will be retained in the backup folder. You can adjust the retention length by changing the `BACKUP_RETAIN` variable in your `gravity-sync.conf` file. +By default, three (3) days worth of backups will be retained in the backup folder. You can adjust the retention length by changing the `BACKUP_RETAIN` variable in your `gravity-sync.conf` file. Running any sync job (`compare`, `pull`, `push`, or `sync`) will trigger the deletion of backup history at the end of the job. + +If you experience a high rate of change to your Pi-hole environment, which would trigger more active sync jobs, consider adjusting the retention settings to avoid filling up the storage on your Pi-hole. If for some reason your replication job does not complete successfully (ex: your path to restart FTLDNS services is not correct and sync fails) you may see backups collect beyond your retention period. If so, you can also manually delete any of the backup files without impacting Gravity Sync operation. See Also: [Hidden Figures](https://github.com/vmstan/gravity-sync/wiki/Hidden-Figures#backup_retain) @@ -16,8 +18,8 @@ See Also: [Hidden Figures](https://github.com/vmstan/gravity-sync/wiki/Hidden-Fi ./gravity-sync.sh restore ``` -Added in version 1.6, Gravity Sync can also restore the database on the secondary Pi-hole in the event of data loss. This could happen in a scenario where you've had your primary Pi-hole down for an extended period, made changes to the secondary, but perhaps didn't get a chance to perform a `push` of the changes back to the primary, before your automated sync ran and pulled changes from the primary. +Gravity Sync can also restore the database on the secondary Pi-hole in the event of data loss. This could happen in a scenario where you've had your primary Pi-hole down for an extended period, made changes to the secondary, but perhaps didn't get a chance to perform a `push` of the changes back to the primary, before your automated sync ran and pulled changes from the primary. -New in version 2.1, when executed this task will ask you to select a previous backup copy (by date) and will use that file to restore. This will stop the Pi-hole services on the local server while the task is completed. After a successful restoration, you will now also be prompted to perform a push operation of the restored database to the primary Pi-hole server. +When executed this task will ask you to select a previous backup copy (by date) and will use that file to restore. This will stop the Pi-hole services on the local server while the task is completed. After a successful restoration, you will now also be prompted to perform a push operation of the restored database to the primary Pi-hole server. It's suggested to make sure your local restore was successful before completing the restore operation with the push job. \ No newline at end of file