ALWAYS Save a Site Backup To Your Computer!

If it didnt save it I wouldnt blame MySQLDumper for that..

More probably the execution time allowed in your php setup at your host provider, simply ask them to double the allowed time....

I have never had ANY failures with this and I have been using it since Noah built his Ark.. The most reliable method there is..

And some of my backups using this are MASSIVE not large...

Also:
My backup is bigger than 1 GB. This way it is "hard to handle". What should I do?

Jump to the configuration and use the "multipart feature". Choose a dumpfile size and watch MySQLDumper splitting the big dump into separated files.

Regards..
 
TheBoss said:
If it didnt save it I wouldnt blame MySQLDumper for that..

More probably the execution time allowed in your php setup at your host provider, simply ask them to double the allowed time....
Click to expand...
My impression was MySqlDumper was subject to php timeouts, but using these commands are not, correct?:

backup:
mysqldump --opt -Q -u dbusername -p databasename > backupname.sql

restore:
mysql -u dbusername -p databasename < backupname.sql
 
Dean said:
My impression was MySqlDumper was subject to php timeouts, but using these commands are not, correct?:

backup:
mysqldump --opt -Q -u dbusername -p databasename > backupname.sql

restore:
mysql -u dbusername -p databasename < backupname.sql
Click to expand...
That is correct. Providing you have shell access.
 
MySQLDumper is NOT subject to php timeouts.. PHP in itself is subject to the timeout limits setup by whoever installed the software on the server...

IE; If PHP is set to 5 mins instead of the normal 30 seconds when its compiled I doubt anyone would ever have any trouble at all...

The problem …

A PHP script has a maximum execution time that is usually set to 30 seconds on most server installations. A script running longer than this limit will simply stop working. This behavior makes backing up large databases impossible. Maybe you already had this specific problem when using other tools.
MySQLDumper fills a gap …

MySQLDumper uses a proprietary technique to avoid this problem. It only reads and saves a certain amount of data, then calls itself recursively via JavaScript and remembers how far in the backup process it was. The script then resumes backing up from that point.
The restore process is similar. Unlike other tools, splitting and splicing of large backup files is no longer necessary.
MySQLDumper can write the data directly into a compressed .gz file. The restore script is able to read this file directly without unpacking it. You can also use the script without compression, but using Gzip saves a lot of bandwidth. You can even configure the script to automatically send the backup file to an FTP account or your email adress.

I wrote this as guide for those who need a little help , not as a defacto dictatorship stating people have to use it...

If your tech savy and dont need the guide great use whatever floats your boat...

Or if your really tech savy and have 15 mins spare write your own guide then people will have a choice , the more guides the better I say...

Regards..
 
TheBoss said:
Or if your really tech savy and have 15 mins spare write your own guide then people will have a choice , the more guides the better I say...

Regards..
Click to expand...

The method I posted here would do the job without risking timeouts, just tweak it to upload to ftp opposed to mailing.
 
Relax. I'm just saying it was not a viable solution for me. It may work for 99% percent of the people, it did not work for me.
The important thing is to backup and test your backup periodically. That was my fault for not checking.
 
TheBoss said:
The problem …

A PHP script has a maximum execution time that is usually set to 30 seconds on most server installations. A script running longer than this limit will simply stop working. This behavior makes backing up large databases impossible. Maybe you already had this specific problem when using other tools.
MySQLDumper fills a gap …

MySQLDumper uses a proprietary technique to avoid this problem. It only reads and saves a certain amount of data, then calls itself recursively via JavaScript and remembers how far in the backup process it was. The script then resumes backing up from that point.
The restore process is similar. Unlike other tools, splitting and splicing of large backup files is no longer necessary.
MySQLDumper can write the data directly into a compressed .gz file. The restore script is able to read this file directly without unpacking it. You can also use the script without compression, but using Gzip saves a lot of bandwidth. You can even configure the script to automatically send the backup file to an FTP account or your email adress...
Click to expand...

