Cutlery/gravity-sync
1
0
Fork 0
mirror of https://github.com/vmstan/gravity-sync.git synced 2025-07-09 02:34:06 -04:00
Code Issues Packages Projects Releases Wiki Activity

Destroyed Backup & Restore (markdown)

Michael Stanclift 2022-02-25 12:13:49 -06:00
parent 3bd6f907a9
commit 7336d7247a
1 changed files with 0 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Backup-&-Restore.md

@ -1,25 +0,0 @@
### Backup Function
```bash
./gravity-sync.sh backup
```
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, 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)
### Restore Function
```bash
./gravity-sync.sh restore
```
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.
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.