В системе RHEL5.4 я настраиваю сценарий для резервного копирования диска с копией dd каждую ночь с помощью cron. Я плюю вывод dd в файл журнала и отправляю электронное письмо. Он находится в / etc / crontab и / var / spool / cron / root, когда я понял, что он даже не будет работать под cron.
Предполагается, что сценарий копирует / dev / sda в /mnt/backup/sda.img (/ mnt / backup - это смонтированный внешний 250 ГБ).
Когда я запускаю его как root на терминале, он работает нормально, я вижу, что данные записываются на диск, а sda.img становится больше.
Однако при запуске от имени cron я получаю вывод от dd, в котором говорится, что он скопировал 147 ГБ, но не могу найти, куда он сплюнул эти 147 ГБ - он не поместил его в sda.img. Его нигде нет в файловой системе, так как на нем осталось всего 50 ГБ.
Куда оно делось? И как я могу убедиться, что в cron происходит то же самое, что и в терминале.
Я останавливаю crond и запускаю его до и после резервного копирования, однако у меня сложилось впечатление, что cron запускает задание, я закрываю его, он выполняет резервное копирование, запускается снова и продолжает свой веселый путь.
Спасибо.
РЕДАКТИРОВАТЬ: Извините, строка dd
dd if = / dev / sda of = / mnt / backup / sda.img bs = 400 КБ
И строка cron
01 0 * * * 2-6 /root/applog_backup.sh
Я могу получить доступ к файлам, когда он работает с
mount -o loop, смещение = 32256 sda.img / mnt / restore
Я выключил cron, чтобы почасовые задания не могли изменять диск во время резервного копирования. Я также отключил другие службы и производственную базу данных, чтобы свести к минимуму запись на диск в важных местах.
У вас есть сценарий "резервного копирования", выполняемый cron ... и вы закрываете cron в сценарии, чтобы предотвратить выполнение заданий cron во время "резервного копирования". Вы действительно не видите, в чем проблема? Ваш скрипт завершает работу crond, но crond запускает ваш скрипт, поэтому завершение работы crond закроет дескрипторы, подключенные к вашему скрипту, которые затем умрут либо из-за сломанного канала, либо из-за сигнала прерывания от самого crond.
Поскольку скрипт умер, crond больше не будет перезапущен. Это то, что мы называем «выстрелил себе в ногу».
Даже после перезапуска crond он не зарегистрирует, что задание завершено, поскольку оно было отключено во время выполнения и / или должно было сигнализировать о завершении. Либо сам crond, либо anacron (зависит от того, какой планировщик cron вы используете), ему придется снова запустить задание, что потенциально может зайти в бесконечный цикл.
Ваша проблема - отличный пример всего, что не так с изобретением собственного «резервного» решения, если у вас нет реального опыта управления надежностью и аварийного восстановления. Хуже того, незнание того, как работает система.
Первое и самое главное, вы не делаете необработанный дамп диска в живой файловой системе. Файловые системы были изобретены для того, чтобы вы не касались напрямую необработанного содержимого диска. Вы хотите сохранить файлы, хранящиеся в файловой системе, это то, что для вас важно. Итак, вы должны получить к ним доступ через файловую систему, а не необработанные байты, хранящиеся на диске. Если раздел смонтирован, нет абсолютно никакой гарантии, что ваши данные действительно хранятся на диске и что диск останется в согласованном состоянии во время копирования.
Даже если бы вы могли сделать снимок состояния диска с возможностью восстановления (например, внезапный сбой питания, который можно было бы быстро исправить с помощью журналируемой файловой системы, такой как ext3), это никогда не произойдет с горячим дампом диска. Создание дампа диска занимает много времени, между началом и концом дампа существует практически бесконечное количество промежуточных состояний, и дамп будет содержать смесь этих состояний, которые потенциально невозможно восстановить даже с журналируемой файловой системой.
И я все еще не упомянул обо всем остальном, что не так с резервными копиями сырого дампа диска:
Многие люди были там и могут поделиться большим опытом в области аварийного восстановления. Не пытайтесь изобрести собственное решение для резервного копирования, иначе вы все испортите. Используйте подходящие средства резервного копирования, например свалка, деготь или rsync. Если вам нужно что-то более надежное, используйте Аманда или Bacula, или одно из сотен других готовых к использованию решений.
Вероятно, не тот ответ, которого вы ожидали, но его нужно было сказать.
Пожалуйста, пожалуйста, не используйте dd делать резервные копии вашего физического тома по всем причинам, указанным в комментариях к вашему вопросу.
По крайней мере, если вы хотите делать резервные копии с диска на диск, используйте что-то вроде rsync (хотя даже это не без проблем), и возвращайтесь сюда, если вы не можете заставить это работать из cron.
Я подозреваю, что ваша строка cron неверна. Пожалуйста, отредактируйте ваш файл crontab, указав следующие записи:
1 0 * * 2-6 /root/applog_backup.sh
Сообщите мне, решит ли это вашу проблему.
Я бы посоветовал вам найти время и изучить продукт под названием Bacula. Это открытый исходный код (бесплатно!), И он отлично справляется со своей задачей. Его сложно настроить, но как только вы начнете, вы забудете о резервных копиях больше никогда.