rsync.net and rclone are great, my brain understood restic easier than borg for local backups over usb (ymmv), and plain old `rsync --archive` is most excellent wrt preserving file mod times and the like.

There is 100% a difference between "dead data" (eg: movie.mp4) and "live data" (eg: a git directory with `chmod` attributes)- S3 and similar often don't preserve "attributes and metadata" without a special secondary pass, even though the `md5` might be the same.

You can do restic+rsync.net too if you didn't know. `rclone serve restic --stdio` on their end exposes the restic REST server over stdio, then with some fiddling of restic, telling it to use rclone as the repo address, and configuring its rclone args to actually invoke `ssh rsync.net`.

Again, with regards to my other comments, I am not affiliated with rsync, just rclone is cool. You can use the same trick with any host with ssh and rclone installed.

Rsync.net is really really good.

Just this weekend, my backup tool went rogue and exhausted quota on rsync.net (Some bad config by me on Borg.) Emailed them, they promptly added 100 GB storage for a day so that I could recover the situation. Plus, their product has been rock solid since a few years I've been using them.

> Emailed them, they promptly added 100 GB storage for a day so that I could recover the situation

Sorry to hear about your troubles. Hope your backup situation's sorted out?

Do you recall if you used a link like this to sign up?

https://www.rsync.net/signup/order.html?code=experts

If you don't, a good heuristic would be to see how much you pay per GB - if it's less than a cent, you probably did. The ones that come with support are typically a shade above per a cent per GB

Thanks for your kind words.

Just to clarify - there are discounted plans that don't have free ZFS snapshots but you can still have them ... they just count towards your quota.

If your files don't change much - you don't have much "churn" - they might not take up any real space anyway.

I don't think a lot of people know you also support Borg 1.x (if you don't absolutely correct me!)

It would be incredible if you started to look into S3 compatible object stores, unless you have made a business decision not to support it.

Thank You for providing an affordable option for self hosters.

We will continue to specialize in filesystem provision, not object storage.

However, we do support interoperating with block storage, such as 's5cmd':

https://news.ycombinator.com/item?id=44248372

... and, of course, rclone, which you can invoke remotely, on our end to move data between cloud accounts, etc.

Thank You for that link!

> not object storage

Happy to email you, if that's better, but is this because of unsustainable competition in the space or the tremendous volatility in consumption that object storage customers bring to the table?

I ask because in this current market, I would imagine investing in storage infrastructure is painful, but then I wonder, you are still in the storage infrastructure space anyways, so it likely has to do with the user behavior or user expectations or both.

Not supporting S3 (and block storage) is not a business decision - it is an ideological decision.

We want to live in a world of UNIX filesystems and we want those to be available in the modern "cloud" ecosystem.

Depending on the usecase, rclone can expose an S3 endpoint via `rclone serve s3` to route to another protocol, eg sftp.

I mention it not to shill rsync.net, but to shill rclone, because when I discovered it I was even more impressed with it.

Obviously having to run a command and apply some amount of plumbing is different to a service just providing that API at the outset so the applicability for users will differ but still, rclone is very cool!

Just a note of caution: sync != backup. When I was younger and dumber, I had my own rsync cron script to do a nightly sync of my documents to a remote server. One day I noticed files were gone from my local drive; I think there were block corruptions on the disk itself, and the files were dropped from the filesystem, or something like that. The nightly rsync propagated the deletions to the remote "backup."

D'argh.

Musing: There's a step further along the spectrum that echoes the relationship, where where "backup" != "backup that resists malware".

In other words, a backup can be degraded into a sync-to-nothing situation if the client logic is untrustworthy.