mirror of
https://github.com/vmstan/gravity-sync.git
synced 2025-07-09 02:34:06 -04:00
Updated Backup & Restore (markdown)
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.
|
Loading…
x
Reference in New Issue
Block a user