• Resolved deeveedee

    (@deeveedee)


    First, let me say that I love your plugin. Great job!

    My website is hosted on a GoDaddy C-Panel shared hosting plan. I’m running WP 4.8.2, UpdraftPlus 1.13.1 and Comet Cache 170220.

    Recently (not sure when this started), whenever I manually perform an UpdraftPlus backup, the backup ‘freezes.’ I can resume the frozen backup by clicking Comet Cache’s ‘Clear Cache.’ Now that I know how to ‘fix’ the problem, it’s not critical, but I thought this might help other experiencing similar issues.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Contributor DNutbourne

    (@dnutbourne)

    Hi,

    Thank you.

    Are you using the Pro version of Comet Cache, with caching for logged in users in WP Admin enabled?

    Thread Starter deeveedee

    (@deeveedee)

    @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.

    Plugin Contributor DNutbourne

    (@dnutbourne)

    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.

    Plugin Author David Anderson / Team Updraft

    (@davidanderson)

    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?

    Thread Starter deeveedee

    (@deeveedee)

    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 7 years, 5 months ago by deeveedee.
    Thread Starter deeveedee

    (@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)
    
    ...
    Plugin Contributor DNutbourne

    (@dnutbourne)

    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.

    Thread Starter deeveedee

    (@deeveedee)

    @dnutbourne – I will provide the info you requested later this week. Thank you very much for your great support.

    Thread Starter deeveedee

    (@deeveedee)

    @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.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Updraft Plus compatibility with Comet Cache’ is closed to new replies.