Backup Immutability - Object Lock support?

Thanks! I was looking for exactly this topic to quote here, but I haven’t found it, I was probably not using the right words in the search.

Yep!

1 Like

I did some testing and I still think that using B2 in this way is not very helpful :frowning:

I really do not see any useful way to recover if adversary used b2 tool to soft-delete all your files.

And it is worse if you sync local backup to cloud using rclone - data is on B2, but there is no tool I know off which can recover B2 state to a point in time. Ideally, it should work as snapshot - you get hacked today, you clean up, go to your cloud storage and tell it to get you to the state you were yesterday.
I searched for a tool, which would allow B2 point-in-time recovery, but besides some hack-ish scripts didn’t find any. It would be great to have this functionality included in Duplicacy and rclone, but until it is there, I’ll stay with more expensive, but proven backend with snapshots :wink:

And what would these backends be?

This would be rsync.net (I mention this earlier in this thread) - it uses ZFS and provide 7 daily snapshots free, but you can setup flexible schedule and only pay for difference in data in older snapshots.
I use it for some time already, but I am always on a lookout for alternatives.

Sorry, I had read it quickly and didn’t notice the snapshot aspect.

So I have two options:

  • B2 (with its retention policies and different permissions per key) for 0.005 / GB / month

or

  • rsync.net with its snapshot protection for 0.025 / GB / month

Keep in mind that:

  • You only pay for storage on rsync.net - they do not charge for ingress/egress
  • B2 - you can get free egress if needed, but you pay for ingress and API calls (but probably not too much)
  • If you go through the right door, you get 0.015/GB/month - rsync.net/products/rclone.html

Still, B2 will probably be cheaper, especially if you are on a budget. But absence of the clear way to recover data to a previous state in case of attack makes this irrelevant for now.

1 Like

No, there is no cost of ingress.

Some, but more related to download / egress. For backups, class A (free) transactions are the most used.

https://www.backblaze.com/b2/b2-transactions-price.html

Interesting :wink:. As they support SFTP, maybe I’ll do some tests later.

You are right, ingress is free, I mixed up with something else… With Cloudflare it makes storage relatively economical, but I am not sure how well this works with Duplicacy - I know there was a merged pull request for B2-custom backend, but I do not see much documentation or feedback on this feature…

I also like rsync.net because of ssh/sftp support - this makes it a bit more compatible with other data storage approaches :slight_smile:

1 Like

I believe that if you read the fine print these cheaper accounts don’t support snapshots.

Not sure where did you see that - I have such account and I do have snapshots :slight_smile:

Whoah! That’s a really nice door!

What is the catch though? (Reading fine print furiously)

There is no catch… As I understand it, people who run the service are bunch of Unix techs, who know the value of borg and rclone tools and provide special discount for their users (you can replace rclone.html with borh.html and you’ll get same discount).

I exchanged email with their support too - pleasant experience, very knowlegable.

Sorry I got the plans you were talking about confused with borg plans: Cloud Storage for Offsite Backups - borg support (rsync.net) which says “Free ZFS filesystem snapshots are not included since you’ll be doing versioning and retention with borg.”

That’s interesting, I did not realize that borg plans don’t include snapshots!
Glad that I found rclone plans at one point :slight_smile:

Also, keep in mind that pricing structure is different - you have to purchase 100GB min, after that it can auto-grow in 20% increments after reaching 90% use (this is from one of the emails with their support).

Isn’t the case that if you don’t give yourself delete permissions on B2 (i.e. you can’t prune with duplicacy) then the adversary can’t delete its backup files? This has no worse storage downsides than the snapshot style backup (i.e. both will keep growing forever but will be deduplicated.) I use duplicacy to copy my local duplicacy backups to b2. Then restoring from B2 is no different than restoring from a local backup. You can use revision labels to simplify keeping track of which revisions from each repository go together - perhaps have the label be the date.

Thank you. I think I misread the pricing. This comes out to be $15/TB/month, which is 3x more than even BackBlaze. I don’t see the point in using them. Snapshots are questionable benefit to pay triple for.

Adversary cannot permanently delete files, but they can hide file or upload corrupted file version.
If that happens, there is no tool to recover previous, good state for large number of files - I so far could not find one which will restore bucket to previous state at a point I need - i.e. simulate reverting to the snapshot.
Basically, there is a way to protect from data loss, but there is no simple way to recover :frowning:
Also, keep in mind, you’ll have to do prune manually all the time which might be good for lower-volume home backup.

It depends on your acceptance of the risk - how much you value your data :slight_smile:

If you are comparing Duplicacy against immutable snapshots, then you shouldn’t be pruning since there’s no equivalent to prune with immutable snapshots.

And how is “upload corrupted file version.” worse for Duplicacy than your other solution? With Duplicacy every block is named by it’s hash, extra files aren’t a problem (there’s no path to them). And if you are paranoid, do a check which can download and check hashes of all files.

All previous states are available if you never prune.

I think you are mixing things up. I am not comparing Duplicacy with anything - it actually does not matter what backup software is used, the issue is with storage behavior itself.

No matter what data you write to storage - as long as you can write (and in case of B2 - “soft-delete”), there is a way to corrupt written data. Once this is done, you have to restore to a point in time when storage state was valid - in case of the snapshot, you have it ready and available for you immediately.
In case of B2, data is there, but it is NOT directly accessible as is - the state of the storage needs to be reverted - for overwritten files “bad” version needs to be deleted so the previous, “good” version becomes visible and for “soft-deleted” files the “hide” marker needs to be removed.
So B2 can “emulate” storage snapshots - data is there, safe, but there is no real tool to do that, unfortunately :frowning:

This is all besides the issue with unattended pruning - where credentials with actual delete permission needs to be stored on the system…

If you want to compare Duplicacy with FS snapshots, you actually have to take into account data life cycle configuration - if you have immutable snapshots for the last 7 days, that only means that there is a “prune job” running somewhere cleaning older data :slight_smile:

1 Like