(no title)
thebiss | 1 year ago
> When rclone uploads a new version of a file it creates a new version of it. Likewise when you delete a file, the old version will be marked hidden and still be available. Conversely, you may opt in to a "hard delete" of files with the --b2-hard-delete flag which would permanently remove the file instead of hiding it.
ajb|1 year ago
The limitation is that it's going to be somewhat more tricky to retrieve a consistent snapshot, because each file is versioned individually - rather like using CVS instead of git.
However S3/B2 versions are still a nice feature because they allow a simple way to provide the property of 'non-fate-sharing' which is a great property to have in backups but is otherwise difficult to arrange without multiple machines. Essentially, two systems fate-share if someone who hacks one can delete both. So Ideally the machine being backed up should not be able to delete the backups, and the machine (or service) hosting the backups should not be able to delete the original. But, dumb storage does not have this property (if you keep it online) and using an online service as dumb storage doesn't either. But if you use a credential which isn't allowed to delete versions in your backup tool, enable versions, and keep your backblaze admin credential elsewhere, then you have non-fate-sharing. So, it's a good idea to enable versioning even if you use restic which does its own versioning (and I don't think this will eat more space, because restic names files by content)
Another limitation of using rclone as a backup tool is that different rclone backends support different metadata (because the underlying systems do). So, it's not suitable to back up the whole of your OS, or something where you care about not losing the metadata. Eg, the b2 backend doesn't support metadata, so if you back up your OS using it you won't know what file was owned by who.