[mythtv-users] xfsrestore backup woes

[Mike Hodson]

On Mon, Nov 28, 2016 at 3:34 PM, Will Dormann <wdormann at gmail.com> wrote:

> On 11/27/16 8:26 PM, Will Dormann wrote:
>
> Just a follow-up after some discussions with the XFS folks:
>
> TL;DR: Don't rely on xfsdump to back up everything.
>
>
> There are things that can prevent xfsdump from successfully backing up a
> file on a live filesystem.  For example, changes to the file that happen
> during the backup *may* cause said file to not properly be stored in the
> xfsdump backup.  The unfortunate situation there is that you can have a
> backup where all of the files *seem* to be there, at least according to
> the file inventory in the dump, but when you go to restore them they
> won't actually be there.   Which IMO is the most catastrophic way that a
> backup can fail (silently on both backup and restore).
>
> ...
>
> I guess I've gotten spoiled with ZFS...
>

You can do a very similar, and (if I'm right, logically the exact same
thing) if your XFS filesystem resides on LVM, if you have (in this example,
more than 2GB) free space in the LVM volume group to create the snapshot
COW space.

lvm lvcreate --size 2g --snapshot --name
/dev/volumegroup/backupthis_snapshot yourvg/your_root # creates point in
time snapshot
xfsdump [options] /dev/volumegroup/backupthis_snapshot
lvm lvremove -f yourvg/backupthis_snapshot  # removes the snapshot, and
merges all changes back into the live fs.

Your dev names may be different; this is how they show up on a current
Sabayon system.
I've used this in practice to dump filesystems for backup purposes, both
with xfsdump as well as dd. A good script would call a mysql FLUSH TABLES
and then FLUSH TABLES WITH READ LOCK to quiesce the database before
snapshotting, and after the snapshot finishes, allow mysql to write again.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20161128/b600c57c/attachment.html>