Database Backup to S3 Wasabi

Hello there,

I am using Wasabi S3 as my host and I have a script which dumps the database into a file and backs it up using restic. It’s been working perfectly well for the first two weeks but every since then when I try to run restic snapshots It takes too long to load. I have around 30+ databases (each one is treated as a separate path) and they’re around 500GB in size. Wasabi has really good restore speed and restic works really well with importing the backups directly into local db when deploying local environments.

The problem became that after almost two months of running, twice a day for all databases there’s just too many snapshots. I’m doing a ‘restic prune’ command at the moment and it’s been running for 45 hours and is only at 66% completion.

100.00% 12402 / 12402 snapshots
found 358902 of 376415 data blobs still in use, removing 17513 blobs
will remove 0 invalid files
will delete 266 packs and rewrite 11986 packs, this frees 33.823 GiB

Is there a way to increase the speed of this? I have a grunty connection and the server is also grunty.

The prune has completed after ~55 hours, ‘restic snapshots’ command seems to be running fairly quickly now, most likely due to the cache. I tried running ‘restic prune’ not long after the initial one finished and it runs a lot quicker. I think I’ll setup an automatic task to run every few days to run ‘restic prune’. The databases are around 500GB in total, not individual ones. Any tips on improving speed would be appreciated :slight_smile:

I can guarantee you this is what took so long. Deleting packs is fast. Having to download parts of nearly 12k packs and re-upload the still-used blobs can indeed take a very long time.

Would it be more latency dependant or connection speed dependant? How big on average would 1 pack be? Do these get cached afterwards?

Sorry about the spam of questions, just trying to get more familiar with the software.

Mostly connection speed, I would think. Pack sizes vary in the 4-8MB range in my experience.

As long as the connection to the server is one or more long-lived TCP connections then TCP’s “slow start” should not be a problem. In your case it was likely just the sheer amount of data that had to be downloaded, decrypted, encrypted, and uploaded.

Oh then is it possible to join s3.connections with the prune command to increase the bandwidth used? I have a 1Gbps line for both up and down.

Most restic operations use two threads, I think. So setting this higher doesn’t really do anything. Sure, you allow the S3 client library to use more connections – but restic isn’t trying to make more connections in the first place.

Oh since its only limited to two threads, there’s nothing to indicate it would saturate all the additional connections. If that’s the case is there a setting to increase the amount of threads?

After some further research I found the following:

Which leads to this sub-repo:

I might wait for cbane to open a pull request to merge with master, then I’ll build of that…