Why repo.rent exists

There are oh-so-many backup solutions: rsync to Wasabi, Borg to rsync.net, Duplicacy to Azure, cp to an external hard drive… here’s why repo.rent exists anyway.

I wanted my backups to be:

• incremental, only backing up files that have actually changed since the last backup;
• encrypted, so I can back up sensitive data;
• append-only, to prevent the destruction of backups (e.g., by ransomware); and
• done through a CLI, to automate my backups.

Restic was the solution to half of the puzzle. It does what I need and more, but it’s only a backup program, not a backup solution. In other words, it needs somewhere to back up to.

Restic can make backups to practically anywhere (SFTP, S3, and rclone, to name a few). I like rsync.net, but I have a lot of small restic repositories that I want to keep clearly separated, and the storage minimum would incur high costs.

This is where repo.rent comes in. I can create many separate repositories and only pay for the storage I use (per megabyte instead of per terabyte) without a minimum.

It hosts repositories on restic’s REST Server, which:

• is more efficient than the SFTP backend (see why); and
• can be run in append-only mode, one of my requirements.

So this is why repo.rent exists: I needed it. If your requirements are similar, maybe repo.rent is the solution for you too. Give it a try; the first 10 GB are free, forever.