Updated Backup & Restore (markdown)

Michael Stanclift 2020-10-21 20:22:34 -05:00
parent 9b2587ff04
commit dc5e6297a4

@ -1,11 +1,19 @@
### 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.
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.
### The Restore Function
Gravity Sync can also `restore` the database on the secondary Pi-hole in the event you've overwritten it accidentally. This might happen in the above 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.
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
./gravity-sync.sh restore
```
This will copy your last `gravity.db.backup` and `custom.list.backup` to the running copy on the secondary Pi-hole.
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.
This function purposefully asks for user interaction to avoid being accidentally automated.