On 06/24/2015 12:06 PM, Chris Adams wrote:
LVM snapshots make it easy to get point-in-time consistent backups,
including databases. For example, with MySQL, you can freeze and flush
all the databases, snapshot the LV, and release the freeze.
Exactly. And I mention this from time to time... I'm working on
infrastructure to make that more common and more consistent:
https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot
If you're interested in testing or development (or even advocacy), I'd
love to have more people contributing.
That also avoids the access-time churn (for backup programs that
don't know O_NOATIME, like any that use rsync).
Yes, though rsync based systems are usually always-incremental, so they
won't access files that haven't been modified, and impact on atime is
minimal after the first backup.
That's server stuff. On a desktop with a combination of SSD and
"spinning rust" drives, LVM can give you transparent SSD caching of
"hot" data (rather than you having to put some filesystems on SSD and
some on hard drive).
Interesting. I wasn't aware that LVM had that option. I've been
looking at bcache and dm-cache. I'll have to look into that as well.
Now, if btrfs ever gets all the kinks worked out (and has a stable
"fsck" for the corner cases), it integrates volume management into the
filesystem, which makes some of the management easier.
btrfs and zfs are also more reliable than RAID. If a bit flips in a
RAID set, all that can be determined is that the blocks are not
consistent. There's no information about which blocks are correct, or
how to repair the inconsistency. btrfs and zfs *do* have that
information, so they can repair those errors correctly. As much as I
like LVM today, I look forward to ditching RAID and LVM in favor of btrfs.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
