On Mon, 2005-09-19 at 13:14 -0400, George Herson wrote:
> James G. Sack (jim) wrote:
> >On Mon, 2005-09-19 at 12:15 -0400, George Herson wrote:
> >>Dear Jim,
> >>Re: your post at http://lists.mysql.com/mysql/189058, why bother
> >>creating the mysqldump if you already have the snapshot? Why not just
> >>backup the snapshot?
> >The output of mysqldump *is* the backup. If the db goes away, it can be
> >restored with (something like) "mysql <dumpfile.2005-09-01".
> >The dump operation is run periodically, and some number of back versions
> >can be kept around (or offloaded) for archival value.
> Yes, but can't you also save your snapshot instead, then, when/if you
> want, restore it,
> "4. mount the snapshot
> 5. load a second database server daemon accessing the db within the
> snapshot (with a suitable alternate my.cnf file)
> 6. perform mysqldump operation on the snapshot-db" ??
George, LVM snapshots are generally intended to be short-lived -- they
give you a "virtual" copy of the underlying ("origin") filesystem (as it
existed at one "point in time"), which occupies only a fraction of the
original storage space because it only deals with changes that occur to
the origin fs over the lifetime of the snapshot.
The snapshot point-in-time concept allows running some slow process
(typically, maybe, writing to a tape device) without needing to be
concerned that the data is changing while you are copying it. The
database does need to be made consistent (locked) at the point of taking
the snapshot, but creating the snapshot only takes seconds. So the
database may be write-unlocked after only a minor disruption, instead of
during the entire backup operation.
If the snapshot were kept around indefinitely, it would eventually need
perhaps as much storage as the origin. So typically one deletes a
snapshot after using it for a staging operation such as above. A further
consideration is that the snapshot adds overhead to every disk
operation, so that's another incentive to minimize the snapshot