Thansk for the writeup !, informative with hands on knowledge :-)

One question, what is you experience with Hetzner Box so far, I am looking into that one as a remote option.

I rsync to a cloud provider. I put my backups in a gocryptfs encrypted directory and rsync the encrypted directory.

For restore I use the cloud provider's client and mount a clear-text- dir/ on top of the gocryptfs dir/. From there I can restore. I have verified the process and it works. If the cloud provider's client malfunctions, I have to rsync the whole thing back to view the encrypted file names.

I am debating with my self if encrypting file and directory names was a smart idea.

Very pretty front page on https://tornovabackup.com/

ok - good luck with the project.

Why not just do a Git pull and be done with it ?

I track "clones" on some repositories witch this home made little tool: https://github.com/per2jensen/clonepulse

It could easily be made to collects GH Insights-->Visitors also.

my repos' last traffic updated is Sep 23, 2026 and counting...

For the linux crowd there are multiple highly regarded open source backup solutions - personally I would not pay for backup software. The advise from u/cubic_sq on doing periodig test recoveries is universal, do not skip on that.

Number one for me is: verify restores are in fact possible from reported good backups.

I use my own setup based on `dar`

https://github.com/per2jensen/dar-backup

Time capsule with everything needed to restore in 10 years: https://github.com/per2jensen/dar-backup-image

No joke - checked out a cheap way to store a little amount of data. Compared to the suggested 100GB/20$/year it looks like a good option.

And along the way the app collects various data about the phone and shares it with companies or organisations. That is at least how I understand the linked Google Play page. I would respectfully say no thank you to the "free" offer.

In DK this "Iomega 360GB USB 2.0, 360 GB, 2.0, 7200 rpm" goes for ~40$. Perhaps that is a way forward.

As part of every backup I take, some files are restored and compared to the "originals". That gives me some peace of mind. A short report is sent to a Discord channel.

I checked out your website, spend maybe 5 minutes:

Observations and thoughts:

- One has to pay up, with no way of testing out the software before purchase ?

- Is this closed source ?

- Is there any evidence the software actually delivers on the (many) promises ?

- The AI integration is followed by a big fat "AIs may fail, check yourself" - not really useful on an important job like restores.

Conclusion for me: I stick with my own solution.

I wish you good luck going forward.

I recently used rclone to upload ~ 1,5TB in 10GB filechunks.

Once done, the average upload speed was ~21 mega bytes per second, which translates to ~ 20 hours upload time.

could this work for you: https://github.com/lobaro/restic-backup-docker

Thanks for the heads up ! - I just checked my thunderbird configuration and it seems I fetch everything and store locally.

Also checked the backups, and the thunderbird mail storage in there 😄

I use refurbished Seagate EXOS disks - so far, after approx. 1 year, they perform as expected.

Update — June 2026

Since the original post the project has grown quite a bit, so a brief update.

v1.0 reached October 2025 :-)

The bash wrapper is retired. The Python version is the only one now.

What's been added since:

• PITR (Point-in-Time Recovery) — rebuild a consistent archive state from any point in the FULL/DIFF/INCR chain

• Metrics database — every backup run writes timing, outcome, slice count and archive size to a local SQLite DB.

• Datasette works well as a viewer

• Dashboard — HTML summary of recent backup runs

• Per-file restore test metrics — the verify phase samples files from the archive, restores them, and records pass/fail per file in the DB

• ~1100 test cases covering unit and integration tests, including real dar and par2 invocations against actual archives

Two types of OOM bugs fixed in 2026:

Worth mentioning because both were found through actual production failures on large archives.

1. The first surfaced over Christmas 2025 on a ~1 TB yearly FULL backup. The Python process itself was accumulating too much in memory — unbounded stdout buffering in the subprocess layer, a buffer += chunk pattern in list_contents() that grew proportional to archive size, and dar's full XML file listing being materialised as a Python list before sampling. All fixed by streaming properly and only keeping what is actually needed.

2. The second was this weekend on a 124 GB DIFF backup. A regression from January 2026 had changed par2 generation from per-slice to processing all slices in one command. For a 124 GB archive at 5% redundancy that meant par2 trying to hold a ~6 GB recovery matrix in RAM at once. Fixed by restoring the original per-slice loop. Peak par2 RSS is now ~360 MB per 10 GB slice regardless of total archive size — confirmed on a 107 GB test run this weekend.

Pre-release validation

The project now has a shell script that runs a full FULL+DIFF cycle of some of my media files before each release. It monitors peak RSS throughout, verifies par2 file naming and integrity, and writes a summary report. This would have caught the January regression before it shipped.

Status

Still actively developed, still used in production for my own media archive. If you are using dar and want a maintained wrapper with a serious test suite, it might be worth a look.

I run AIDE ( https://aide.github.io/ ) once a week. If it flags a lot of changed files - I know something is off and will have to dig into what is going on.

ok - thanks.

what if the 4 encrypted acronis files are encrypted by ransomware ?

I run AIDE once a week on important stuff I backup.
If suddenly those files start changing signatures AIDE will alert me and I know something is not right and can start taking action. The air-gapped backups should help me get back.

version 1.6.1 in two days - that is impressive speed