What’s wrong with SpiderOak backup

In my last investigation of backup options for Linux, I had to conclude that SpiderOak One Backup is still the best option. I no longer hold that opinion. Before I select an alternative, I want to write down the most visible issues.

In addition to what I have mentioned in the last post, SpiderOak One Backup has the following major issues:

• SpiderOak servers were unavailable for more than a month in the spring of 2024 for a large fraction of users. Nobody was informed. Why have a backup that silently stops working and the company takes more than a month to fix it?
• Restore requires an order of magnitude more RAM than incremental backup, which means that you might encounter unrecoverable restore failure on a computer that ran backups without any warnings. Why have a backup that cannot be guaranteed to be restorable?
• The high RAM usage is due to an architectural flaw that makes SpiderOak load file lists into memory during initial setup. I have 3.5M files and I couldn’t get SpiderOak to launch on a computer with 4GB RAM even though I wanted only partial sync.
• If you try to work around the RAM usage by adding lots of zram swap, SpiderOak will declare “connection lost” sometime during the setup and restart the whole hours-long process from the beginning. This will repeat in cycles until you give up.
• As a consequence, 2TB and 5TB plans are not usable unless your data consists mostly of large video files.
• Even when it works, restore is incredibly slow. 1+ day just to get the restore started is a major loss of productivity. Slow restores also interfere with HW upgrades.
• A key feature I was looking for is time travel. While SpiderOak can technically restore older versions of files, it is only possible to do so for individual files rather than whole directories.
• Another key feature is real-time backup, but that does not work out of the box unless you have only a limited collection of files. I had to tweak fs.inotify.max_user_watches to get it working.
• There’s built-in sync feature, but its security implications make it an anti-feature. Any computer can enable sync to and from any other computer, so all my devices must trust each other, but I personally do not trust my Android phone nor whatever is installed in virtual machines, so separate sync software must be used for those.
• The UI does not support high-DPI displays, which is a joke these days.
• It’s closed-source, which is frowned upon among Linux users.

I will be therefore ditching SpiderOak and looking for opensource alternatives. Hopefully, I can come up with something that can be recommended to less patient users.