Backup 1.0 Times out I think

[blulegend]

I can't get Backup 1.0 included with 1.3 to complete a restore. I backed up my data to a file and it will never get to the EOF during a restore. It always stops and it will stop randomly. Now 1.3 will not run and I have lost all my info. I will try to use phpMyAdmin to restore it.

[blulegend]

I have used phpMyAdmin to restore the database.

Downloaded the data file and replaced the delimiter with a semicolon. Removed the header and footer comments and uploaded the file to phpMyAdmin as an SQL query. Worked. I think because Backup outputs each query to the browser it will time out for some people.

[Pekka]

Hi,

Thanks for reporting.

I recently fought some server timeout problems with one omnihttp server and that lead me to fix more reasons to the possible restore timeout in latest EE backup (release version). There was also an odd bug related to UNIX file buffering which I fixed, too. I also added a debug more (set in beginning of index.php) to follow backup code workflow.

http://photography-on-the.net/gallery/ee_backup_release_1_index.zip

Can you please try this version for checking if you have same problems, that would make my day. If you still have problems, please mail me your initial backup file for further investigation.

PS. I recommend that database backup sets are used for restoring and backing up. I included file backup/save/upload/restore only for having that extra backup security if whole database system fails. Database backup sets are faster and more reliable (no delimiters, parsing or possible browser timeouts).

PPS. Oh, and the Omnihttp server still does not work with EE backup - it does not with PhPMyadmin either, both lock it down. So Omni is definitely not on my recommended servers list.

[blulegend]

I will try it out. I use Apache.

I think my host sets a limit on the time to load a page or something. I had trouble posting large http downloads before.

[blulegend]

I tried the database backup set and it works.

I tried the new version of index.php with debuging on and everything connects fine. Still times out while outputting the queries to the bottom of the screen. It doesn't get as far, but the timeout may be influenced by the load on my server.

If timeouts are a big problem, perhaps you can create entire a set of backup files. One for each table. You could probably do something that will reload the page and move onto the next table when one table is complete. That would require a LOT of work and still may not be fullproof is a server is having trouble and does not completely restore one of the tables. With this method you can also restore certain tables using a checkbox. Another way is to add delimiters to the files between tables and have the script search out the beginning of each table instead of using separate files.

[Pekka]

blulegend wrote:
I tried the database backup set and it works.

I tried the new version of index.php with debuging on and everything connects fine. Still times out while outputting the queries to the bottom of the screen. It doesn't get as far, but the timeout may be influenced by the load on my server.

Try this version:
http://photography-on-the.net/gallery/ee_backup_release_1_keepalive.zip

It uses a different approach to keep browser from timing out.

If timeouts are a big problem, perhaps you can create entire a set of backup files. One for each table. You could probably do something that will reload the page and move onto the next table when one table is complete. That would require a LOT of work and still may not be fullproof is a server is having trouble and does not completely restore one of the tables. With this method you can also restore certain tables using a checkbox. Another way is to add delimiters to the files between tables and have the script search out the beginning of each table instead of using separate files.

Because MySQL can receive only one command string (DROP, CREATE, INSERT) at a time, using big chunks of commands really does not help. Database backup sets use chunks to speed up file processing and making compression more effective. Timeouts are not really related to size of the backup, but lenght of how much time it takes to process one command - this may vary a lot between servers. Also, timeouts happen if browser does not accept and understand the given methods as "keep alive" signals.

If the problem is something other than browser timeout (MySQL timeout, too big command, parse error) EE backup will report and explain it.

There are two methods of keeping browser "alive" when executing the commands: by sending something to the browser screen (the version you have now), or using http headers. Both cannot be used at the same time.

The new test version above sends "keep-alive" instructions as http headers in every occasion it can during restore - problem with this approach is that I can not print anything helpful or progress messages while file backup is being restored. Also, debug mode must be 0 (off) for this version.

Let me know it if makes a difference.

Restoring selected tables is on the wish list, but it is sort of done already - just make backups of selected tables. :)

[blulegend]

Nope. This version just gives a browser error after a while before it displays anything. Lucky the database version works well.

I think it is my server.