I found this comparison between borg and restic, and it seems like most of these apply. (https://stickleback.dk/borg-or-restic/) seems like blogbackup and restic are very similar. Wish there were more docs though.
https://borgbackup.readthedocs.io/en/stable/changes.html
The downside of borg is that the target is only sftp and not directly to any of S3 and some other targets but there are online services that accept sftp.
On the other hand, restic is new and while this can sync towards many targets, the use of memory gets crazy after a while that my machine choked out of memory and these kind of stability problem is something not mentioned in the docs until you use it.
I've tried several others like duplicacy but this also has a memory problem and both restic and duplicacy seem to have trouble fixing it quickly.
When it comes to backup, I'd like to use more than 1 implementation toward different remote locations in case 1 of the implementation has corruption bugs to render the backup useless.
Trying out kopia to see if it does any better.
Also asuran seems promising but so far too early to test it out.
I would have used restic directly as a backend for BlobBackup had it not been for the awful prune operation. Downloads a ton of data everytime, prone to errors, and has to repack blobs. Compression would be nice too but they have nice dedupe so it would have been workable without.
This used to be (as in, from 2008 to 2018) difficult, one of my past companies made a good deal of money by offering an sftp gateway to S3. But AWS continues to do a great job commoditizing their complements, and tackled SFTP back in 2018 when they launched...
“... AWS Transfer for SFTP, a fully-managed, highly-available SFTP service. You simply create a server, set up user accounts, and associate the server with one or more Amazon Simple Storage Service (S3) buckets. You have fine-grained control over user identity, permissions, and keys. You can create users within Transfer for SFTP, or you can make use of an existing identity provider. You can also use IAM policies to control the level of access granted to each user. You can also make use of your existing DNS name and SSH public keys, making it easy for you to migrate to Transfer for SFTP. Your customers and your partners will continue to connect and to make transfers as usual, with no changes to their existing workflows.”
“You have full access to the underlying S3 buckets and you can make use of many different S3 features including lifecycle policies, multiple storage classes, several options for server-side encryption, versioning, and so forth.”
https://aws.amazon.com/blogs/aws/new-aws-transfer-for-sftp-f...
Because this did not exist for a decade, it seems most folks don’t know it exists today.
Just to turn SFTP on at AWS, you need to pay $0.3/h ($216/mo) and it even costs to upload not just for download at $0.04/GB. If you upload 100GB/day, that's also about $120/mo and if you're storing about 1TB you're paying like $350/mo for such little storage you get.
Who wants to pay for upload? At this point, why don't you just run EBS backed EC2 yourself?
With that kind of pricing, you'd get like 15TB of space at rsync.net and it doesn't leech users for bandwidth and on every parameters as AWS does. (If you use the borg discount, you get 40TB+ at $0.008/GB!)
And at what benefit does it bring for the price difference? I see no point in using it. Maybe people don't care to mention than not knowing it.