Thank you very much for your guide an this additional information, it really helps. It has been quite some time since I've looked into these things.
 
niden.net said:
Unfortunately there is no way for me to do this without a shameless plug :/

I have been burned by backups (or lack there of) numerous times in the past. I have therefore created a backup solution at home which is fully automated and runs on very inexpensive hardware (my current backup PC is 7 years old).

http://www.niden.net/2010/08/how-to-create-an-inexpensive-hourly-remote-backup/

I hope it helps.
Click to expand...

Thanks for posting. How often do you apply security patches to your backup box?
 
TheBoss said:
MySQLDumper is NOT subject to php timeouts.. PHP in itself is subject to the timeout limits setup by whoever installed the software on the server...

IE; If PHP is set to 5 mins instead of the normal 30 seconds when its compiled I doubt anyone would ever have any trouble at all...
Click to expand...

Setting the value of max_execution_time at 5 minutes on a production server is bad for a number of reasons. A script going haywire can easily tie up your entire system. The issue can be avoided altogether by running the script from the command line.

Personally, I prefer mysqldump for restoring databases (and parallelizing restoration of multiple tables in a single database). MySQLDumper doesn't seem to have any advantages over mysqldump, aside from the fact it can be ran from a browser. Then again, I do realize there are web hosts that still don't provide shell access to their customers :-/.
 
I used 5 mins as an example of time I didnt mean it should be set at 5 mins in the actual compilling of php.

60 or 90 seconds should be ample in most cases.

But , as the documentation of MySQLDumper points out it uses Java refresh so that the script does not fail because of php time outs.Or should NOT.

Failure is more than likely caused by how busy the net is at the time you decide to do your restore.
We ARE ALL subject to net lag at certain times of the day.. Regardless of where we live.

Regards..
 
Floris said:
One of the reasons I am on at least VPS and not on Shared hosting, is so I have access to my data without the restrictions.
Click to expand...

One of the reasons I am with Linode is for the $5 a month backup service, is a very decent VPS for the money and though is non-managed are still great with support.
 
0ptima said:
Thanks for posting. How often do you apply security patches to your backup box?
Click to expand...

The backup box resides at home and the firewall is closed to outside coming in (since the box only pulls via rsync). Having written that, it is a Gentoo box so I usually run the emerge --sync every week or every other week.
 
This thread meant nothing to me yesterday ... today, however, I will be leaving work and heading off to my "other" office to repair my PC, which appears to have thrown a disk out. What fun ... NOT!! :rolleyes:
 
http://bqinternet.com/ - I've been using them for years now. Started with my dedicated box I was renting from The Planet for about 4 years and still use them when I moved over to my own co-located server.

WELL worth the money and extremely useful. Backups up my entire server each and every night. My server is located in Dallas, TX and the backups are transferred to BQInternet which is located in New York.

Nice thing is it's also accessible via FTP if needed so I can recover one file, an entire site or even the entire server from my backups. I HIGHLY recommend them!
 
Thanks ... might be an opportunity to de-junk my machine - I've got files on there from 12 years ago that are useless to me now, but for some reason - with my computers anyway - I have a tendency to hoard data.
 
David Thomas said:


The World Trade Center had security guards and alarm systems, probably some of the best. The Pentagon is a freaking prison, you can't get in or out without passing rigorous security clearance and military guys with guns. I'm sure you'll recall what happened. Calling someone "incompetent" or "jerkoffs" because they experienced a freak accident with the hardware just goes to show you how the true "jerkoff" is. Millions of car accidents happen every year. Most of the time, people are injured, but they are still alive. Do we call the thousands who died in the accident "incompetent jerkoffs", because they're part of the few who couldn't control what happened?

To assume that nothing could go wrong with technology just sets you up for further failure.
Click to expand...

Oh my god! I can't believe what I just read here - I have literally heard it all now. This David Thomas just tried to compare the 9/11 attacks on the world trade center and pentagon to a hardware failure in web hosting. Absolutely amazing and idiotic all at the same time.
 
Top Bottom