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

Community
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.

10 Likes
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).

1 Like
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

1 Like
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.

1 Like
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?

1 Like
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…)

2 Likes
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:

3 Likes
11

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

1 Like
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.

1 Like
13

Could the race condition between first-completed-snapshot and prune be solved by not running prune until the first snapshot completes uploading?

1 Like
14

Sure, but there’s no guarantee it wouldn’t happen with future snapshots. So you’d have to indefinitely not run prune until you’re done making snapshots forever unless you keep track of when a backup has completed and only then run prune. Relica does this for you.

15

I’m not sure if you are even still on the forum (all relica discussions seem to have died circa 2018).

Is relica still operating? Safe to use?

I’ve noticed the installer doesnt ask for admin permissions, then fails to complete the install (writing to c:\programdata I believe)

I’ve also noticed when I pointed it to my existing repo, it would not allow me the option to restore existing backups.

When I’m not using your rather pricey cloud service ($25/tb might have been the price in 2018, but not today) why does it need to log into the cloud? Is my information like snapshot data and “backup sets” stored on your servers?

What happens if relicabackup.com goes away? Are my backups lost?
Thanks

16

Relica exchanged hands over a year ago – it is, overall, excellent software. I am not sure what the new owner is doing with it these days. Unfortunately I’m no longer able to provide help or support with it as I don’t work on Relica anymore myself or access anything in its systems/code.

But I have good news regardless.

Yes; as in, it won’t harm your data. It’s a thick UI and service wrapper over restic, but “thin” at just the right spots.

I seem to remember issues with that. I don’t actually run Windows so all my tests with it were through friends’ computers or VMs and I was able to run the installer successfully. I wonder if something changed with Windows in the last 5 years – or maybe there’s a weird env setup we didn’t encounter. I dunno. But it’s intentional that we don’t run as administrator; the purpose was to back up user-space data, and to be safer to operate that way. (No reason it can’t pivot, however, and run as admin! That’s technically possible. This was just a decision we made.)

I’m not sure on that one anymore – would probably need more details, but I think that needs to go to the support inbox.

That’s for 2 redundant cloud copies, I believe. It can go on just 1. I’m not sure what the current pricing is other than what the website shows.

To be clear, there are 2 “clouds” you might be referring to?

  • Cloud backup – i.e. storing your backup set in the cloud. This is purely optional, but is on by default unless you change it during the setup/onboarding flow when you set up a new backup/repo. It’s on by default because it’s an important part of a 3-2-1 backup strategy and what most people use Relica for: they get the benefits of restic but don’t have to self-host or figure out cloud storage! Hurray.

  • Relica’s servers – this is solely for billing and keeping your configurations synced. Relica connects to its billing server to make sure you are logged in, have an active subscription, etc. To answer your questions:

Hopefully I answered this one already. Cloud backup is optional, it doesn’t “need” to do that. But it does need to connect to its servers once in a while. But you can be offline for a long time before it should start disabling paid features.

No. The only data stored on Relica servers is the program configuration and account/billing info, along with your MEC (main encryption key). This key is protected by a password that you have to enter every time you log into the Relica app on your computer, and it is never transmitted to Relica servers; it is used to encrypt data that gets sent to Relica already encrypted, so Relica team cannot read/decrypt your data. It’s why if you lose this password, it’s game over for your backup data. The MEC also protects backup configurations stored in the DB, for example: the folder paths included in a backup set. That is considered sensitive metadata so it is encrypted locally. Relica team cannot know or reveal which folder paths you are backing up.

Actual backup data is not stored on Relica servers; even if you back up to the Relica Cloud, it goes to third-party storage providers (already encrypted, as restic always does).

Not at all! Relica backups are just restic backups. Relica even documents how to read your backups without Relica:

Anyway, I hope that is helpful. Sorry I can’t be more help, as I’m no longer with the project. But technically it is pretty good, and your backups (that you have locally or on your own storage devices, at least) are safe and accessible even if Relica disappears.