[Comm] Очень странные проблемы с LVM

[Comm] Очень странные проблемы с LVM

[Eugene Prokopiev]

Здравствуйте!

Произошла такая жуткая история.

На машине жила система, целиком (за исключением /boot) размещенная на 
одной группе томов LVM. Затем эту систему забэкапили, используя 
снапшоты, cpio и bzip2, а машину отдали на растерзание. Что туда только 
не ставили, даже Solaris 10 x86. Короче, неважно. Важно то, что вчера на 
нее обратно водрузили тот же самый ALM2.4 из бэкапа, но логические тома 
LVM создали иначе, а именно: / уменьшили на 1Г (и все равно осталась 
куча места), /distrib увеличили на 2Г. Создавались LVM и файловые 
системы Кноппиксом, им же файлы из бэкапа копировались на диск.

Все запустилось без проблем, пару раз было перезагружено и оставлено на 
ночь. Сегодня потребовалось перегрузить машину еще раз. Перегрузка 
окончилась kernel panic. Загрузившись с Кноппикса, я увидел, что все 
логические тома приобрели свои первоначальные размеры, поэтому на / 
обнаружилась куча нечитаемых файлов и каталогов, а /distrib пострадал 
больше всех, т.к. его размер уменьшился (а размер fs - нет) и получилось 
вот что:

# fsck.ext3 /dev/system/distrib
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
Superblock has a bad ext3 journal (inode 8).
Clear<y>? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

Superblock doesn't have has_journal flag, but has ext3 journal inode.
Clear<y>? yes

The filesystem size (according to the superblock) is 3145728 blocks
The physical size of the device is 2621440 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>?

Ну и границы томов, наверное, сдвинулись, короче, произошла катастрофа ...


Проблема не в том, как вернуть все к жизни. А в том, что я такое 
умудрился сделать, что после всех издевательств система (какая?) решила 
вернуть логические тома на якобы причитающие им места, изуродовав тем 
самым файловые системы на этих томах? И почему не сразу, а на следующий 
день?

Могу показать скрипт, который выполнял бэкап:

#!/bin/bash -x
BACKUP_NAME=`hostname`-`date +%y.%m.%d-%H:%M:%S`
rm -rf /var/ftp/distrib/current-system-image/*
df -h > /var/ftp/distrib/current-system-image/$BACKUP_NAME.filesystems
lvcreate -L3000 -s -n rootbackup /dev/system/root
lvcreate -L1000 -s -n homebackup /dev/system/home
lvcreate -L1000 -s -n varbackup /dev/system/var
mount -o ro /dev/system/rootbackup /mnt/backup
mount -o ro /dev/system/homebackup /mnt/backup/home
mount -o ro /dev/system/varbackup /mnt/backup/var
mount -o ro /dev/sda1 /mnt/backup/boot
CURRENT_DIR=`pwd`
cd /mnt/backup
find ./ | cpio -o | bzip2 -9 -c > 
/var/ftp/distrib/current-system-image/$BACKUP_NAME.cpio.bz2
cd $CURRENT_DIR
umount /dev/sda1
umount /dev/system/varbackup
umount /dev/system/homebackup
umount /dev/system/rootbackup
lvremove -f /dev/system/rootbackup
lvremove -f /dev/system/homebackup
lvremove -f /dev/system/varbackup

Восстанавливалось все еще проще:

vgcreate
lvcreate
mkfs.ext3
cat backup.file | bzip2 -d -c | cpio -i --make-directories
chroot
lilo

--
С уважением, Прокопьев Евгений