Restic + Backblaze: best practice?

I currently backup various machines to a local server using the restic ssh backend. The server is raid1 and does daily rsync of the restic directory to a backup drive. The current restic volume is about 600GB.

I have been also backing up the restic directory to Code 42. This worked great but in the last year, it has been lagging miserably. It’s $120/year.

So, I’ve been thinking about ditching Code 42 in favor of Backblaze B2. I know that Backblaze usage has been discussed on and off in this forum, but I’m still unsure of the best strategy for cost and efficiency.

Given the business model for B2, my sense is that I’d better off doing an rclone of the current restic data to Backblaze periodically (e.g. once or a few times per week, maybe up to once a day) rather than using the rclone backend explicitly. Then I’m simply adding the new packs, deleting old packs and replacing the index.

Do people who have tried this have general comments on best practices? Is it better to do the rclone of the restic directory or use the rclone backend directly? Thoughts? TIA!

One thing to consider is that if your repo is somehow broken, corrupted etc. then using rclone to push that same repo to Backblaze will simply propagate the broken repo to your secondary backup, so it’s not really a “second backup” so much as a “backup of your backup”. I would probably opt for two separate backup runs and keep your concerns separate between the two endpoints receiving your backups.

Yes, I see your point. I’m currently sending backups from 3 machines to a local server via ssh to take advantage of deduplication (the 3 machines have many files in common).

I could do the same with the Backblaze B2 backend I suppose, maybe less frequently. That’s a bit more complicated in some sense but doable. I could simply add new timer scripts.

Any thoughts on what strategy is best given the Backblaze B2 cost structure (transaction types, etc.)?

With backblaze you never really hit transaction type limits doing just basic backup, at least with restic. All you have to look out for is restore bandwidth fees, and even that is reasonable.

I will note there are a couple of suggestions here:

https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html?highlight=B2#backblaze-b2

And also you probably want to make sure versioning is turned off at the bucket level - it won’t “hurt”, but will cost you a good bit of storage space ($) without benefit (my understanding).

If you use rclone for any reason, check out the

--b2-versions

flag and make sure you have what you want.

Thanks for all of the suggestions. I’m still on the fence about moving to direct backups to B2 or backing up the restic repo on my local server.

Anyway, @Rando: any thoughts about the transaction overhead on restic purge and restic check?

I have a similar setup: local backups to an HDD and then another repo on b2. I thought about using rclone to copy the local backup files first, but for reasons above decided against it.

Have considered restic copy? It will copy over some/all snapshots from one repo to another. If you keep the chunking params the same, it’s very efficient.

I have a Backblaze bucket for Restic about 400Gb and it’s costing me just under $2 US per month. Highly recommend!

Using btrbk (all btrfs filesystems) gives me quick hourly/weekly/monthly local only snapshots.

Restic is only to backup to B2 and I run it directly on the filesystem, not on the btrbk snapshots. I run forget->backup daily, and prune->check weekly with zero issues. Systemd targets and Before/After ensure sequential operations so I never have to deal with locking issues.

A typical nightly backup, adding ~600 Mb to the bucket takes about 10-15 minutes. The backup + prune and check on Sunday night takes around 30-40 minutes. My /var/cache/restic folder is about 1.3 Gb.

Hopefully that helps!