Switched Duplicati with Restic

It all started with a simple version upgrade.

It was my bad I didn’t check if everything was still in place after it. I took the risk and blindly assumed jobs would run smoothly afterwards.

I was wrong many times:

  1. Wrong to take the risk
  2. Wrong to not test jobs
  3. Wrong to take things for granted

Infra management can be cruel to you if you make the above mistakes.

It was only when I see those red dots on the screen indicating failures I decided to see what a heck was going on.

Basically, all backup jobs were failing. This was one of them.

My initial reaction was to take this wordy log and dump it into god almighty LLM for troubleshooting.

5 minutes later and all the checking completed, the problem persisted to the point the LLM had no alternatives but to point the finger at Duplicati and its latest upgrade.

Since I wasn’t getting any progress out of this situation, I decided to give other tools a try.

The first was Borg, until I learned it would not connect to Wasabi (or any S3 compatible object store) directly. One would have to send files via rcloud. This is a no-go to me, I prefer an end-to-end backup solution with all the traditional features.

Borg out.

Next was Duplicacity. It has a straightforward installation and a nice UI, really nice indeed, but it’s a paid option, and I wanted a zero cost, set-up-and-forget-it solution.

Duplicacity out.

The next option down the list was Restic, which impressed me with its simplicity and power.

In 15 minutes I had it configured in my server and running tests (I learned the lesson).

Then, later in the day, ran a 5GB full backup of some websites and everything worked as smooth as it should. I checked the log file, all clear.

Created the cron with the full command with retention policy and periodic purges to clean up the remote bucket. Done!

If you need a slim, simple yet powerful CLI backup app, give Restic a try.