What Shawn said is important.
1. Use InnoDB, and then you can make a consistent backup with `mysqldump
--single-transaction > backup.sql` and keep your db server actively responding to
requests at the same time.
2. Use something like LVM to create filesytem snapshots which allow you to backup your
database, while only keeping a read lock on the db for a second or so.
From: Shawn Green [mailto:shawn.l.green@stripped]
Sent: Monday, April 19, 2010 3:24 PM
To: Mitchell Maltenfort
Subject: Re: better way to backup 50 Gig db?
Mitchell Maltenfort wrote:
> I'm using MySQL to manage data on my computer .
> The total data is 50 Gig in MyISAM folders.
> As I type, I already have the folder with the myd, frm, etc being
> copied offsite. As I understand it, if this computer dies tomorrow, I
> can reinstall MySQL on a new computer, drag over the archive, stick
> the folder under "data" and I'm back in business.
> Or am I dreaming?
> I'd rather be corrected now than find out the hard way.
> Any advice?+
Did you remember to FLUSH (with read lock) those tables before you
started copying. Alternatively, you could have shutdown your MySQL
If not, then the in-memory and on-disk images of your tables are out of
sync. You may be copying away data that will appear corrupted after
MySQL Principle Technical Support Engineer
Oracle USA, Inc.
Office: Blountville, TN
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=1
This message contains confidential information and is intended only for the individual
named. If you are not the named addressee, you are notified that reviewing,
disseminating, disclosing, copying or distributing this e-mail is strictly prohibited.
Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed
to be secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not
accept liability for any loss or damage caused by viruses or errors or omissions in the
contents of this message, which arise as a result of e-mail transmission. [FriendFinder
Networks, Inc., 220 Humbolt court, Sunnyvale, CA 94089, USA, FriendFinder.com