WordPress.org

Support

Support » Plugins and Hacks » [Resolved] Files not transfered to Amazon S3

[Resolved] Files not transfered to Amazon S3

  • TraciBunkers
    Member

    @tracibunkers

    I just installed your plugin, set things up, and did a backup. My buckets on Amazon showed the files were there. But when I tried to download them, nothing happened. So I clicked on the link in Amazon S3 to open the smallest one, and it opened a new page that said this:

    NoSuchKeyThe specified key does not exist.backup_2012-11-02-2344_Traci_Bunkers_Welcome_to_My_World_aaa189ea0704-others.zipD2BED09A52939141D6zpUu8LMTf5eA09iUdtdw1a+V7HgPSxdq471wLv20bdfM2UqYT/VX2XGRWY5uJp

    I went back in the wordpress dashboard, I clicked on the button to download backups, then clicked on one of them to download, and it said this:

    Download failed. File /home/tracibun/public_html/blog/wp-content/updraft/ did not exist or was unreadable. If you delete local backups then S3 or Google Drive or FTP retrieval may have failed. (Note that Google Drive downloading is not yet supported – you need to download manually if you use Google Drive).0

    But, when I went to the FTP folder, the files were there and I was able to download them (I only tried one). And, the files in the FTP folder had the same sizes listed as in Amazon S3.

    What have I done wrong?

    http://wordpress.org/extend/plugins/updraftplus/

