If you replicate your live database to a spare database, you can then
perform backup tasks on the spare. The reason to backup to spare is that
you can use the pre and post dump commands to shutdown the database for the
backup. This solves a number of issues from file locking on the database.
You
On Sat, 2008-10-11 at 22:47 +, John Rouillard wrote:
> On Fri, Oct 10, 2008 at 08:00:33PM -1000, Philip Tait wrote:
> > If you run a second MySQL, why not configure it as a replicated slave?
> > Works well for us.
>
> and what happens when somebody runs a cascaded delete that wipes your
> data
On Fri, Oct 10, 2008 at 08:00:33PM -1000, Philip Tait wrote:
> If you run a second MySQL, why not configure it as a replicated slave?
> Works well for us.
and what happens when somebody runs a cascaded delete that wipes your
database? Replication is not a replacement for backups.
--
I believe the way it works is:
Rsync divides the file up into blocks and transfers only the blocks that
have changed. Then it re-assembles the file on the receiving side using
the changed blocks (that were just transfered) and the unchanged blocks
(which already existed on the receiving side).
-
Seann Clark wrote:
> Another way to do this is get a Windows type box, use MySqlAdmin on
> the windows box (Free perdy GUI download J ) and have it schedule
> the backups. The backups end up as TXT files that compress
> wonderfully, and restore perfectly.
I don't really see the advantage of
]
Sent: Friday, October 10, 2008 9:27 PM
To: General list for user discussion,questions and support
Subject: Re: [BackupPC-users] backing up large SQL DB's
for backing up MySQL databases, why not run a second MySQL and sync them on
a schedule? Then if you have a problem you dont even need to re
If you run a second MySQL, why not configure it as a replicated slave?
Works well for us.
Philip J. Tait
http://subarutelescope.org
On Fri, 2008-10-10 at 20:27 -0600, dan wrote:
> for backing up MySQL databases, why not run a second MySQL and sync
> them on a schedule? Then if you have a problem
for backing up MySQL databases, why not run a second MySQL and sync them on
a schedule? Then if you have a problem you dont even need to restore, you
can just switch to the other server or restart the first machine and sync
the other way? If you do this you can sync, then stop the backup so you c
On 2008-10-09 22:13, Nick Smith wrote:
> On Thu, Oct 9, 2008 at 3:38 PM, David Rees <[EMAIL PROTECTED]> wrote:
> >
> > As long as the file names remain the same and you are using rsync,
> > only the changes will be downloaded.
> >
> Do you know how it does that? I thought it just checked checksums
David Rees wrote:
> On Thu, Oct 9, 2008 at 11:06 AM, Nick Smith <[EMAIL PROTECTED]> wrote:
>> I am using the volume shadow copy to backup large (12gig+) sql db's.
>> After the first full backup, and things are changed/added to the DB,
>> is it going to pull down the entire DB again or will it just
Do you know how it does that? I thought it just checked checksums to
see if they were different? How can it just download the changes to a
large DB like that if its all contained in a single file DB?
thanks
On Thu, Oct 9, 2008 at 3:38 PM, David Rees <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 9, 20
On Thu, Oct 9, 2008 at 11:06 AM, Nick Smith <[EMAIL PROTECTED]> wrote:
> I am using the volume shadow copy to backup large (12gig+) sql db's.
> After the first full backup, and things are changed/added to the DB,
> is it going to pull down the entire DB again or will it just download
> the changes
I am using the volume shadow copy to backup large (12gig+) sql db's.
After the first full backup, and things are changed/added to the DB,
is it going to pull down the entire DB again or will it just download
the changes
(if thats possible)
thanks for the input.
---
13 matches
Mail list logo
