Thanks everyone for any advice in advance. Sorry for the long post, but trying to provide a good understanding of exactly what I have and am interested to achieve:
I’m looking into using Restic to implement an encrypted backup of data to an untrusted off-site server. However, this data is already stored on a Btrfs drive that has historical snapshots. So I’m looking for some advice on overall backup design and settings for Restic itself considering that Restic also has its own snapshots.
For background this is what I have today:
- NAS1 = Running RAID6 on Btrfs with snapshots
- NAS2 = Running RAID6 on Btrfs with snapshots
- VPS = Off-site configurable server with significant storage
Each NAS is a ReadyNAS with an x-86 processor that I believe runs Debian.
The backup process I use today is:
- NAS1 -> NAS2 via incremental rsync
The reasoning is:
NAS1 with RAID 6 and Btrfs snapshots takes care of most concerns such as drive failures etc, and even file versioning problems because of the Btrfs snapshots allow a recovery to a past state. However, this leaves the setup vulnerable to complete hardware failure of NAS1.
The rsync to NAS2 with RAID 6 and Btrfs snapshots essentially duplicates NAS1, except the NAS1 snapshots themselves are not synced to NAS2 via rsync. However, the NAS2 has its own Btrfs snapshots, and therefore NAS2 ends up being a complete backup of NAS1, except that there is a slight versioning difference in the snapshot data due to the periodic rsync runs. This setup provides a hot spare of NAS1 as the data can be accessed on NAS2 without any significant recovery time required etc. The slight snapshot versioning difference is an acceptable compromise because I can’t think of a better convenient way to have a hot spare. This then solves the problem of complete NAS1 failure, with quick failover. However, this leaves the setup vulnerable to a disaster situation such as a fire etc. that destroys both NAS devices.
Desired next step to add disaster recovery
- Run Restic on NAS2 to encrypt and store the data off-site on an untrusted VPS.
Given that the data is already has Btrfs snapshots, what will Restic actually store/backup?
- I think it will probably behave similar to the rsync setup I have between NAS1 & NAS2, and only backup the current live version of the data unless I somehow specifically configure it to include the snapshots, but I’m not sure if this is correct, and exactly how to include/exclude the snapshots with Restic settings.
If there is the option to have Restic backup the Btrfs snapshots as part of the job, then:
- Are there any consideration in the Restic settings to make sure the Restic deduplicaiton works well with the Btrfs snapshots so the data size doesn’t grow exponentially, and/or to handle the time stamps etc., and to make sure it restores as useful as posisble?
- Is there any reason to have Restic keep any snapshots of its own, and any reason to enable/use one set of snapshots over the other. For example:
- Is it more resource or time efficient to just rely on the already existing Btrfs snapshots within the Restic backup, and/or would it use less computing power, RAM, upload and/or download time etc.?
- If I had backed up the Btrfs snapshots themselves with Restic, when restoring from the off-site Restic backup, would the Btrfs snapshots restore correctly to the NAS such that the NAS Btrfs file system will recognize and accept the restored snapshots as its own, and then just move forward working as normal from there with all that efficient snapshot history? Or is this not going to work on the Btrfs file system, and I might as well just restore a snapshot produced by Restic, and start anew on the NAS without any historical snapshots on the NAS itself from that point forward?
Any advice and thoughts on the overall design or the specific Restic settings and/or which folders to backup and restore and why would be greatly appreciated. I should also mention that I’m mostly a Windows user, and have very little experience in Linux so doing things in Linux is always a learning experience.
Thanks in advance!