Relica, a cross-platform UI for restic, is now version 1.0


#1

Just wanted to mention here that Relica, a backup service I’ve been working on heavily for the last 6 months, is now version 1.0: https://relicabackup.com/blog/relica-1_0

Relica uses restic for its archival and restore operations, so you can restore your data using only restic if you need to. Relica takes care of running restic on a schedule correctly – many scripts I’ve seen here and elsewhere that automate restic are nice and convenient, but have the potential to lose data if they run prune at the wrong times (:exclamation:) – but Relica won’t.

I started working on this after CrashPlan announced the retirement of their Home product, as I realized I’d need a suitable replacement for my whole family, and their families. Even CrashPlan wasn’t a perfect fit (not for my own needs), so I decided to make Relica. At first, it was “just” going to be a web UI over restic, but then I realized I wanted it to be more accessible and usable by non-technical users who don’t know how to clone open source projects and get started with something from GitHub.

I also wanted a fancy managed cloud backup solution so that my family wouldn’t need to set up their own B2 or S3 accounts, etc. And I wanted to back up to multiple cloud providers without uploading my data more than once (we have slow Internet access).

So Relica was born. And today it’s version 1.0. Now you can back up to local disk, friends’ computers (or other computers on your own account that have Relica installed), the Relica Cloud, or your own cloud accounts, including SFTP and WebDAV.

Anyway, I don’t mean to merely advertise, but I wanted to show the community something that we built around restic. Feel free to try it, or find some inspiration for your own projects. And all the restic contributors – especially @fd0 – should be very pleased with their work. Restic is very well-engineered. We have a lot of compliments about how fast restic is when backing up locally, something that other projects haven’t been able to excel at. (I suspect restic’s snapshot model, as opposed to “continuous” backup, is one factor.) Restic is also to blame for good security and privacy: only you can read your data, even when backing up to friends’ computers. :+1:

Relica also has a nice CLI (something we designed carefully – it has the full functionality of the web UI) so you can use it over SSH.

Thanks to all who made this possible. Relica (and ultimately restic) are replacing my entire family’s backup stack now.


#2

How does Relica prune the repository? This seems to be one of the more problematic aspects of setting up a good backup routine. Having backups run every hour leaves little room for pruning, especially when the computer being backed up isn’t active during e.g. night time when you’d consider running the pruning otherwise. So how are you implementing pruning in Relica that doesn’t interfere with the backup schedule?


#3

I didn’t say that prunes don’t interfere with the backup schedule – just that prunes don’t run at times when it could cause data loss in the repository. Prunes and backups can’t run at the same time, that’s true. Currently, Relica prioritizes backups over prunes ("adding data > deleting data" philosophy) so if a backup is not running, Relica will run a prune if it is time to do so. It skips prunes if repositories are not in a “safe” state to prune. If a prune is running long and a backup tries to start, the backup will have to wait until the prune is complete or cancelled.

Restores from the Relica Cloud preempt prunes, however, so restores are always available there.

In general, after the initial backups complete, backups don’t take very long and prunes can run somewhat regularly (not frequently, but regularly).


#4

Right, but I’m curious about more concretely when you run prunes. Do you have a schedule for them? What is that schedule? Does the prune run from the client only, or do you have it set up so that the backend systems can prune as well?


#5

Gotcha. Prunes are scheduled to run no more than once every 7 days. (We’re gonna improve the logic in the future so that for larger repos, it happens less often, but also subject to desired retention periods.)

Prune runs only from the client, since we don’t have the repository password.

Prune does not run on a repository if there are any started-and-unfinished backups to that destination. This is the tricky part that a lot of simpler scripts don’t consider, potentially causing data loss if an initial backup takes a while: See Quick question about running prune.

You can read more here about how retention periods are enforced: https://relicabackup.com/docs/retention-periods


#6

I’m interested in the mention of “data loss”. My understanding is that prune will only run when there are no backups in progress (due to locks held and periodically refreshed by the client during the backup process), and the scope for prune doing anything unwanted here is it jumping in after a client has disconnected part-way through a backup, and then removing data the client had already uploaded.

The outcome as I understand is then that the client has to go through the bother of re-uploading that same data which prune may have just removed. While that may be important if you’ve got limited client bandwidth or pay for data, I’m not sure I would describe that default behaviour as “data loss” as it can’t affect any data in completed backup snapshots.

A potential improvement for restic might be for prune to only consider removing unreferenced data if it has been stale for a (configurable) bit, in the hope the client will come back and complete its backup. Maybe that’s already in the plan.


#7

Yes, that’s correct.

Initial backups can take months to complete, and if you need your backup before then… you’re out of luck if prune already wiped it out. We consider data that was deleted from a repository but later needed as one form of data loss.

That’s a good idea, if the timestamp is saved with the unreferenced data.


#8

Hi @matt
Relica looks great and is pretty much what I’ve been looking for (a graphical front end for restic). One thing I would like to ask you about is how much Relica contributes to restic - ie. can I reasonably say I’m (also) supporting open-source development if I buy a relica membership?


#9

That’s a great question, and a good concern to have. :slight_smile: I’ll defer to @fd0 since I don’t think I can answer for him.

I’m sure we will continue to contribute to restic – but we don’t want to try to push so much through the pipeline (at least at one time) that we overwhelm Alexander. For now, every PR appears to go through his review, and we don’t want to burden his time. I think we’ve got one or two open PRs right now that are waiting for more feedback, so we’ll leave it at that for now.

(I say this as a fellow OSS developer and maintainer – so I somewhat know how it is. Except fd0 handles his community much better than I have mine…)


#10

Oh, I’m confident that Matt will continue to contribute to restic based on the number of pull requests :), you can see for yourself: https://github.com/restic/restic/pulls?utf8=✓&q=is%3Apr+author%3Amholt

It’s in the interest of both projects to get bugfixes and features into restic if possible. We also regularly talk about implementation details and so on :slight_smile:


#11

Thanks for the quick and thorough replies, @matt and @fd0. It’s just as I’d hoped :grin:


#12

Thanks for the clarification and checking my understanding. Yes, if you’re on the end of a slow and sporadic link and are backing up a lot then I agree it could definitely be a race between backup and prune, which backup may not win.

Best of luck with your UI and service, it looks really interesting.