I’ve finally started to consider an off-site backup location. I don’t have enough data to justify building a server to put in my parents' house (yet), so cloud it is.
So far, I’m leaning towards #Backblaze B2. Do you have anything good (or bad) to say about it, or can recommend other services to check out?
I want: one (EU-based) location, no (or small) egress fees, pricing per GB (or less), no minimum charge. I use #restic, so backend doesn’t matter (S3, FTP, DAV, you name it).
@josephb wow, didn't know that they support restic! I love the service, but with the EU VAT, it's more expensive than Backblaze or Hetzner. And my data amount will most likely land in the middle of their 250 GB / 1 TB split 😁
Exploring restic for backing up my workstation (to local external volumes and probably "the cloud" too) at the suggestion of a friend. https://restic.readthedocs.io/en/latest/
Maybe just in time, because...
[605358.398403] nvme0n1: I/O Cmd(0x2) @ LBA 131640760, 1024 blocks, I/O Error (sct 0x2 / sc 0x81) MORE
[605358.398428] critical medium error, dev nvme0n1, sector 131640760 op 0x0:(READ) flags 0x80700 phys_seg 88 prio class 2
Now I'm replacing the primary NVMe SSD tomorrow too...
@mikef Seems like consumer drives supposedly should be good for 1 year offline at 30C (worst case), and 5-10 years seems within the realm of possibility (for a drive in good condition).
I think as with anything "don't rely on a single backup" is probably the best policy (see also: "RAID is not a substitute for backups").
Not sure there are any great options for high capacity (100s of GBs or more) long term offline storage...
I hoped that by copying the #restic cache to my new computer the first backup after the move would be as fast as normal. It's not; it has to re-read all the files.
But at least Restic doesn't store redundant copies of all the files! 🎉
@mcdanlj moving all your files to your new computer possibly changed their mtimes, so Restic felt compelled to check them again and thereby ignored the cache…
Considering to change my #backup solution from #duplicity to #restic (Not sure yet, I like having #pgp keys for encryption, but it's not like a long password stored in #PasswordStore wouldn't cut it). Since restic supports Windows I might try moving a couple relatives onto it; Makes helping them easier if I know the software. For them however, a #GUI is likely a MUST, but what I've found so far is not too encouraging: restatic (dead), npbackup ("metrics" and other assorted niggles), resticguigx (Electron), backrest (browser-based, which makes my skin crawl for security tooling)... Does anyone know other options I missed? Or has some compelling arguments for those I mentioned?
@lpwaterhouse The reason why I did this switch is that Duplicity does not support large backups. The ticket is open for over a decade and still not solved.
@ascherbaum Yeah. My main issue is that duplicity feels very hacky in an "old unix grognard" kind of way (Not that I ain't one of those, but still). Been hearing good things about restic for a while now (out of the CCC universe), but looking at things like https://github.com/restic/restic/issues/187 (asymmetric encryption) being open since 2015, with quotes like "restic currently requires delete privileges for normal backup operation" (in 2021) make me somewhat hesitant... Especially given the claim that it "does backups right". The biggest draw for me really is not having to fiddle with some arcane Windows-only solution when asked for help...
@ascherbaum This is very nice & important to know, as I have only tested it as a test case, but have not yet needed it in an emergency - fortunately. 🫣
@leChris Well, I regularly need to access some files on our backups - especially on this specific laptop. That's why I remind the sole user to regularly bring the laptop to the docking station.
I'd love to have a #restic command that shows me all of the versions of a file stored in the repository. Like, I can do restic find -l some/file.txt, but this lists all copies of it in all of the snapshots it appears in, regardless of whether the file actually changed or not. I'm more interested in, basically, a version history.
You can mount the repo, and it looks like ls -l snapshots/*/some/file.txt works reasonably fast.
Is there a tool that works on this kind of "one subdirectory per snapshot" structure, compares the file's modification time & size between each of them, and tells you in which of the directories a certain mtime and size tuple first appeared?
I've already checked whether the inode numbers exposed by restic mount help, but they change between snapshots even when the file doesn't.
The curse of being a programmer is not only finding bugs in software you'd just want to use, but also having the urge to dig for the issue and potential fix yourself.
Today: The #restic wrapper #resticprofile doesn't apply the configured nice priority.
@carl You are, because what I'm commenting on is actually a separate issue raised by the last comment, and it's about interactive usage (or at least not specific to systemd anymore). Thanks anyway though!
Ugh, so in one of the replies to my experiments with #BorgBackup and associated tooling, @guerda asked "well, why not #restic?" and turns out, my main reasons against using restic (no compression and no exclude exceptions) are no longer valid, so I'm currently re-evaluating it.
Almost finished my writeup. And you know what? Both are really good.
My decision might boil down to performance against remote hosts and SSH vs SFTP, and whether "rclone serve restic" can save the day there.
So, I'd say the difference between off and auto on this particular machine is 10 % more time for 10 % compression. "max" however doesn't seem to pay off that much at all.
This is a Celeron 3965Y, two cores at 1.5 GHz, so not massively powerful.
Tools used are #restic and #rclone. All data is encrypted client side before being shipped to the cloud.
Comparing up-times, speeds (both down and up), and the correctness of the data stored. The last part was done using a VPS, and the data was found to be identical.
On speed (up and down) Jotta wins, Hetzner comes second, Mega fluctuates wildly.
On up-time Jotta and Hetzner tie, Mega went off-line for me at some points (worrysome)
On price Jotta also wins. Mega comes second, Hetzner last.
So I'll stick with Jotta. It's hosted in europe, it's fast, it's priced decently, support reacted fast when I asked some (noob) questions.
"[Restic v0.16.3] fixes a couple of bugs on Windows and in the restore command. It also works around an unlikely yet possible situation with rclone which could potentially result in data loss."
@rgberror I was watching this bug - the user's rclone erroneously reported zero files in the "snapshots" folder during a prune run. restic then assumed there were no snapshots and began pruning everything. Thankfully they quickly cancelled the prune, and lost very little backup data. I suggested general sanity checks when pruning (>1 snapshots, >0 bytes remaining data etc.), which has been added to the feature requests.