Question Restoring encrypted folder from a snapshot?

[devoid]

First off, I just started using Synology today so forgive me if I have missed something obvious.

My goal is to have encrypted backups on some cloud provider (S3, GCS, B2, etc.) and to be able to periodically restore those backups back to the Synology (or other Linux machines) for verification and disaster recovery. To that end, I've created a shared encrypted folder on my btrfs system, added a few files and enabled hourly snapshots using the Snapshot Replication package.

The Snapshot Replication application only supports replicating to another DSM machines or to another local volume. I have neither, but it is fairly easy for me to write a script to find the scheduled snapshots (btrfs sub list /volume1/@sharesnap) and use btrfs send to upload them to a cloud provider.

The trouble comes when I try to restore these snapshots on the DSM machine. The only thing I've been successful with is adding the snapshot to the "source" shared folder (with encryption), and and messing around with the @[email protected] to get the snapshot to show up in the UI. At that point I could use the "Clone to a New Name" option to recover the share and decrypt it.

$ btrfs send -f volume1/tmp/test.file /volume1/@sharesnap/@documents@/GMT-2019.04.24-22.15.02
$ synosharesnapshot delete documents GMT-07-2019.04.24-22.15.02
$ btrfs receive -f volume1/tmp/test.file /volume1/@sharesnap/@documents@
$ btrfs show /volume1/@sharesnap/@documents@/GMT-2019.04.24-22.15.02 | grep UUID
        UUID:                   bf0dddd4-c18e-7445-9d03-ce0453a094c6
        Parent UUID:            -
        Received UUID:          b48f7cd8-fd0c-e34e-b4cf-ac9cafca1336

Then I update the @[email protected]@ file to contain this record:

echo "
[GMT-07-2019.04.24-22.15.02]
hide=false
take-by=/usr/syno/sbin/synosharesnapshot
schedule_snapshot=true
lock=false
desc=Snapshot added by devoid
ruuid=b48f7cd8-fd0c-e34e-b4cf-ac9cafca1336
snap_size=37797888
" >> /volume1/@sharesnap/@[email protected]

# Also to sync the reported number of snapshots to the actual number (not strictly necessary)
$ synosharesnapshot snapcout sync documents

The caveat here is:
1) The snapshot had to come from one of the schedule snapshots or via synosharesnapshot create.
2) When I import it back I have to manually create the entry in @[email protected] like before.
3) I can't get it to work if I add the snapshot to a different shared folder.

I'd like to be able to send a snapshot away to a cloud provider, delete the shared folder and then restore from a snapshot into a new folder. I've gotten it to the point where a) the snapshot fails to restore (e.g. if I change the name of the snapshot to a non-timestamp value) and b) to the point where decryption fails with the wrong password.

For a) are there logs where I can see the error message?
For b) I'm not very familiar with eCryptFS but I understand that there are 'key files' involved. Is it possible that I need to come up with a solution for backing these up and putting them back in the correct place somewhere on the DSM system?

 

[fredbert]

What doesn't Hyper Backup do that you are needing?

It supports scheduled backup to various destinations and can encrypt the data before transfer. Then there's Hyper Backup Explorer for accessing the backup when not using the original DSM NAS.

 

[Gerard]

What doesn't Hyper Backup do that you are needing?

It supports scheduled backup to various destinations and can encrypt the data before transfer. Then there's Hyper Backup Explorer for accessing the backup when not using the original DSM NAS.

Doesn’t synology market snapshot replication as a way to protect against ransomware? Does hyper backup provide the same protections?

 

[fredbert]

Doesn’t synology market snapshot replication as a way to protect against ransomware?

If I'd rebuilt using btrfs then I might have taken more interest in snapshot replication. I'm still debating whether I should blat the volume and start afresh.

As for Hyper Backup: provided the archive itself isn't encrypted by ransomeware then going through its version history to unaffected files within the archive would be the approach. Using off-NAS destinations 'may' provide more protection as their archives won't to mounted on a local filesystem. Having rotating, multiple backup tasks will give protection provided you spot the infection before all tasks have been run.

 

[devoid]

I actually just started fiddling with Hyper Backup after sending the original post. It does restore in the way I want although I'm sad that it looks like GCS and B2 aren't supported. I'll take a look at Hyper Backup explorer as well.
My observations looking at it so far:

1. The backup format doesn't appear to be 'simple' in the sense that it uses simple Linux tooling at it's core. I am always a bit skeptical of backup solutions that require a custom piece of software where you can't analyze the constituent parts of the solution. Correct me if I'm wrong here and the backup format is some standard Linux thing.

2. Hyper backup seems to create a lot of files vs. snapshots which are a single file (possibly broken up into chunks because of max file-size limits in the cloud provider). More objects means more API operations and higher cost.

3. It looks like with Hyper Backup I need to grant the DSM permissions to create and delete objects in the bucket. The model I'd really like is for the DSM to only have permissions to list / create objects and have a separate (offline) tool to manage backup retention / deletion. Maybe this fits with your ransom-ware threat model?

4. The decrypt, then encrypt loop is confusing to me. I don't know how to think about the security implications. I am aware that there are issues with eCryptFS w.r.t. uploading the full backup to a cloud provider.