Debugging Snapshot Process

I have configured Snapshots to backup tables and files sending them to Dropbox. I am able to see the "Item scheduled to run" when I manually start the job. It appears the file is not being placed in the snapshot folder nor is it being sent to Dropbox.

How do I go about debugging the process?

Here are my server settings:
WordPress Version 3.5.1
PHP Version 5.3.14
MySQL Version 5.0.96
Is Multisite Yes, Number of Sites: 2
WP_CRON Snapshot uses WP_CRON to run automated backups. If you have disabled WP_CRON via your wp-config.php you will not be able to schedule snapshots.
WP_CRON Enabled.
_SESSION Snapshot uses _SESSIONS to store temporary information about database tables and files during the backup and restore processing. Sessions are a default part of PHP.
Session save path:
Session save path is empty. This may be ok. Try running snapshot manually.
Folder Permissions Writable (0755) – /var/chroot/home/content/74/9440274/html/backups/snapshots/
Writable (0755) – /var/chroot/home/content/74/9440274/html/backups/snapshots/_backup
Writable (0755) – /var/chroot/home/content/74/9440274/html/backups/snapshots/_locks
Writable (0755) – /var/chroot/home/content/74/9440274/html/backups/snapshots/_logs
Writable (0755) – /var/chroot/home/content/74/9440274/html/backups/snapshots/_restore
PHP runtime information
Display Errors 1
Error Reporting 4983 - E_ERROR, E_WARNING
Magic Quotes 1
Max Execution Time (seconds) 30 The value displayed can be adjusted by Snapshot PHP scripts.
Memory Limit 64M - WP_MEMORY_LIMIT defined by WordPress wp-config.php.
Open Basedir Off
Safe Mode Off
ZLib Compression Off

  • Paul

    @brett, When you run a manual snapshot does it complete? Can you provide a screenshot of the Snapshots > All Snapshots listing? In the Archives folder do you see the .zip file listed?

    From your System Info output I do see the following

    Session save path:
    Session save path is empty. This may be ok. Try running snapshot manually.

    You need to check your PHP setup. Your session save path should NOT be empty.

  • brett

    Joe, thanks for the follow up. The configuration was changed to the recommended settings and confirmed that the settings were loaded appropriately. We are still not seeing output from the snapshot job. Are there any logs I can review or would I see error messages through the GUI?

    Paul, I do not see the file under the archive column. This column is blank. Where do I update the "Session save" path?


  • Paul

    Okay, I figured out that I needed to add session.save_path = 'my path' and it appears to have written a zero byte session file named "sess_52fue2vhrbf7rl81ksjgusip47" to the session.save_path. It appears the archive has not been written yet or it stopped mid process.

    Again, the PHP setup is really outside of my support area. This is generally something setup by your hosting. Joe might have some input. There are PHP functions used by Snapshot to read/write from the current user session. The mechanics of this actually being converted to a physical file is managed as part of PHP and outside of Snapshot.

    One other thing to look into to. Snapshot will create a folder on your site where it stores the archive, logs etc. This folder is /wp-content/uploads/snapshots/ The final archive will be saved into this top folder. You will see 'working' folders like _backups' which is where the temp database dumps are staged and added to the working zip files.

    you should also see a folder /_logs/ within this folder are processing logs for the given snapshot configuration. The beginning number will match the configuration item number. Can you open the latest file and see if any errors are reported.

    Within wp-admin under Snapshots > Settings toward the bottom is a section for Error Reporting. Just set all the 6 checkboxes.

    Also on that page is a section Memory Info. Set this to something like 256M. By default it will use your WordPress internal memory which is 40M for single and 64M for Multisite. You can also increase the memory via your wp-config.php

    Also, on the Settings page the last section controls which Zip library to use. It should default to PclZip which is a zip library provided from WordPress. You can try switching to ZipArchive which is a native PHP set of functions.

    But I really thin your issue is the session path.

  • brett

    Okay, I'm writing successfully to the local server drive. I was missing "[DEST_PATH]" in the respective field for Directory. I see the local archive was written successfully but I'm not seeing it being written successfully to Dropbox. Is there a mechanism for logging these jobs? I'd like to read the standard output to see where the job is failing.

    Thanks again for your continued assistance.

  • Paul


    So what you should be seeing on the All Snapshots listing is the zip file in the Archive. Can you confirm that the status (last line of that column read '1 Pending'? Basically, there is a status for the archive creation and another for the send of the file to the remote.

    The current implementation of Snapshot does the backup local processing and sending of the archive to the remote destination as two distinct steps. The main reason is since the manual archive create processing is browser driven there is potential that a longer running process like sending the file to the remote system will timeout.

    So the send to destination process is done as a WP_CRON process. On the Snapshots > All Snapshots listing in the top-right of the page you should see the local time and below that the time for the next send cycle. You should be able to just reload the listing a few time to update the time. It should be setup to run from WP_CRON every 5 minutes.

    Another option is on All Snapshot listing in the first column you can hover the name and click the run now. This should produce a new archive then kick into the sending process.

  • brett


    I never get a status of "1 Pending". I actually never see a status with the exception of the first job that I ran which saves the zip file on the local file system. When this job ran, I did see the progress bars associated with the database tables and file backups. After the progress bars collectively reached 100%, the status on the "All Snapshots" screen updated with an accurate completion status.

    Please see the attached screenshot that illustrates the aforementioned behavior. With regards to the remote Dropbox job, I'm still not seeing the requisite zip file on the file system nor am I seeing an updated status that the job failed for any reason on the "All Snapshots" screen. This job leveraged the "Run Now" functionality.

  • Paul

    No, one job does not cancel the other out. If you setup the Snapshot interval to be daily, say at 1am. You can still run the snapshot manually during the day as many times as needed.

    The problem you will most likely run into is that the Snapshot backup does not occur. The main reason for this is you don't have enough front-end traffic on your site at the time the scheduled snapshot is to run. So basically Snapshot interfaces with the WordPress scheduler WP_CRON. IT is up to WP_CRON to actually kick off the processing. So best thing you can do is setup a cron via your hosting to call the wp-cron.php in your site root.

  • aecnu

    Greetings brett,

    Thank you for your input and working through this with us.

    It appears that once you got everything configured up things started to run as they should though we cannot control the traffic/cron item that Paul had mentioned, we can see what is indeed going on with the cron using something like the Cron View plugin.

    Please advise if your scheduled crons are now happening as anticipated or what the results for crons are using the suggested plugin.

    In any event, have a GREAT upcoming weekend!

    Cheers, Joe

  • brett

    Hi Joe,

    All seems to be working now with the exception of the Dropbox upload. I'm getting the following log output:

    2013-01-30 02:47:28: finish:
    2013-01-31 19:54:21: Sending Archive: 75.72M
    2013-01-31 19:54:21: Destination: dropbox: dropbox (brett)
    2013-01-31 19:55:44: Sending to Dropbox Directory:disappointed:
    2013-01-31 19:55:44: ERROR: Forbidden. This could mean a bad OAuth request, or a file or folder already existing at the target location.

    The destination points to the default folder which exists on dropbox and the dropbox record on the "All Snapshot Destinations" shows as authorized. I'll keep you posted as my debugging continues.


  • Paul

    @brett, Have seen this message from other members. But have not been able to debug this myself. Some things to try.

    1. Try re-authorizing your Dropbox destination. If you edit the current Dropbox destination you will see a single checkbox. Set this checkbox and submit the form. This will regenerate the access keys used by Snapshot.

    2. Try sending the snashot archive to a sub-folder.

    I'll try and dig into the Dropbox forums and see if this was reported and solved somehow.

  • brett

    Hi Joe, Paul,

    I've attempted to resolve the issue by re authentication and the it appears to have been successful. I also attempted to create a subdirectory and configure the job. I setup a job that takes a snapshot of the database only and it successfully backed up and transmitted to Dropbox. I continue to have issues when the snapshot is over 75MB which includes database and files. The error message continues to be:

    2013-02-08 01:00:15: Sending Archive: 76.27M
    2013-02-08 01:00:15: Destination: dropbox: dropbox (brett)
    2013-02-08 01:01:25: Sending to Dropbox Directory:disappointed:
    2013-02-08 01:01:26: ERROR: Forbidden. This could mean a bad OAuth request, or a file or folder already existing at the target location.
    2013-02-08 02:00:07: Sending Archive: 76.27M
    2013-02-08 02:00:07: Destination: dropbox: dropbox (brett)
    2013-02-08 02:01:31: Sending to Dropbox Directory:disappointed:
    2013-02-08 02:01:31: ERROR: Forbidden. This could mean a bad OAuth request, or a file or folder already existing at the target location.


  • aecnu

    Greetings Brett,

    We have not heard back from you as to the status of this issue.

    If you are still having an issue please let us know so that we may try to get you fixed up as soon as possible by choosing to check mark this ticket as unresolved below and posting any new errors or symptoms you are noticing.

    This action will also bring your ticket up front back in plain view again within the ticket system.

    Thank you for being a WPMU DEV Community Member!

    Cheers, Joe

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.