请留意这个警告。而且看来至少有些内核或LVM的版本在使用这个命令时有问题。我是用2.3.99pre6-2来测试的，它可以工作，但要警告。 

现在，/dev/hda1没有包含任何物理分区了，我们可以将它从卷组中删除： 

# vgreduce test1 /dev/hda1 
vgreduce -- doing automatic backup of volume group "test1" 
vgreduce -- volume group "test1" successfully reduced by physical volume: 
vgreduce -- /dev/hda1 

FIXME: we need clarity on a few things. Should the volume group be active? When do we get data loss? 

6.1 当事情发生在晚期时 
如果一个磁盘没有出现警告就失败了，你就不能移走它上面的物理分区到另一个物理卷上，这样你可能会丢失数据，除非在这个失败的PV上的逻辑卷是镜像了的。正确的行为是用一个同样的PV或者至少同样大小的分区来替换这个失败的PV。 

/etc/lvmconf目录包含了LVM数据和结构的备份，包括哪些磁盘做成了PV，每个PV属于哪个VG，每个VG中有哪些LV。 

替换了出错的磁盘之后，你可以用vgcfgrestor命令来恢复LVM数据到新的PV上。它恢复卷组和所有它的信息，但是不会恢复在逻辑卷上的数据。这是因为当LVM数据做一些更改时，LVM命令自动做备份。 

-------------------------------------------------------------------------------- 

7. 为一致性备份做快照 
这是更加难以置信的一个可能性。假设你有一个非常繁忙的服务器，有许多东西运行。为了一个有用的备份，你需要停止大量的程序，否则，你将以数据不一致告终。 

一个规范的例子是从/tmp移动一个文件到/root下，而且/root将先备份。当/root被读的时候，这个文件还不在那里。当/tmp被备份时，这个文件已经不在了。 

另一个事例是保存数据库或目录。如果一个文件在使用状态，我们就没有任何线索了，除非我们给应用程序时间做一个清除的关闭。 

这样的话，新的问题又出现了。我们关闭程序，做我们的备份，接着重新启动它们。如果备份只花几分钟这是很好的，但是，如果它要花数小时，或者你根本不确定它到底要花多久的时候，事情就真的痛苦了。 

LVM可以营救。 

使用LVM，我们可以做一个LV瞬间的快照，然后mount它，再备份它。 

让我们试验一下： 

# mount /dev/test/HOWTO /mnt 
# echo > /mnt/a.test.file 
# ls /mnt/ 
a.test.file lost+found 
# ls -l /mnt/ 
total 13 
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file 
drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found 

Ok，我们现在有些事情要用它一起做。让我们产生这个快照： 

# lvcreate --size 16m --snapshot --name snap /dev/test/HOWTO 
lvcreate -- WARNING: all snapshots will be disabled if more than 16 MB are changed 
lvcreate -- INFO: using default snapshot chunk size of 64 KB 
lvcreate -- doing automatic backup of "test" 
lvcreate -- logical volume "/dev/test/HOWTO" successfully created 

对于“--size”参数以后再详述。让我们mount这个快照： 

# mount /dev/test/snap /snap 
# ls /snap 
total 13 
-rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file