Backblaze B2 point in time recovery


#1

Hello,

Is it possible to restore (sync back to local drive) the file versions from a specific point in time when using Backblaze B2?

The purpose is to have a daily incremental backup to Backblaze B2 using rclone sync and be able to restore the entire folder structure that was synced in a specific day.

Thanks!


#2

When using b2 it makes revisions for you automatically, so you can use --b2-versions to see the older versions of files you uploaded. That isn’t in exactly the format you wanted though but all the information will be there.


#3

Hi,
i’ve recently started to use rclone, so first of all I would like to thanks the developers community for this great software!
Like ngm, i also think that a function to recover (copy) from b2 the files that existed at a certain time in the past (or x days ago) would be really useful in a lot of scenarios.

In my case I’m using rclone to periodically sync a borg backup repository to b2. Borg can easily manage an infinite versioning incremental backup so, in theory, I could disable the versioning feature in B2 to save space. If I want to protect my repository from an accidental corruption being propagated from the local copy of the repository to the remote one, B2 versioning could be relly useful, but, in this scenario, an easy recovery method is essential. A borg repository has thousands of files inside and the only way to recover previus versions with rclone is per single file.

This is just to add my opinion and my use case to this argument, in the hope this could help to opt for the development of a new feature.


#4

Likewise! Building this into Rclone would be amazing. For now there are a few alternative scripts mentioned in this thread https://github.com/ncw/rclone/issues/2126.


#5

Have you thought about using actual backup software like restic which already does this for you, and integrates with rclone?


#6

Restic is awesome however due my large dataset Rclone with Backblaze B2 keeps it’s lightweight. Storage is cheaper then cpu/memory requirements needed for a “real” backup repository.


#7

Hmm, interesting. Can you elaborate a little more on this? I’m curious how much data you have, and what are your CPU/memory constraints? (We want to make it better.)