From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4289CDE7.20201@stc.donpac.ru> Date: Tue, 17 May 2005 14:56:39 +0400 From: Eugene Prokopiev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040808 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Community@altlinux.ru Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: [Comm] =?koi8-r?b?797Fztgg09TSwc7O2cUg0NLPwszFzdkg0yBMVk0=?= X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 10:57:06 -0000 X-List-Received-Date: Tue, 17 May 2005 10:57:06 -0000 Archived-At: List-Archive: List-Post: Здравствуйте! Произошла такая жуткая история. На машине жила система, целиком (за исключением /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? yes *** ext3 journal has been deleted - filesystem is now ext2 only *** Superblock doesn't have has_journal flag, but has ext3 journal inode. Clear? 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? Ну и границы томов, наверное, сдвинулись, короче, произошла катастрофа ... Проблема не в том, как вернуть все к жизни. А в том, что я такое умудрился сделать, что после всех издевательств система (какая?) решила вернуть логические тома на якобы причитающие им места, изуродовав тем самым файловые системы на этих томах? И почему не сразу, а на следующий день? Могу показать скрипт, который выполнял бэкап: #!/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 -- С уважением, Прокопьев Евгений