WordPress.org

Ready to get started?Download WordPress

Forums

WordPress Backup to Dropbox
[resolved] Two issues with latest update (18 posts)

  1. sephage
    Member
    Posted 1 year ago #

    Hi and thanks for the excellent plugin!

    The latest update oauth changes have got it working on my website again, which is awesome. But I've noticed two odd things happening in this version:

    1) some large files don't ,make it into the correct subdirectories on the dropbox side. Instead, they have the subdir name appended ton the front of the filename. E.g., subdirBigfile.mp3

    2) the plugin seems to be backing up and overwriting every file every backup, rather than just copying over changed files, so it's taking 3 to 4 hours to backup the site every night (about 1.5 GB worth of files).

    Any thoughts?

    Thanks!

    http://wordpress.org/extend/plugins/wordpress-backup-to-dropbox/

  2. Michael De Wildt
    Member
    Plugin Author

    Posted 1 year ago #

    1) Really? Thats odd. What was the file path on your server and what does it look like on Dropbox?

    2) Ill do some regression testing to see if this is happening for me.

  3. sephage
    Member
    Posted 1 year ago #

    1) yeah, I know. Some of then files are in a subdir off the top level directory titled audio, and they got put into the root / home directory with "audio" appended to the beginning of the filename instead of being copied to the audio directory on the drop box side. If I had to guess, I'd say that might have something to do with how a dir list got parsed and what characters are used to recognize or write those (e.g., "/", etc.) But I've not taken a gander at the code so that's only a guess.

    2) thanks!

  4. Michael De Wildt
    Member
    Plugin Author

    Posted 1 year ago #

    What is the difference in size between the two files?

  5. Michael De Wildt
    Member
    Plugin Author

    Posted 1 year ago #

    I just pushed a fix for #2. if you delete and re-install you should get it.

  6. sephage
    Member
    Posted 1 year ago #

    No diff between the file sizes that I can discern, and they've not been changed I'm some cases for over a year. In fact, one of the files this is happening with are the SQL dumps created by this plugin, which are in the backups dir on the server but one level up in wp-content on drop box, with "backups" appended to the beginning of the filename.

    For #2, thanks, I'll have to give that a go tomorrow when I'm back in front of a proper PC.

  7. sephage
    Member
    Posted 1 year ago #

    Ok, confirmed it's no longer overwriting everything every time, thanks!

    As for the odd issue with the names, that is still happening, and it is happening for the SQL dumps every time now (they get put into the /wp-content dir on Dropbox instead of in the /wp-content/backups dir). Additionally, the SQL dump for the plugins seems quite small to me, about 1/2 the normal size (usually around 73 MB now about 35 mb).

  8. sephage
    Member
    Posted 1 year ago #

    An update, the plugins SQL dump is not only half the size it should be, but now I'm getting errors that it failed to copy, as if it might still be open?

    Error uploading '/htdocs/wp-content/backups/XXXXXXXXX-backup-plugins.sql' to Dropbox: Submitted input out of alignment: got [29360128] expected [26512199] (Status Code: 400)

  9. sephage
    Member
    Posted 1 year ago #

    Sorry for the flurry of updates but had a few mins to test it out today, and from what I can see, I've no idea why the incorrect naming issue is happening on the SQL dumps, but I can just about confirm that the issues with the plugin SQL dump is due to the fact that the dump gets copied over to drop box before the SQL dump is complete. So, sometimes out copies over an incomplete dump file, sometimes it creates an error instead, but I see based on changing file size via ftp that the dump file is still being written to when the copy to dropbox kicks off. Might need a check on completion of the SQL dump, or some kind of wait period before copying? I hadn't noticed it before because when it was overwriting files on the drop box side there was plenty of time for the SQL dumps to complete, I think.

  10. Michael De Wildt
    Member
    Plugin Author

    Posted 1 year ago #

    Thanks for the info.

    I have managed to replicate the issue and its an odd one indeed. I will be releasing a bug fix v1.4.1 soon.

    Cheers,
    Mikey

  11. sephage
    Member
    Posted 1 year ago #

    Thanks! Were you talking about the naming issue, the copying of the plugins SQL dump, or both? Cheers!

  12. Michael De Wildt
    Member
    Plugin Author

    Posted 1 year ago #

    Both :-)

  13. sephage
    Member
    Posted 1 year ago #

    Cool. It's back to overwriting every file, by the way. That might be a server config thing, I'm on Zippykid and their config breaks all kinds of plugins I've found. But the 4 hours it took to copy all the content to drop box gave the sqlmdump plenty of time to complete :-) . In any case, thanks and I'll be anxiously awaiting the next round of fixes.

  14. Michael De Wildt
    Member
    Plugin Author

    Posted 1 year ago #

    I just released 1.4.1 that resolves a few issues.

    Cheers,
    Mikey

  15. sephage
    Member
    Posted 1 year ago #

    Thanks. Installed and tested. Neither the incorrect naming/dir issue or the incomplete SQL dump issue have been fixed, both ate exhibiting the same behavior as in your previous version.

    1) The SQL dumps are still copied from backups dir on the server to wp-content dir on drop box, with "backups" appended to the beginning of the file name.

    2) The plugins SQL dump is not complete when copied, so only a partial dump is sent to drop box and then the file is deleted from the server.

    Is there any way to isolate the SQL dump code that you use, so I could run it separately as php to test how long the plugin db dump portion needs to execute a full dump? Mine is a bit large, probably over 80 mb, I suspect it's taking a long time also due to the config at Zippykid which is not at all standard. It's worth noting that most SQL dumps on ZK don't work, so yours is already far ahead of the game!

    Thanks!

  16. Michael De Wildt
    Member
    Plugin Author

    Posted 1 year ago #

  17. sephage
    Member
    Posted 1 year ago #

    Thanks - confirmed that the uploaded SQL dumps are now going into the backups directory. :)

    Also confirmed that the plugin is copying an unfinished version of the plugins SQL dump, which is only 1/3 to 1/2 complete at the time it gets sent to Dropbox. :(

    Is there any constant/setting I should try to get the plugin to wait for a completed plugins sql dump? I'm running Slimstat and that seems to be the major issue, in that the stats table for that plugin is probably around 90mb. Would increasing the WAIT_TIMEOUT in class-wp-backup-database.php possibly help?

    Thanks!

  18. sephage
    Member
    Posted 1 year ago #

    I know this is marked as resolved, but it's actually not since the plugins SQL portion of this never finishes :).

    In fact, I've seen another 400 error today on the plugins SQL file upload to dropbox, as the file was still being created at the time of upload. From what I can discern, the plugins SQL is actually still (9 hours later!) creating a temporary file of the SQL dump on my server... moving veeeeery slowly....!

    It might make sense to add some kind of exclude tables feature, as I think that might help determine if there's a single plugin or table causing the issue, and generally that would make your plugin even more useful if folks wanted to exclude the plugin table data, etc.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic