Improve Clone/Backup/Restore Speed

[d19dotca]

@robi This likely has to do with the remote-nature of your backups. Using a mounted disk allows cloning to be super quick. I know there was room for improvement before and changes later made to allow for faster backups, but not certain if that impacts the restores too.

[girish]

Is this rsync or tgz? You can now configure the Download concurrency in Advanced Settings.

[robi]

@girish currently it's set to rsync and default concurrency of 10.

Increasing concurrency isn't as useful when all the files are fetched one by one. It's too many requests.

Object storage should NOT be treated like a filesystem because it isn't one.

The large object should be requested in its entirety.

This is something I worked on at IBM as few people on the planet understood this concept.

As for a clone, it would be much faster now to install a new copy of the same app, and apply the few deltas. But that's not what's happening.

How can we speed things up?

[girish]

@robi said in Improve Clone Speed:

The large object should be requested in its entirety.

Mmm, I am not following. What do you mean by large object? If the files are stored separately as rsync does, they have to be fetched separately as well.

As for a clone, it would be much faster now to install a new copy of the same app, and apply the few deltas. But that's not what's happening.

That's honestly very complex (might even be impossible) since you have to delta databases, caches etc.

[robi]

@girish said in Improve Clone Speed:

Mmm, I am not following. What do you mean by large object? If the files are stored separately as rsync does, they have to be fetched separately as well.

Then I am definitely using the wrong method.

As for a clone, it would be much faster now to install a new copy of the same app, and apply the few deltas. But that's not what's happening.

That's honestly very complex (might even be impossible) since you have to delta databases, caches etc.

For a clone, it would be simpler to duplicate the database/caches, etc over the default install and not compare anything.

[girish]

@robi said in Improve Clone Speed:

For a clone, it would be simpler to duplicate the database/caches, etc over the default install and not compare anything.

Yes, good point And that's probably the solution to make things faster.. Currently, our clone system is tied to a backup. So, this feature request is "clone a live app" (i.e skip this backup stuff altogether).

[robi]

@girish are you aware of the incremental feature of tar ?

This feature is provided by tar via an argument -listed-incremental=snapshot-file where a "snapshot-file" is a special file maintained by the tar command to determine the files that are been added,modified or deleted.

That will speed things up.

[yusf]

@robi Would this mean that we can have incremental, encrypted tar backups? That would be amazing as it would solve all my backup woes by combining the best of both methods.

[robi]

@yusf that's probably a better question for @girish but likely yes.

[jdaviescoates]

@robi @yusf @girish

More info here:
https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html

And here:
https://serverfault.com/a/569668

But perhaps what we really want is Borg?
https://borgbackup.readthedocs.io/en/stable/

It's recommended in that Server Fault post, but also when I asked Hetzner about backups I can download (you can't download backup from their native backup solution) to store off-Hetzer, they suggested I use it, here is their guide:

https://community.hetzner.com/tutorials/install-and-configure-borgbackup

But that's ^ all a bit too technical for me. I use Cloudron so I don't have to bother with all that. So I'd love to just have Borg as a backup option on Cloudron

[Lonkle]

Incremental backups. I thought we had those already, but if we don't - we should vote to support them.

[jdaviescoates]

@Lonk said in Improve Clone/Backup/Restore Speed:

Incremental backups. I thought we had those already, but if we don't - we should vote to support them.

We do have them with the rsync option.

[necrevistonnezr]

Actually, rsync and rclone-ing the incremental backups - encrypted - to Onedrive has been very reliable for me the last years. rclone is such a fantastic tool.

[Lonkle]

@jdaviescoates I'm using .tgz with Backblaze right now since tgz was the default I didn't look into it. Should I switch to rsync for the benefit of incremental changes or are there cons like @robi is trying to solve (his cloning / restoring speed suggestions).

Is "Incremental TAR files" the best of both worlds, basically?

[marcusquinn]

@Lonk If you use rsync, use Wasabi as it has no ingress costs. Also, in Backblaze, check the lifecycle settings on all buckets to make sure you're not paying to insure infinite versions of versions, just change the setting for each in there to just store the latest.

[Lonkle]

@marcusquinn said in Improve Clone/Backup/Restore Speed:

@Lonk If you use rsync, use Wasabi as it has no ingress costs. Also, in Backblaze, check the lifecycle settings on all buckets to make sure you're not paying to insure infinite versions of versions, just change the setting for each in there to just store the latest.

I did have infinite versions on, thanks for saving me there, I owe ya!

[marcusquinn]

@Lonk Everyone does as the sneaky f***ers make it the default. Must have lost thousands of dollars before I found that where everyone else missed it.

[marcusquinn]

Wasabi don't make it the default though, and have a much better interface. I'm dropping Backblaze from my recommendations for S3 needs and only use if for personal machine backups which don't have all those extra costs.

[yusf]

@robi said in Improve Clone/Backup/Restore Speed:

This feature is provided by tar via an argument -listed-incremental=snapshot-file where a "snapshot-file" is a special file maintained by the tar command to determine the files that are been added,modified or deleted.

Have @girish or @nebulon seen this?

[jimcavoli]

Recently, I accidentally found myself studying this problem. I've relocated backups to GCS recently from DigitalOcean Spaces for one machine...suffice it to say I found the bottleneck in that process. Previously, it appeared to be some traffic management into spaces, and/or the fact that it was heading to the SFO2 region from NYC3 (you know...because...geography). After turning on backups into GCS in the awesome us multi-region automatic replication (nearline), it became very obvious that the main limiting factor was a 10MB/s cap on the disk speed at DO.

Seriously; here's their graph over the last 7 days for Disk I/O performance (it's pretty obvious where the backups are):

The main reason this even showed up is that GCS ingest is way faster from a bandwidth perspective:

Too bad I don't have the old Spaces graph to show as well, but suffice it to say, it wasn't great. So the GCS switchover actually moved the first bottleneck, getting at the main root of the issue.

I'll update on how things go one the server in question gets itself moved into a GCP instance - by my rough math, there should be a noticeable performance bump in at least backups, but likely systemwide once it transitions into the GCP volumes, which are rated at least 50% faster in the case of the small volumes, and in the big one (apps data), should have a network performance ceiling that is roughly 6x higher than the existing DO volumes. I know this is more on the production/operator side than the personal side of usage, and the problem of "throw more, bigger resources at it" is not one most folks can/would take on a NAS/local server and home internet connection, but it's some interesting data and an intriguing problem in any case.