Updated Backup & Restore (markdown)

Michael Stanclift 2020-10-22 16:50:39 -05:00
parent cabdd656da
commit 4ad57a9854

@ -1,17 +1,23 @@
### Backup Function ### Backup Function
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 be manually editing your crontab file and removing the entry. ```bash
./gravity-sync.sh backup
```
By default, 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. Please review [this document](https://github.com/vmstan/gravity-sync/wiki/Hidden-Figures#backup_retain) for more information on setting these custom configuration options. 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.
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.
Learn More: [Hidden Figures](https://github.com/vmstan/gravity-sync/wiki/Hidden-Figures#backup_retain)
### The Restore Function ### The Restore Function
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.
```bash ```bash
./gravity-sync.sh restore ./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.
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. 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.
It's suggested to make sure your local restore was successful before completing the restore operation with the push job. It's suggested to make sure your local restore was successful before completing the restore operation with the push job.