I’m developing a script to simplify restic configuration, schedule backups and maintenance in an easy way. My goal is to have one file with all the configuration (so you can save that for easy recovery) and the main features would be:
- Compatible with Windows and Linux (wip)
- Restic download and setup, including gsudo on windows, and cron/scheduled tasks setup (working)
- Backup schedule on cron format (working)
- Automated repository maintenance (pruning and health check) (wip)
- Easy recovery (navigation through snapshots and folders to select what to recover) (working)
- Pre and post backup scripts (wip)
- Email reports (working)
I intend to open-source the package once it’s stable enough or sooner if there’s anyone interested or willing to help (it’s a php script by the way, not ideal but it’s what I’m familiar with).
I’m having some “is-this-a-good-practice?” doubts I would like to share to make it as bullet-proof as I can:
- The script does a backup, then prunes the backup repository. I think this is easier than configuring another schedule for pruning, but would like to know if there’s any shortcomings with this approach.
- Currently I’m developing a post-prune check, with a data-subset of 1% so we get an early warning if somethin is wrong with the repository. Do you think this is a good idea?
- When testing on user computers, I find that sometimes the computer is shutdown when doing a backup or pruning, so the repository is locked. We have no way to know if a repository is locked beforehand, so I’m running an unlock before the backkup and before the pruning. What happens if we have a backup running and we try to unlock the repository?