Each night I run via cron a shell script to backup one of my Debian
boxes, which has NFS-mounted partitions for the rest of my network.
The backup is supposed to do a full copy-to-tape of all the specified
directories, including the NFS-mounted partitions.
However, I get a tar: file changed as
Why not just export the the databases with MySQL-dump and back up the
exported files instead of the live databases?
--
Dave
On Dec 5, 2003, at 11:43 AM, Marc Elliot Hall wrote:
Date: Fri, 05 Dec 2003 11:43:54 -0800
From: Marc Elliot Hall [EMAIL PROTECTED]
To: Vox-Tech [EMAIL PROTECTED]
On Fri, Dec 05, 2003 at 12:24:59PM -0800, David Siedband wrote:
Why not just export the the databases with MySQL-dump and back up the
exported files instead of the live databases?
I'm vaguely familiar with what he's working on (though hadn't looked into
backups there), and unfortunately, I
On Fri, Dec 05, 2003 at 12:33:22PM -0800, Bill Kendrick wrote:
On Fri, Dec 05, 2003 at 12:24:59PM -0800, David Siedband wrote:
Why not just export the the databases with MySQL-dump and back up the
exported files instead of the live databases?
I'm vaguely familiar with what he's working
Why not just export the the databases with MySQL-dump and back up the
exported files instead of the live databases?
Right at the bottom of the email you quoted...
Somebody with a suggested workaround using mysqldump that doesn't quite
work for me:
So, if tar is saying the file changed as we read it, does that mean
that tar:
* skipped the file,
No
* made a copy of the version that existed when tar *started* the
operation,
No
* made a copy of the version that existed when tar *finished* the
operation, or
No
* some combination of these?
On Fri, 5 Dec 2003, Mitch Patenaude wrote:
* some combination of these?
yes. if it was half-way through reading the file.. then the first half
is the old file, and the second half is the new files. If more than
one change was made, then more than one file is there.
Hold on... are
On Fri, Dec 05, 2003 at 04:43:25PM -0800, Mitch Patenaude wrote:
Basically, you can use a tool like mysqldump to dump a version of the
tables, which can be used to reconstruct the database later. If you
don't have enough disk space, then get another (or bigger) disk. Even
then,
On Fri, Dec 05, 2003 at 05:21:53PM -0800, David Hummel wrote:
mysqldump -l --opt mydb | gzip mydb_`date +%y%m%d%H%M%S`.sql.gz
Silly me, this is redundant. -l is included when using --opt.
-David
___
vox-tech mailing list
[EMAIL PROTECTED]
Never mind. Mitch is right. Checked the tar sourcecode.
-Mark
On Fri, 5 Dec 2003, Mark K. Kim wrote:
On Fri, 5 Dec 2003, Mitch Patenaude wrote:
* some combination of these?
yes. if it was half-way through reading the file.. then the first half
is the old file, and the second half
Thanks Rob. I did read Marc's entire e-mail though.
I was asking to determine why mysqldump wasn't a workable solution in
his situation.
In my experience it has proved the most effective fix for the problem
he is describing.
--
Dave
Right at the bottom of the email you quoted...
Somebody
On Fri, 5 Dec 2003, Mark K. Kim wrote:
On Fri, 5 Dec 2003, Mitch Patenaude wrote:
* some combination of these?
yes. if it was half-way through reading the file.. then the first half
is the old file, and the second half is the new files. If more than
one change was made, then more
12 matches
Mail list logo