Viewing 15 replies - 16 through 30 (of 52 total)
  • TraciBunkers
    Member

    @tracibunkers

    I had started a manual backup, but didn’t see a resume job in the crontrol panel. But I just refreshed it, and see it now. It says the recurrence is non-repeating. Is that correct?

    I’ve also looked in the updraft folder on my ftp, and the size of my uploads folder hasn’t changed. It’s still at 16.5mb, but should be about 485mb. As updraftplus works, it can add to the zipped file?

    Plugin Author David Anderson
    Participant

    @davidanderson

    Yes, the recurrence is non-repeating. When the resume job starts, it re-schedules another one-off job. If the backup completes successfully, it then cancels that job. That way, there should only be a resume job to use WordPress’s resources if it is needed.

    It’s hard to say; there are a few possibilities. Some FTP clients cache their listings. Or, your web host may have a low memory limit for PHP that is too small for some file that the zip code to be able to deal with. I can get most information if you can do the visit-page-on-blog-every-5-minutes cycle a few times, and then send me the relevant log file from the wp-content/updraft directory…

    TraciBunkers
    Member

    @tracibunkers

    The files sizes haven’t changed and I have refreshed things in Fetch (what I use for FTP). And my webhost put in a php.ini file for me that says this:

    memory_limit = 2048M
    max_execution_time = 259200
    max_input_time = 259200
    upload_max_filesize = 1536M
    post_max_size = 1536M

    Plugin Author David Anderson
    Participant

    @davidanderson

    Can you send the log?

    Also, can you check if those details in the php.ini file are actually taking effect? Upload a file called phpinfo.php like this:

    <?php phpinfo(); ?>

    Then run it in your web browser, and try to find the settings mentioned above (memory_limit, etc.) and see what it says. Then delete the phpinfo.php file.

    David

    TraciBunkers
    Member

    @tracibunkers

    Also, when I check “delete local backups” in the updraft settings page, and save it, it does not save that setting. That had happened to me with the previous version as well.

    And I had deleted the plugin, and said to delete all of the files associated with it. Then when I reinstalled it today, it had all of my Amazon S3 info already in it.

    I just refreshed the Fetch window, and there are now 3 more files of uploads, themes, plugins. This is what had been happening to me before. Instead of finishing backing up the files, it would just start making new ones. So I’d have a bunch of them, all incomplete.

    Plugin Author David Anderson
    Participant

    @davidanderson

    Delete local backups – I’ll look into that.

    When you de-install, you’ll see that WordPress offers to show you which files it means by the associated files – it’s just the ones in wp-content/plugins/updraftplus. It doesn’t touch the settings stored in the WordPress database. Those are left alone – that’s up to the plugin author, and I thought it best to leave them; they don’t cause any harm and some people may later decide to re-install and find it convenient to not need to enter their preferred settings again.

    TraciBunkers
    Member

    @tracibunkers

    Yes, I ran the phpinfo after my host put it in. And it has the same settings as the php.ini.

    There are 3 logs so far. I’ll paste them in order:
    Fri, 07 Dec 2012 05:54:47 +0000 In case we run out of time, scheduled a resumption at: 300 seconds from now
    Fri, 07 Dec 2012 05:54:47 +0000 PHP version: 5.2.17 WordPress version: 9961 Updraft version: 0.9.20 Backup files: 1 (schedule: daily) Backup DB: 1 (schedule: daily)
    Fri, 07 Dec 2012 05:54:47 +0000 Processed schedules. Tasks now: Backup files: 1 Backup DB: 1
    Fri, 07 Dec 2012 05:54:47 +0000 Beginning backup of directories
    Fri, 07 Dec 2012 05:54:47 +0000 Beginning backup of plugins
    Fri, 07 Dec 2012 05:55:46 +0000 Created plugins zip – file size is 14475529 bytes
    Fri, 07 Dec 2012 05:55:46 +0000 Beginning backup of themes
    Fri, 07 Dec 2012 05:56:01 +0000 Created themes zip – file size is 4442623 bytes
    Fri, 07 Dec 2012 05:56:01 +0000 Beginning backup of uploads
    Fri, 07 Dec 2012 06:00:28 +0000 Resume backup (1): begin run (will check for any remaining jobs)
    Fri, 07 Dec 2012 06:00:28 +0000 Resuming backup: resumption=1, nonce=7bd54804ed74, begun at=1354859687
    Fri, 07 Dec 2012 06:00:28 +0000 Error: Could not find a record in the database of a backup with this timestamp
    Fri, 07 Dec 2012 06:00:28 +0000 There were no files that needed uploading; backup job is finished
    Fri, 07 Dec 2012 06:05:34 +0000 Resume backup (2): begin run (will check for any remaining jobs)
    Fri, 07 Dec 2012 06:05:34 +0000 Resuming backup: resumption=2, nonce=7bd54804ed74, begun at=1354859687
    Fri, 07 Dec 2012 06:05:34 +0000 Error: Could not find a record in the database of a backup with this timestamp
    Fri, 07 Dec 2012 06:05:34 +0000 There were no files that needed uploading; backup job is finished
    Fri, 07 Dec 2012 06:10:35 +0000 Resume backup (3): begin run (will check for any remaining jobs)
    Fri, 07 Dec 2012 06:10:35 +0000 Resuming backup: resumption=3, nonce=7bd54804ed74, begun at=1354859687
    Fri, 07 Dec 2012 06:10:35 +0000 Error: Could not find a record in the database of a backup with this timestamp
    Fri, 07 Dec 2012 06:10:35 +0000 There were no files that needed uploading; backup job is finished
    Fri, 07 Dec 2012 06:15:38 +0000 Resume backup (4): begin run (will check for any remaining jobs)
    Fri, 07 Dec 2012 06:15:38 +0000 Resuming backup: resumption=4, nonce=7bd54804ed74, begun at=1354859687
    Fri, 07 Dec 2012 06:15:38 +0000 Error: Could not find a record in the database of a backup with this timestamp
    Fri, 07 Dec 2012 06:15:38 +0000 There were no files that needed uploading; backup job is finished
    Fri, 07 Dec 2012 06:20:42 +0000 Resume backup (5): begin run (will check for any remaining jobs)
    Fri, 07 Dec 2012 06:20:42 +0000 Resuming backup: resumption=5, nonce=7bd54804ed74, begun at=1354859687
    Fri, 07 Dec 2012 06:20:42 +0000 Error: Could not find a record in the database of a backup with this timestamp
    Fri, 07 Dec 2012 06:20:42 +0000 There were no files that needed uploading; backup job is finished

    another:
    Fri, 07 Dec 2012 06:24:28 +0000 In case we run out of time, scheduled a resumption at: 300 seconds from now
    Fri, 07 Dec 2012 06:24:28 +0000 PHP version: 5.2.17 WordPress version: 1125 Updraft version: 0.9.20 Backup files: (schedule: daily) Backup DB: 1 (schedule: daily)
    Fri, 07 Dec 2012 06:24:28 +0000 Processed schedules. Tasks now: Backup files: Backup DB:
    Fri, 07 Dec 2012 06:24:28 +0000 There were no errors in the uploads, so the ‘resume’ event is being unscheduled

    another:

    Fri, 07 Dec 2012 06:22:54 +0000 In case we run out of time, scheduled a resumption at: 300 seconds from now
    Fri, 07 Dec 2012 06:22:54 +0000 PHP version: 5.2.17 WordPress version: 5275 Updraft version: 0.9.20 Backup files: 1 (schedule: daily) Backup DB: (schedule: daily)
    Fri, 07 Dec 2012 06:22:54 +0000 Processed schedules. Tasks now: Backup files: 1 Backup DB: 1
    Fri, 07 Dec 2012 06:22:54 +0000 Beginning backup of directories
    Fri, 07 Dec 2012 06:22:54 +0000 Beginning backup of plugins
    Fri, 07 Dec 2012 06:23:42 +0000 Created plugins zip – file size is 14475529 bytes
    Fri, 07 Dec 2012 06:23:42 +0000 Beginning backup of themes
    Fri, 07 Dec 2012 06:23:59 +0000 Created themes zip – file size is 4442623 bytes
    Fri, 07 Dec 2012 06:23:59 +0000 Beginning backup of uploads

    TraciBunkers
    Member

    @tracibunkers

    also, I only have sets of the uploads, themes, & plugins files in my updraft folder–no database or others.

    I just looked in the crontrol panel, and the updraft resume is no longer showing, even though I’ve opened a page on my site. I’m not sure if I’ve done it every 5 minutes or not.

    Plugin Author David Anderson
    Participant

    @davidanderson

    That log shows that the PHP process runs out of time whilst trying to create a zip file of your “uploads” directory. Look at how much time it takes to create the zips of your plugins and themes directory, it’s completely crazy-slow:

    Fri, 07 Dec 2012 06:22:54 +0000 Beginning backup of plugins
    Fri, 07 Dec 2012 06:23:42 +0000 Created plugins zip – file size is 14475529 bytes

    That’s 14Mb in 48 seconds – about 290Kb per second… it ought to be something like 20Mb a second, i.e. 80 times as fast. I’ve just checked my logs from my testing whilst developing yesterday; 12Mb in under a second; and that’s a cheap server.

    Or for themes:
    Fri, 07 Dec 2012 06:23:42 +0000 Beginning backup of themes
    Fri, 07 Dec 2012 06:23:59 +0000 Created themes zip – file size is 4442623 bytes

    4Mb in 17 seconds; 250Kb per second. Your *mobile phone* will be able to produce zip files far faster than that.

    I’m afraid your website must be hosted on the world’s most over-sold, over-crowded, resource-starved server. If your “uploads” directory is 450Mb, then at the same rate it would take half an hour to produce a zip file from its contents….

    I recommend http://www.simbahosting.co.uk, whom I am part of – they’ll transfer your website over for free…

    TraciBunkers
    Member

    @tracibunkers

    Hmmm. My host is stablehost. It’s not “unlimited” and is supposed to be a good host. I just moved to them a few months ago. And I was having the same problems trying to backup on my previous host, which was a small company and not unlimited either.

    Is there anything I can ask my host? I thought that them ading the php.ini file would help. I know the numbers on it are much higher than usual. Would that be causing problems? Or, do you know if other plugins could cause conflicts, causing this to happen?

    There were a few times with updraft plus that it was able to zip the files & upload them to amazon S3–Nov. 20th & 24th. I’m not sure why they did then, and not now. But I do remember I was still having to do a lot to get those to happen.

    Plugin Author David Anderson
    Participant

    @davidanderson

    The values in the php.ini can’t be hurting – those are just limits, and only having them too low can hurt. But it’s having too little CPU time, which isn’t something PHP can control, that’s your problem – either that or they have a problem with congested disk input/output. Other plugins can’t be causing a conflict; there’s nothing you could do, even if you wanted to, to resource-starve your website other than by bombarding the server with too many requests for its capacity. The only thing you can do is ask your hosting company to investigate. Specifically, show them the logs, and tell them that “the code is simply using PclZip to create a zip file from a directory, and is expected to run at 20Mb/s rather than 250Kb/s”).

    TraciBunkers
    Member

    @tracibunkers

    My web host said I was maxing out at my CPU/RAM usage. I was on a shared cloud linux server which throttles your usage when you hit the max. So I upgraded to “enterprise level”, and I still seem to be getting up to my limits. They said I need to optimize my site more and not use as many plugins.

    But, the good news is, with your latest upgrade, my site is getting backed up–even my large 480 mb uploads file. But they aren’t transferring to Amazon S3.

    I’ll see how the next scheduled backup goes, and let you know.

    Plugin Author David Anderson
    Participant

    @davidanderson

    Any news?

    David

    TraciBunkers
    Member

    @tracibunkers

    Unfortunately, with the last 2 updates, nothing happens at all, even though I haven’t changed any settings. Even if I click on the “create backup now”, and look at pages on my site every 5 minutes, it doesn’t back up anything and doesn’t created a log.

    In the admin panel, under latest backups, it says:
    Array ( [0] => S3 delete error: NoSuchBucket: The specified bucket does not exist [1] => S3 delete error: NoSuchBucket: The specified bucket does not exist [2] => S3 delete error: NoSuchBucket: The specified bucket does not exist [3] => S3 delete error: NoSuchBucket: The specified bucket does not exist [4] => S3 delete error: NoSuchBucket: The specified bucket does not exist [5] => S3 delete error: NoSuchBucket: The specified bucket does not exist )

    But I haven’t changed my buckets, and it still has my amazon S3 info. But it’s not even creating the files in my FTP like it used to.

    Plugin Author David Anderson
    Participant

    @davidanderson

    Have you updated to this morning’s version 1.2.16? That fixed the relevant bug that you’re encountering there (which was also recently introduced).

Viewing 15 replies - 16 through 30 (of 52 total)
  • The topic ‘[Resolved] Files not transfered to Amazon S3’ is closed to new replies.