Support

You can definitely back up that site but it will be slow. The last person who reported a 100GiB backup told me it took just over 24 hours to complete. The slowest part of the process was, naturally, dumping the database.

Let's keep in mind some facts:

• Backups are single-core loads (to maintain consistency)
• The memory usage of a backup is limited to the maximum PHP memory and is typically much less. In practical terms, it's at most 16GiB plus twice the maximum of: chunk for processing large files, largest backup size (if using a remote storage engine which does not support chunking like FTP), or remote storage chunk size. With the default settings you're talking about less than 32MiB of memory.

So, your server is more than enough as we'll only need 1 core and well under 128MiB of RAM. We designed the backup to be frugal; your server is best used serving requests :)

Before going on, let's consider that you are never going to run this backup from the web (backend of the site, frontend legacy backup URL or backup API). You will only ever run this backup from the CLI if you value your sanity.

This means that the timing settings and fine tuning settings are essentially ignored so we don't comment on them.

The archiver options are your choice; you have plenty of memory on that server. Heck, you have more RAM and cores than my two dev machines combined. Just remember that increasing the size of large files means that you are reading this entire file in memory, compressing it, and writing it to disk. This will slow the backup down. Also remember that large files (over 1MiB by default) on a web server are typically already compressed in some form or another: images, videos, audio, PDF. So I'd leave these settings as-is.

Logs will take a LOT of space. Set the Log Level to None unless you run into a problem. This will create zero sized log files.

The only pertinent options are the remote storage engine ones. You have 100GiB of data and you are going to back it up. Do you have another 100GiB of working space to spare? If so, no problem, have the upload to the remote storage happen at the end of the backup. If not, use a remote storage engine which allows for immediate transfer of each backup archive part and set the part size for split archives to 2000MiB (just under 2GiB to keep on the safe side). The working space in the latter case is 2x the part size + 1MiB i.e. 4GiB.

That's all there is to it. It just takes a lot of patience because you are looking at a backup time between 17 and 25 hours, depending on the row structure of that 40GiB database!