Hi,
Thank you.
Are you using the Pro version of Comet Cache, with caching for logged in users in WP Admin enabled?
@dnutbourne – I am using the free version of Comet Cache, so I believe that caching is disabled for logged in users (not an option for the free version). Very good question. Makes me wonder why clicking ‘Clear Cache’ works the way it does.
Let me know if you need any additional information.
Hi,
Please could you send us a copy of the latest backup log where this occurred? This can be found in the UpdraftPlus Existing Backups tab.
The contents will be too long to post here directly, but you can use an online service such as Pastebin, and post the link here.
What is leading you to think that clearing the cache is doing anything? Backups don’t “freeze” as such; webservers kill off PHP processes, and UpdraftPlus starts a new one after a pre-defined time interval. Does something different happen if you *don’t* clear cache, and instead just wait 5 minutes?
If I don’t clear the cache, the backup does not resume on its own (although I did see multiple backup wait and restart messages). I waited for what seemed like a long time, but I wasn’t counting the minutes. What I observed is that clearing the cache unfroze the backup which then finished immediately.
Could this have something to do with limited memory and I/O resources. My PHP memory is 512M and I/O is limited in the shared hosting environment.
Or possibly could clearing the cache free memory that is then available for the backup?
-
This reply was modified 8 years, 6 months ago by
deeveedee.
@dnutbourne,
The portion of the log where the backup “froze” is below. Clearing the cache immediately unfroze the backup and it continued to completion. Directories have been removed from this log.
0917.573 (3) Scheduling a resumption (4) after 300 seconds (1508084735) in case this run gets aborted
0917.694 (3) Checking if we have a zip executable available
0917.699 (3) Zip engine: found/will use a binary zip: /usr/bin/zip
0917.700 (3) Creation of backups of directories: had begun; will resume
0917.701 (3) Beginning creation of dump of plugins (split every: 400 MB)
0917.711 (3) File exists (xxxxxx_230310d0c27d-plugins.zip.tmp), but was apparently not modified within the last 30 seconds, so we assume that any previous run has now terminated (time_mod=1508084258, time_now=1508084436, diff=178)
0918.743 (3) xxxxxx_230310d0c27d-plugins.zip.tmp: Zip file already exists, with 5552 files
**** Backup frozen. Cleared Cache – Backup resumed ****
0922.009 (3) Total entities for the zip file: 856 directories, 5552 files (0 skipped as non-modified), 85.2 MB
0922.013 (3) Zip: xxxxxxx_230310d0c27d-plugins.zip.tmp: 100 files added (on-disk size: 32322.8 KB)
0922.014 (3) Zip: xxxxxxx_230310d0c27d-plugins.zip.tmp: 200 files added (on-disk size: 32322.8 KB)
0922.016 (3) Zip: xxxxxxx_230310d0c27d-plugins.zip.tmp: 300 files added (on-disk size: 32322.8 KB)
...
Hi,
The fact that the log does not show a large gap in the timestamps, suggests that this may only be affecting the front-end output (i.e. the progress display). The backup itself may be running in the background.
Please could you check how many seconds the backup takes to complete (from the final entry in the log), and then leave a fresh backup approximately that long without clearing the cache. Then, check if the backup files have been uploaded to the remote storage location, even if the progress bar has not advanced.
@dnutbourne – I will provide the info you requested later this week. Thank you very much for your great support.
@dnutbourne,
I started a backup and it did complete on its own (without me ‘clearing cache’). I suspect that clearing the cache just gave me something to do while I was waiting. Backups take much longer than I’ve experienced before, but I suspect that this is due to resource limiting in a GoDaddy shared host (CPanel).
0000.000 (0) Opened log file at time: Fri, 27 Oct 2017 17:37:16 +0000
0706.474 (2) The backup apparently succeeded and is now complete
Thank you for your support and your great plugin.
