sanity backup failing on DreamHost

Hi @shibmz,

Thank you for reaching out, and thanks for sending over your log.

Since there were no error messages to indicate what caused the process to terminate, it’s tough to say for sure exactly what caused the failure. This is normally due to exceeding some limitation on your hosting account, for example CPU usage, Execution Time Limit, or Disk I/O etc.

What stands out to me is is looks like you may be hitting memory limit.

[2024-01-18 11:44:39 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 41146536 (39.24 MB) / 41879136 (40 MB)

It looks like your right at your peak and that’s likely causing the backups to fail. Dreamhost should be able to increase your memory limits if your hosting plan allows. I would contact them for further assistance with that and then reattempt the backup.

Another thing to try is to enable the Filelist Analysis option in the Total Upkeep > Settings > Backup Process menu. This will show you if there are any “huge” files in your website that might be using up unnecessary space in your backups. Be on the lookout for any temporary files?*.tmp?and delete all of those.

Also, look for any big files with:
find . -type f -size +100M and delete any of those you don’t think need to be there.

While you’re on this menu screen, also try reducing the Compression Level setting. Start with level 0, and if that succeeds try 3, and so on until you find the sweet spot. This will increase the total size of your backup archive, but reduces CPU usage and execution time.

Another tactic to try is to exclude the wp-content/uploads/ directory from your backup, since that’s normally the directory that takes up the most disk space.

I hope this helps, please let us know if there’s anything else we can answer for you!

Thanks, Brandon (?).

Please note that my latest failed attempt (for which I posted the log above) included only *.txt files and no database tables, so many of your suggestions wouldn’t apply. I’m wondering whether there’s even a point in trying to reduce the compression level in this case. However, I decided to check how many *.txt files there were (224) and how big they were (max ~150 kb). In the process, I noticed a recursive symbolic link I’d set up as a temporary workaround after moving the website from a subdir up to the root. I suspect that may have something to do with this issue, if your file-scanning code is liable to get into an endless loop.

Detail: the website used to be a in a subfolder called wordpress, and since I moved it up and several references broke, I’d created a symlink wordpress -> . in the root folder. I’d already resolved the broken links, but had forgotten to remove the symlink.

Update: the sanity backup test (after removal of that recursive symlink) succeeded – hooray! I then tried a full backup, which almost worked:

...
[2024-01-18 22:17:34 UTC] Chunk closed in 6.9668281078339 seconds. 64% complete closing
[2024-01-18 22:17:34 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56722552 (54.09 MB) / 62494256 (60 MB)
[2024-01-18 22:17:38 UTC] Chunk closed in 3.4804148674011 seconds. 68% complete closing
[2024-01-18 22:17:38 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56722552 (54.09 MB) / 62494256 (60 MB)
[2024-01-18 22:17:43 UTC] Chunk closed in 4.7579138278961 seconds. 73% complete closing
[2024-01-18 22:17:43 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56722552 (54.09 MB) / 62494256 (60 MB)
[2024-01-18 22:17:46 UTC] Chunk closed in 3.314975976944 seconds. 77% complete closing
[2024-01-18 22:17:46 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56722552 (54.09 MB) / 62494256 (60 MB)
[2024-01-18 22:17:50 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:17:57 UTC] Chunk closed in 11.547420978546 seconds. 82% complete closing
[2024-01-18 22:17:57 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56722552 (54.09 MB) / 62494256 (60 MB)
[2024-01-18 22:18:04 UTC] Chunk closed in 6.1026511192322 seconds. 86% complete closing
[2024-01-18 22:18:04 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56722552 (54.09 MB) / 62494256 (60 MB)
[2024-01-18 22:18:17 UTC] Chunk closed in 13.701091051102 seconds. 91% complete closing
[2024-01-18 22:18:17 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56722552 (54.09 MB) / 62494256 (60 MB)
[2024-01-18 22:19:50 UTC] Backup process running: No

I tried reducing the compression level from 6 to 3, and oddly that failed even earlier in the process:

...
[2024-01-18 22:35:11 UTC] Chunk closed in 13.794708967209 seconds. 41% complete closing
[2024-01-18 22:35:11 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 57463336 (54.80 MB) / 69102560 (66 MB)
[2024-01-18 22:35:17 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:35:22 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:35:29 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:35:35 UTC] Chunk closed in 23.801074981689 seconds. 45% complete closing
[2024-01-18 22:35:35 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 57463336 (54.80 MB) / 69102560 (66 MB)
[2024-01-18 22:36:11 UTC] Backup process running: No

I tried again with a compression ratio of 0, and that succeeded!

...
[2024-01-18 22:43:36 UTC] Chunk closed in 7.8543620109558 seconds. 95% complete closing
[2024-01-18 22:43:36 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56417824 (53.80 MB) / 62189592 (59 MB)
[2024-01-18 22:43:38 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:43:43 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:43:46 UTC] Chunk closed in 10.665627002716 seconds. 100% complete closing
[2024-01-18 22:43:46 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 56417824 (53.80 MB) / 62189592 (59 MB)
[2024-01-18 22:43:47 UTC] Finished closing the zip file.
[2024-01-18 22:43:47 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 55669656 (53.09 MB) / 62189592 (59 MB)
[2024-01-18 22:43:47 UTC] Starting to add db dump to the zip file.
[2024-01-18 22:43:47 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 55669656 (53.09 MB) / 62189592 (59 MB)
[2024-01-18 22:43:47 UTC] Finished adding db dump to the zip file.
[2024-01-18 22:43:47 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 55669712 (53.09 MB) / 62189592 (59 MB)
[2024-01-18 22:43:47 UTC] Archiving of files complete!
[2024-01-18 22:43:47 UTC] Archive filepath / size: /home/.../boldgrid_backup/boldgrid-backup-www.site.com-xyz.zip / 671473617 (640.37 MB)
[2024-01-18 22:43:47 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 55669656 (53.09 MB) / 62189592 (59 MB)
[2024-01-18 22:43:47 UTC] Starting sending of email...
[2024-01-18 22:43:48 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:43:49 UTC] Sending of email complete! Status: 1
[2024-01-18 22:43:53 UTC] Backup process running: Yes (pgid = 447141)
[2024-01-18 22:43:56 UTC] Backup complete!
[2024-01-18 22:43:56 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 55834336 (53.25 MB) / 84064256 (80 MB)
[2024-01-18 22:43:56 UTC] Backup complete!
[2024-01-18 22:43:56 UTC] Memory usage - limit / current / peak memory usage: 1073741824 / 40678336 (38.79 MB) / 84064256 (80 MB)

For completeness’ sake, I also tried level 2 and level 1 (level 2 failed relatively quickly, and level 1 got to 91% and has been stuck there for almost an hour, so I’m assuming it will time out and announce failure eventually).

Thanks again for your suggestion to try adjusting the compression level, which turned out to helpful indeed!

I do think you should check your plugin’s code for how it handles recursive symlinks, and adjust it to avoid falling into infinite loops when they exist.

Thanks for your reply @shibmz, and my apologies if my response was excessive. I’m happy to hear you were able to complete a sanity check backup after removing your recursive symlink. That at least lets us know that a backup can be taken. We’ll definitely have to try replicating this in our own environment and if we can pin point an error we’ll address it in a future patch release.

Have you reviewed the Preflight check status from your Total Upkeep dashboard Total Upkeep < Preflight Check? The functionality test might reveal problem areas that are preventing backups from completing properly.

If your check results in a fail if you can copy/paste your failing metrics into the thread here so that we can review them and help you determine the best course of action to address the errors.

Thank you, We’re looking forward to assisting you further with this!

Hi @shibmz,

We haven’t heard from you in a while and were curious to know if you’re still experiencing this issue? If so, please let us now and we can continue troubleshooting right away.