Fatal error when backing up Files with Snapshot plugin

I just downloaded the Snapshot plugin, as I'd like a backup solution for my WordPress multisite. Of the 17 sites I currently have configured, I really only have content for two of them at the moment, and those are the two I'd like to backup.

I've managed to check all the settings and started the snapshot/backup, except when it gets to "Files," it hangs for a very long time before saying "Fatal error: Maximum execution time of 300 seconds exceeded in /home/******/public_html/wp-admin/includes/class-pclzip.php on line 2007" (I've also gotten it on 5485).

Reading here in the forums, it looks like this might have something to do with a memory limit configured somewhere?

In my Snapshot settings, I have "64M - WP_MEMORY_LIMIT defined by WordPress wp-config.php." and I have configured the Segment Size to be 5000.

  • Paul

    @Azurite, since you are hitting a timeout on the Files section I have to ask how large is your files section? And specifically which section for files are you backing up? You might want to try doing a backup for just media. Another for just plugins. etc. Sort of divide and conquer.

    The 300 second timeout is a very long time (5 minutes) and is generally enough time for the backup to finish. But if you have many very large files like videos these don't compress very well into an archive.

  • Azurite

    Hi there,

    I found out it was my themes that were the likely culprit in hogging up all the time of the backup, so once I unticked them, everything appeared to be fine. I was able to manually make a backup, although it never appeared in Dropbox, no matter how many times I refreshed my site or waited for Cron to kick in.

    I ended up manually downloading the file and moving it to Dropbox, and another manual backup that I attempted today also had the same issue. Is there another way to force it to show up on Dropbox, or would I be better off downloading the files to my local server?

  • Paul

    @Azurite,

    Glad you were able to figure that part out. As for the Dropbox issue are we sure the files are not being sent? What do the snapshot logs tell you about this?

    The remote destination send is handled via the WordPress scheduling system, WP_Cron. So when you run a manual snapshot but for a remote destination there is a background WP_Cron process which runs once an hour to check for files needing to be sent to remote destinations.

    The WP_CRon is somewhat tricky in that is needs front-end traffic on your site to 'kick off' the scheduler to run. Probably your best option is to setup a scheduled Snapshot. Initially set it for once hourly. You will then have the option chose the minute of the hour the task runs. Chose somewhere 2-3 minutes into the future. Then choose the Dropbox destination.

    When you save the snapshot item on the All Snapshots screen for that item you will see in the Interval column the next scheduled run for the backup. Just before this time is reached open a new browser tab/window and load your home page a few times. Flip back to the Snapshot screen and refresh. You should see the backup process start.

  • Azurite

    The Snapshot logs are interesting; for the one that I manually tried to start yesterday, the log cuts off after a certain file, but it looks as if it's going to start another file--it's just not there.

    See this example:

    2012-12-17 01:24:14: file: wp-content/plugins/add-to-any/icons/hi5.png
    2012-12-17 01:24:14: file: wp-content/plugins/add-to-any/icons/hubdog.png
    2012-12-17 01:24:14: fil

    That's exactly how it looks in the log.

    I'll try your suggestions for scheduling an hourly Snapshot and see how that works.

  • Azurite

    It was the one from the Archives column; I hadn't even noted there was a link on the word "Now" in the Interval column until you mentioned it!

    Looking at it now, it also says "Destination: 1 Fail" and "Sending to Destination 74% (abort)"

    The next scheduled one picked 8:05am tomorrow morning; is there no better way to schedule the hourly snapshots so it's a time when I'll actually be awake to try and refresh the page? (Not a morning person)

  • Paul

    @Azurite,

    Apologies for not seeing your last question. Wow 4 weeks is a long time to wait for an answer.

    The next scheduled one picked 8:05am tomorrow morning; is there no better way to schedule the hourly snapshots so it's a time when I'll actually be awake to try and refresh the page? (Not a morning person)

    Sure. when you edit the Snapshot items and set the Interval to hourly or once a day or whatever you should see a secondary option beneath the dropdown where you can select the minute of the hour, day of week, etc. See attached screenshot showing options when weekly is selected.

    As for the other comment in your previous response -

    Looking at it now, it also says "Destination: 1 Fail" and "Sending to Destination 74% (abort)"

    It is shows that progress percentage that means it is working.

  • Azurite

    Thanks for the points, Dean!

    I'm a bit concerned that Snapshot still isn't doing what it should be; my Dropbox folder that is the only destination I've specified only has a zip that I manually put there back in mid-December.

    I checked the Snapshot logs again this morning, and once more, I saw a percentage chugging along, but it's lower than it was when I checked earlier the same day (it was at 70-something% and is now at 3%). It does say "1 fail" under the logs, but I can't find a specific error message, just the same truncated file about where the view log cuts off.

    Worse, my host got in touch with me yesterday with this message:
    "The account [seventh] has a large amount of files being stored on the account in the directory ./public_html/wp-content/uploads/snapshots. These files are .zip files.

    ===========
    [/home/seventh/public_html/wp-content/uploads/snapshots]# du -h --max-depth=1
    16K ./_restore
    296M ./_logs
    800K ./_backup
    20K ./_locks
    99G .
    ==========="

    So is this some normal behavior of Snapshot while it's in use, or is it somehow backing up to a "Local folder" on my host, and not Dropbox as it should? Help!

  • Paul

    @Azurite,

    Worse, my host got in touch with me yesterday with this message:
    "The account [seventh] has a large amount of files being stored on the account in the directory ./public_html/wp-content/uploads/snapshots. These files are .zip files.

    So is this some normal behavior of Snapshot while it's in use, or is it somehow backing up to a "Local folder" on my host, and not Dropbox as it should? Help!

    First things first. When you go to Snapshots > All Snapshots how many configurations do you have defined? And what are the intervals. When you edit a Snapshot configuration in the section 'When to Archive' there is an input field 'Maximum number of local archives' please set this to some single digit number. Otherwise Snapshot will build the file local. This should clear up your disk space issue.

    Back on the Snapshots > All Snapshots listing. In the Archive column you should see a link for 'Archives: view'. Click on this will take you to a screen showing all the zip files for the given configuration. Please delete all but the last 3-5 items. Those older zip files are just taking up space. Should only care about that last fe archives.

    Back again to the Snapshots > All Snapshots listing. Again, how many total items in the listing and what are the intervals? Generally for the interval you want this to be daily or higher. If you have any that are hourly, of every 5 minutes for example then please set these to suspended. There is no use these running. Again just taking up space.

    Now on to your Dropbox issue. Once you have things cleaned can you post one of the log files so I can review. This could be anything. Might be a server (PHP) timeout. At this point not sure. Let me know.

  • Azurite

    First things first. When you go to Snapshots > All Snapshots how many configurations do you have defined?

    I have two (see screenshot).

    When you edit a Snapshot configuration in the section 'When to Archive' there is an input field 'Maximum number of local archives' please set this to some single digit number. Otherwise Snapshot will build the file local. This should clear up your disk space issue.

    I had it set to 0, I have now set it to 3. I hope this resolves things without impacting how Snapshot works.

    In the Archive column you should see a link for 'Archives: view'. Click on this will take you to a screen showing all the zip files for the given configuration. Please delete all but the last 3-5 items. Those older zip files are just taking up space. Should only care about that last few archives.

    Of the two Snapshots I had configured, only one actually had a number next to the Archives: view. I clicked on it; it's the same file (and date) as the one I already manually put on Dropbox, from December 12, 2012. That Snapshot is a manual one. The other one, the "Once Hourly" backup, has no archives at all, ever created. I'm fine with editing it to be daily or higher, but I've never seen any of these automated Snapshots kick in, which is why I was trying hourly, just to see if they ever worked.

    I'll post the log files if I see anything happen, I guess?

  • Paul

    Of the two Snapshots I had configured, only one actually had a number next to the Archives: view

    I guess I'm sort of confused on the comment previous from your hosting. It appears you only have the one manual zip file, correct? Other than that large file there are the files in /_logs/ which can manually be removed. But really does not appears Snapshot is creating backups for you so not understanding the issue from the hosting.

    So to be sure I understand the issues you have two. Correct me if I'm missing something:

    1. Your manually created snapshot item (the second in the screenshot listing) was created manually but the file never is delivered to the Dropbox destination.

    2. You have a scheduled snapshot item (the first item in the screenshot listing) which is set for hourly but have not ever produced a successful backup.

    Can you go to Snapshots > Settings and look for the section 'System Info' and provide a screenshot of that section. Please.

    Just reading through some of your previous comments in this threads it appears WP_CRON is running as times. as you mentioned you say the percentage of the transfer updating. So I'm not sure why the backup is not running. Still might be hitting a timeout or memory issue.

  • Azurite

    Hi there,

    I looked at the directories my host mentioned in their warning email, just to see what in the world could be taking up so much space, and sure enough, there are plenty of what appear to be snapshot ZIP files, each about 119 MB, starting 12/19/12 and going up to 1/25/13!

    Under the _backup folder, there are multiple folders with various numbered names. Some of them contain a snapshot-backup.zip file, but not all of them (there are only three files, but five folders).

    There are a ton of logfiles under _logs that look numerous enough to correspond to all the backups in the main snapshots folder, but I can't be sure.

    Attached is the screenshot of the Server Info, which I think you asked for; I didn't see any "System Info" under Snapshot > Settings.

    Just to clarify, yes, I have Dropbox set up as my only destination, but nothing seems to be in the default Apps/WPMU Dev Snapshot directory except for the zip I manually moved there myself after it was created in December. I'm fine with deleting the manual snapshot that created that zip, but it is the only one with any sort of logs; the other one I have now set to "Once Daily" and is scheduled for a few hours from now; I'll check and see if it does anything or if any logs are created.

  • Paul

    @Azurite,

    Ok. Well I'm for clearing up your server space right away. Then we can reset things and start over on Snapshot. So do this.

    1. in wp-admin under your Network Snapshot > All Snapshot delete all these in the listing. This should also remove most of the logs. Thought at the moment I'm not sure why you are seeing all the logs for the two existing entries.

    2. FTP into your server. Navigate to wp-content/uploads/snapshots and delete everything below that folder. Your FTP client should be able to recursively delete all the sub-directories. The Snapshot plugin will recreate these automatically.

    3. Edit your wp-config.php Increase the memory to 128M http://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP

    4. Once you have everything cleared go back to wp-admin Snapshots > Settings. Look for the section 'Memory Info'. Set this to 256M The difference between this memory setting and the one from #3 above is this step is specific to the Snapshot backup.Restore processing. I want to give it plenty of memory. The #3 memory is more for your general WordPress system.

    5. Go to Snapshots > Destinations. Delete the existing Dropbox entry. Then I would like for you to add a new one.

    6. Now go to Snapshots > Add New. Creates a small snapshot for just a few database tables. Not all of them. I'm trying to see if the error you are seeing is from the backup processing, the Dropbox transfer or both. So I want to just make a backup of 2-3 small tables from your system. No files. Set the interval to 15 minutes. And the destination as your Dropbox entry. Save the configuration.

    When you are done the archive should be created almost immediately. You should be able to see the progress. But it may happen too fast. In the Archives column of the All Snapshots listing you should see the log file and the status. Let me know what you see. And download the log file and post back to this thread. please.

  • Azurite

    Okay, I did everything you instructed.

    I couldn't attach the logfile because it's a denied extension, but it was very short, anyway. Here are the contents of the logfile from the snapshot:

    2013-01-28 04:22:02: init
    2013-01-28 04:22:02: table: non selected
    2013-01-28 04:22:02: file: non selected
    2013-01-28 04:22:02: memory limit: 256M: memory usage current: 29.75M: memory usage peak: 30M
  • Azurite

    I updated to the latest Snapshot plugin version and did as you suggested. So far, so good. I got notified via Growl almost immediately that the file had been uploaded to Dropbox; I checked the folder via the app on my computer, and it didn't show up until I went to the Dropbox icon and clicked on Recently Changed Files and found the ZIP file that had the last few letters/numbers that were different from the one manual ZIP I had uploaded back in early December.

    But...it showed up, so I think the plugin is working well now. I want to let it do at least a few more test runs before I either edit this Snapshot or make a new one that backs up more tables and things.

    What do you suggest: edit this one, or make a brand-new Snapshot and delete this one? I want to make one full backup to run immediately, and then maybe every two weeks or a month or so thereafter.

  • Paul

    What do you suggest: edit this one, or make a brand-new Snapshot and delete this one? I want to make one full backup to run immediately, and then maybe every two weeks or a month or so thereafter.

    Since you have been testing things. I would probably suggest clearing things out in Snapshot as well as your Dropbox. Then create a new Snapshot.

    As for the frequency you might consider creating multiple snapshot configurations. With one configuration being the database tables and a second being the files. Then depending on how often things change you can run the database configuration once a week and the files once every two weeks. Generally if your site goes down it is because of the database not the files.

  • Azurite

    Just to check, should I wait an extended period of time before expecting to see the Archives/a log file for each of these new (larger) Snapshots? I ask because I've oddly been seeing Growl notifications which look like alerts of uploaded Snapshots, except when I check my Dropbox folder under Apps > WPMU Dev Snapshot or the Dropbox.com web interface, the folder is empty.

    There are no archives YET under the All Snapshots, nor are there any when I click on "All Archives" from the bottom of an individual Snapshot's edit page. I just want to make sure that I'm not rushing it (I keep seeing the Next File Send as a time in the future, and even after that time has passed, nothing shows up in Dropbox, but I could be impatient; I imagine these archives take a while to create and upload).

    Thanks again!

  • Azurite

    So it looks like the issue isn't resolved after all; while we were able to successfully create and send an archive with just a few tables (no files) selected, I'm not able to get a Snapshot for the two NEW Snapshots I created: one for all my tables, and one for my files (minus all the themes).

    Should I be splitting these Snapshots up into smaller pieces, e.g. by site, or is there some way to find out just where it's timing out? I've been checking my Dropbox several times over the past few days, and still nothing is getting sent over.

  • Paul

    @Azurite, If you go to Snapshots > All Snapshots listing in the far right column, 'Archives' will show the last archive for each of the listings. This first line of output shows the archive filename and file size.

    If you click on the first link of the second line of the output it will take you to a new listing showing all archives for the specific snapshot configuration. The archive size is shown on the Size column.

    As for the issue of not sending I'm again at a loss. This could be anything with your hosting. Snapshot does not use much memory when sending files. unlike the actual backup process. There was another member having a similar issue with FTP and Snapshot a few weeks ago. He provided me access to his server and even though I setup a PHP script to run outside of Snapshot and outside of WordPress the process hit a timeout.

    Without any reported error from Snapshot or your server logs I can take this much further. We know the smaller archive work. Might be the solution it to backup each section individually.

    Or if you can provide access to your server and WordPress I can take a deeper look.

  • Azurite

    For the Snapshot I created for the database, the Archives section under Snapshot > All Snapshots has this information:
    snapshot-1359496703-130203-120139-32a0064b.zip (249.14kb)
    There is nothing listed for the other snapshot that I created for the files. I also tried clicking on the "All Archives" link for the files snapshot, but there's still nothing listed there, even though I found a substantially larger ZIP file on my server in the Snapshots folder (larger than the size of the database ZIP, that is).

    The database snapshot also says Destination: 1 fail. I looked at the logs and it appeared somehow I got un-authorized from my Dropbox, so I re-authorized it, but I'm not sure whether the send to Dropbox will happen automatically or if I have to run the script again to get it to try and send once more.

    If I were to contact my host about a possible timeout preventing the sending of the files, what would I say? I'd like to see if I can resolve it through them, if possible, before giving out server access.

  • Paul

    For the Snapshot I created for the database, the Archives section under Snapshot > All Snapshots has this information:

    Just to be clear that I understand what I'm seeing. One snapshot archive for one blog within your Multisite is 249Mb?? That seems quite large. Then again if this is the primary site maybe not.

    The database snapshot also says Destination: 1 fail. I looked at the logs and it appeared somehow I got un-authorized from my Dropbox

    Hmm. There was another member reported this same issue is random de-authorization. Not sure what is issue there. The authorization keys from Dropbox are stored into your wp_options table and used by Snapshot.

    If I were to contact my host about a possible timeout preventing the sending of the files, what would I say? I'd like to see if I can resolve it through them, if possible, before giving out server access.

    Well explain to then you are using a third party WordPress plugin that performed a backup of your site and sends the archive (include the size) to Dropbox via CURL. And for some reason the connection is dropping. We are not seeing reported errors in the plugin logs so need help to identify where this connection is being reset. Most likely they can point you to the access and error logs for your individual hosting.

    Should probably also review the PHP settings (php.ini) Here are some of the settings I've seen effecting Snapshot Note not all of these will effect your specific server configuration. Seems each hosting has different way of control

    upload_max_filesize - Make sure this is at least larger than your largest Snapshot file.
    post_max_size - Same as above

    max_execution_time - Make this at least 900 (15 minutes). Snapshot tried to increase this during execution. But some hosting prevents this from being changed by a running PHP script.
    max_input_time - same as above
    default_socket_timeout - same as above

  • Azurite

    Really quick, just to clarify the size of the snapshot in the logfile is in KILObytes, not MEGAbytes. It's not very large at all. That's the snapshot for just a single blog's databse tables (and not even one of my larger sites; while it is the primary site, it actually doesn't have as much content as some of my subsites, since the primary site is really meant to be a portal), since Multisite shows all the tables when I created the Snapshot (it says "All blog database tables").

  • Azurite

    Progress! I contacted my host and they got back to me fairly quickly; they made all the changes you recommended, after saying that in my PHP.INI file, "file size for upload or post was considerably lower, as well as the timeout settings."

    I clicked on "run now" for the database snapshot, and it ran perfectly AND sent to Dropbox!

    However, for the files snapshot, I saw it initially say "creating archive..." (no percentage, just the option to abort), and several minutes later, I clicked on Snapshots > All Snapshots, but there was nothing listed under the Archive header, and there are no new files in the WPMU Dev Snapshot folder on Dropbox. I don't think an archive has been created for that snapshot (yet?) but I'm also not sure how long to wait, seeing as there's nothing that indicates a creation of an archive but a failure to send, the way it did with the other snapshot before.

    I'm hopeful it'll just take some time, because the files are larger or something.

  • Paul

    @Azurite,

    Yeah, progress. Thank you hosting company. Most members I've dealt with their hosting has the standard line of "We don't support third party software'.

    On the File Snapshot when is it scheduled to run? Can you try clicking the 'run now' option? If anything try editing the item. Then on the Interval set the time to run just a few minutes in the future. Save the snapshot item then see if WP_CRON kicks it off.

    Keep me posted. Thanks.

  • Azurite

    Hi again,

    It's scheduled to run Twice Monthly, with the next one on 2/17. "Run Now" is what I did the last time, where it seemed like it was starting something, but it never seemed to finish creating an archive that could be seen by the plugin within Snapshot (though again, I did see a file in the wp-content/uploads/snapshots folder that was larger than the snapshot ZIP for the database file).

    I edited the Snapshot and tried Run Immediate, and it showed me the progress bars and seemed to be successful; unlike the other snapshot, it didn't send to Dropbox right away, but it does say Destination: 1 pending, so it might just take a while because it's larger. If this is successful, I think I'll create the snapshots for the other sites and see what they do. However, it now says the interval is "Manual," so I'm wondering if something about the automatic kick-off isn't working for me?

  • Paul

    but it never seemed to finish creating an archive that could be seen by the plugin within Snapshot

    How would you know exactly? I think this depends on how you have the many different Snapshot configuration on the All Snapshots page. I'm sorry but as long as this thread has been going I've lost track of things. I'm tempted to suggest clearing out the snapshots again so we can go back to see what is broken. I'm still not sure if the issue you are having is you are not able to create a large/full backup or send to Dropbox or both.

    However, it now says the interval is "Manual," so I'm wondering if something about the automatic kick-off isn't working for me

    When you run a snapshot in 'immediate' mode you see the pretty progress bars. But the file will not be sent to the destination immediately. This is because you are running things manually. Meaning there is a higher potential of a timeout on the page processing. When you schedule an item to run at an interval the backup processing and sending are done as one step.

    For the manually run snapshot items that need to be sent to a remote destination there is a specific WP_CRON process run every 5 minutes. This WP_CRON processing relies on front-end traffic to your website. So every 5 minutes this process will check for any files needed to be sent.

  • Azurite

    How would you know exactly?

    Well, something is showing up in my wp-content/uploads/snapshots folder that wasn't there before I started the backup. It also has the same format filename as the snapshot that DOES work, but it's a different name and size altogether. However, when I navigate to the Snapshots plugin page in WordPress via my browser, that file is not seen under Archives for that snapshot (the files one), nor does it show up in the All Archives listing.

    So, the snapshot is getting created, but something is stopping before it can get recognized by the plugin on the browser-end, which may be why it's not sending to Dropbox. (Of note: I've seen it say that it's sending the archive twice now, and it says Destination: Pending, with a percentage going upward on the Interval header. But after I go back to All Snapshots, it's still pending, and now the Interval is back to "normal," with no indication that it's currently sending.)

    I only have the two snapshot configurations, as previously mentioned. I have not yet created any others, and the only configuration settings are:
    1) all files, including config files, but no themes
    2) all database tables for the one seventh-star.net site, but nothing else

    Per my Dropbox, the snapshot-database is working just fine. It's the snapshot-files one that isn't, even though there are now FOUR 117-118.MB files on my server, only one of them shows up for the snapshot-files in Archives, and its Destination is still "pending." I checked the logs a few minutes later, and it says "failed," but it doesn't say why:

    2013-02-11 23:47:48: Sending Archive: snapshot-1359496821-130210-004241-9104a2ca.zip 112.27M
    2013-02-11 23:47:48: Destination: dropbox: Dropbox
    2013-02-11 23:48:15: Sending to Dropbox Directory:/
    2013-02-11 23:48:15: ERROR: Uploading file to Dropbox failed

    When it sends to Dropbox, is it supposed to delete the local copy? Isn't that specified by how many local copies to keep--and is that a total number of snapshots, or just for that one configuration?

    (That is, if I want to keep 3 snapshots, is it keeping 3 for snapshots-files and 3 for snapshot-database, meaning 6 total before the oldest ones will be deleted?)

  • Paul

    When it sends to Dropbox, is it supposed to delete the local copy?

    No. You always retain the last X number of snapshot archives. That is why you have the field on the configuration item for number of local snapshots to retain. At the moment Snapshot does not manage remote files. Meaning (if you ever) get files to Dropbox you need to manage those yourself. But will be adding this hopefully soon.

    I'm really at a loss on suggestions. It seems the smaller snapshot file is going to Dropbox. So this proves there is nothing wrong at your server level that would prevent the connection. The Dropbox library used by Snapshot is from Google and uses the PHP Pear library which is part of PHP. The fact that on the larger files it starts (you do see the percentage change from 0%) tells me things are starting. But something is stopping/timing out on the push of the file. Dropbox will not report on partial uploaded files.

    I have another member having similar issue. Similar in that he is having Dropbox problems. He can send a small file but not a large one. But on his server the large file aborts immediately. I've tests on 12 other server which I have access. On all I can create a 100Mb backup and it sends to my Dropbox no problem.

  • Azurite

    After a bit of trouble with my FTP client, I got the beta version installed. The snapshot for the files is currently hanging at Now: sending the archive to Dropbox at 39%, and when I click on "Now," it says under the logs that "2013-02-15 01:19:32: Sending Archive: snapshot-1359496821-130210-004241-9104a2ca.zip 112.27M
    2013-02-15 01:19:32: Destination: dropbox: Dropbox
    2013-02-15 01:21:23: Sending to Dropbox Directory:disappointed:
    2013-02-15 01:21:23: ERROR: Forbidden. This could mean a bad OAuth request, or a file or folder already existing at the target location."

    I don't see a file in the WPMU Dev Snapshot folder that matches what is trying to be sent, but if it is a bad OAuth request, how would I fix that--by re-authorizing Dropbox?

  • Paul

    @Azurite, Can I ask you to double check the Snapshot install via your Network Plugins listing? The reason I ask is the output from your log does not match a debug addition I made to the code.

    In the beta version the output will show each 'chunk' of the file as it sends to Dropbox. Something like the following.

    2013-02-12 10:28:05: Destination: dropbox: My Dropbox
    2013-02-12 10:28:05: Sending file chunked. Offset: 0/98355002 (0%)
    2013-02-12 10:28:09: Sending file chunked. Offset: 4194304/98355002 (4%)
    2013-02-12 10:28:12: Sending file chunked. Offset: 8388608/98355002 (8%)
    2013-02-12 10:28:15: Sending file chunked. Offset: 12582912/98355002 (12%)

  • Azurite

    I double-checked that the Snapshot plugin was properly updated to the beta; see the screenshot. I did have some difficulties FTPing it and replacing the existing Snapshot folder...maybe something got missed in the process?

    I've checked the logs for the snapshot-files and it still doesn't show the "chunks" you're talking about. It showed the OAuth errors from before, and after several of those, one attempt that looks like it tried to send to Dropbox again from five days ago (the 15th), but never completed and has no error as to why. On the main All Snapshots screen, it looks like this particular snapshot is hanging at 39%.

  • Azurite

    I removed the entire snapshot folder from the plugins folder, then uploaded the beta version from the ZIP, but even though I see the correct version in my plugins list, I still see my old snapshot hanging at 39%, with the logs stuck from 2/15, no chunk output, and no way to abort it (clicking on the abort link doesn't seem do do anything). Could there be something corrupted in the database Snapshot uses?

  • Paul

    @Azurite, No, Snapshot really doesn't create a database for its own use. and I don't think thins is related to your database at all since you can created the snapshot archives using most any configuration. Correct me if I'm wrong here but the issue is the sending to Dropbox. I see in this thread sidebar it does show you are using the beta-3 version of Snapshot.

    So I think you are maybe looking at the wrong log files. Considering things are running and creating new archives and log files I'm really sure where you are looking. Does not matter at this point. Can we once again clear our ALL the snapshot items on the All Snapshots listing. Also please remove the entire /wp-content/uploads/snapshots/ folder.

    Once you are done. Create a new snapshot and see if we can get something fresh on the log file.

  • aecnu

    Greetings Azurite,

    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.