Because it doesn’t quit trying once you’ve started it, I’ve disabled it. Everything before that point involved creating the backup temp files which it did. I’m re-enabling, will post other components of the log shortly.
0000.000 () Opened log file at time: Sat, 22 Jun 2013 09:53:12 -0700
0000.002 () UpdraftPlus: 1.6.23 WP: 3.5.1 PHP: 5.2.6-1+lenny16 (Linux XXXXXXXX 2.6.35.4-rscloud #8 SMP Mon Sep 20 15:54:33 UTC 2010 x86_64) Server: Apache max_execution_time: 900 memory_limit: 192M ZipArchive::addFile : Y
0000.004 () Free space on disk containing Updraft’s temporary directory: 54776.6 Mb
0000.005 () Deleting old temporary file: backup_2013-06-20-1657_XXXXXXXX_cd8a6e2495f6-uploads.zip.tmp
0000.007 () Tasks: Backup files: 1 (schedule: manual) Backup DB: 1 (schedule: manual)
0000.008 () Processed schedules. Tasks now: Backup files: 1 Backup DB: 1
0000.011 (0) Backup run: resumption=0, nonce=ad081c96296d, begun at=1371919992 (0s ago), job type=backup
0000.012 (0) Scheduling a resumption (1) after 300 seconds (1371920292) in case this run gets aborted
0000.014 (0) Creation of backups of directories: beginning
0000.017 (0) Beginning creation of dump of plugins
0000.018 (0) Checking if we have a zip executable available
0000.019 (0) Testing: /usr/bin/zip
0000.020 (0) Testing: /bin/zip
0000.021 (0) Testing: /usr/local/bin/zip
0000.021 (0) Testing: /usr/sfw/bin/zip
0000.022 (0) Testing: /usr/xdg4/bin/zip
0000.023 (0) Testing: /opt/bin/zip
0002.126 (0) Zip::addFile apparently failed – retrying with PclZip
0012.903 (0) Created plugins zip – file size is 36571 Kb in 12.9 s (2838.3 Kb/s)
0012.905 (0) Beginning creation of dump of themes
0015.152 (0) Created themes zip – file size is 11100.7 Kb in 2.2 s (4944.1 Kb/s)
0015.154 (0) Beginning creation of dump of uploads
0000.000 () Opened log file at time: Sat, 22 Jun 2013 09:58:17 -0700
0000.001 () UpdraftPlus: 1.6.23 WP: 3.5.1 PHP: 5.2.6-1+lenny16 (Linux xxxxxxxx 2.6.35.4-rscloud #8 SMP Mon Sep 20 15:54:33 UTC 2010 x86_64) Server: Apache max_execution_time: 900 memory_limit: 192M ZipArchive::addFile : Y
0000.002 () Free space on disk containing Updraft’s temporary directory: 54731.2 Mb
0000.003 (1) Backup run: resumption=1, nonce=ad081c96296d, begun at=1371919992 (305s ago), job type=backup
0000.004 (1) Scheduling a resumption (2) after 300 seconds (1371920597) in case this run gets aborted
0000.006 (1) Creation of backups of directories: had begun; will resume
0000.010 (1) Beginning creation of dump of plugins
0000.011 (1) backup_2013-06-22-0953_XXXX_ad081c96296d-plugins.zip: this file has already been created
0000.012 (1) Beginning creation of dump of themes
0000.012 (1) backup_2013-06-22-0953_XXXX_ad081c96296d-themes.zip: this file has already been created
0000.013 (1) Beginning creation of dump of uploads
0000.014 (1) Checking if we have a zip executable available
0000.015 (1) Testing: /usr/bin/zip
0000.016 (1) Testing: /bin/zip
0000.016 (1) Testing: /usr/local/bin/zip
0000.017 (1) Testing: /usr/sfw/bin/zip
0000.018 (1) Testing: /usr/xdg4/bin/zip
0000.019 (1) Testing: /opt/bin/zip
0022.334 (1) Zip::addFile apparently failed – retrying with PclZip
It does quite trying, once it gets up to (10).
I must have run out of patience around 8 then.
Hmmmm. Does the same happen on a new backup run? I’m wondering if there was a freak timing error that is the cause. (Would still need fixing, of course – but I want to know if it’s that rather than something else).
David
It has happened every time I run it – once the rackspace connect was handled that is.
Re-checking the code, I can see part of the problem.
PHP’s built-in zip-file handling fails; so UpdraftPlus re-tries, using the in-PHP-code zip file handler, PclZip. That’s this line:
Zip::addFile apparently failed – retrying with PclZip
PclZip is all-or-nothing; you can add a whole directory to the zip, or have it fail. Most likely nothing is logged after that because it times out. (PHP’s built-in zip-file handling doesn’t have this problem).
So what we want to work out is why we get “Zip::addFile apparently failed”. There are two possibilities that trigger that error. I’ve tweaked the development version so that we can distinguish from the log which one it is – that’ll help. Please can you update again to the development version, and the post a new log:
http://updraftplus.com/faqs/devversion – should show as 1.6.26 or later after installation.
Many thanks,
David
Hi Dirty Bill,
I’ve just made a further change that may also solve your situation – please update – http://updraftplus.com/faqs/devversion – should show as version 1.6.27 or later.
David
Sorry – I spotted a logic error in the latest tweak – if you’d started updating, then please do so again, and verify that you’ve got version 1.6.29 or later.
