Alt linux резервное копирование
Этот документ предназначен для пользователей Linux , желающих научиться самостоятельно выполнять резервное копирование информации своего компьютера.
Документ не является специфичным для ALT Linux. Полученные знания можно применять как к другим дистрибутивам Linux , так и к различным вариантам UNIX . Вы узнаете о возможностях регулярного резервного копирования, предоставляемых программами GNU tar и cron .
В наше время резервное копирование информации необходимо хотя бы по той причине, что ее потеря может сильно сказаться на времени, необходимом для восстановления испорченных или потерянных данных. Принятие простых мер поможет избежать необратимых последствий.
Хотя своевременное резервное копирование и не спасет вас от всех возможных проблем с испорченными данными, оно, по крайней мере, сделает возможным восстановление сохраненной информации.
Создание резервных копий
Количество информации, которую вы сможете восстановить, во многом зависит от того, как часто вы ее сохраняете и насколько надежно храните.
Для начала определитесь с тем, где вы будите хранить backup-копии. Наилучшим решением для домашнего компьютера является использование отдельного жесткого диска, но, к сожалению, не у всех есть такая возможность. Поэтому, скорее всего, вы будете сохранять копии в отдельной директории или на отдельном разделе жесткого диска и периодически переписывать их на CD-R(W) или DVD-R(W).
Предостережение
Не используйте некачественные носители для сохранения резервных копий! Информация может быть дороже денег, затраченных на покупку качественных носителей.
Вне зависимости от того, где физически будет располагаться директория для сохранения копий, далее будем предполагать, что это директория /backup .
В простейшем случае скрипт для сохранение backup-копии будет выглядеть следующим образом:
В этом скрипте нет ничего особенного, но основные принципы он демонстрирует:
Сохранение и сжатие директории /home (домашние директории пользователей) в отдельный файл;
Сохранение и сжатие директории /etc (общие системные настройки) в отдельный файл.
Рассмотрим использованные опции команды tar :
Сжать файл с использованием gzip
Создать новый архив
Использовать указанный файл
Предостережение
В случае порчи хотя бы нескольких байт сжатого резервного архива исключается возможность восстановления файлов из этого архива, даже если восстанавливаемый файл не находится в поврежденной области. Поэтому, на такие носители как магнитная лента резервные копии предпочтительнее записывать в не сжатом виде. Для этого не нужно указывать опцию -z команды tar .
Следующий скрипт реализует более широкие возможности для сохранения backup-копии:
В данном примере сохраняются не отдельные директории, а корневая директория / , исключая /proc , /var , /mnt , /usr и, конечно, /backup . Также к имени файла добавляется дата создания резервной копии.
Дополнительно к уже рассмотренным были задействованы следующие опции команды tar :
Выводить список обработанных файлов
Сохранять информацию о правах доступа
Директория для сохранения в архив
Исключить директорию при сохранении в архив
Вы можете комбинировать оба предложенных варианта. Например, использовать первый скрипт ежедневно для ручного резервного копирования, а второй запускать по расписанию раз в неделю для полного сохранения.
Замечание
Если вы решили использовать отдельный HDD для резервных копий, то вам подойдет следующее решение.
Для начала подключите предварительно отформатированный HDD. Далее подразумевается, что это /dev/hdb1 , т. е. первый раздел на втором диске канала IDE 1. Создайте точку монтирования:
Дополните ваши скрипты для резервного копирования следующими строками:
Со временем вы сами разработаете наиболее удобный и эффективный для вас способ проведения регулярного резервного копирования. Например, вы можете исключить директории (опция —exclude ) с музыкой и фильмами из списка резервируемых директории.
Резервное копирование по расписанию
Далее вам предстоит настроить запуск скрипта по расписанию. На самом деле нет ничего проще. Со времен ОС UNIX существует программа cron , предназначенная для выполнения действий по расписанию. Откройте файл /etc/crontab и запишите новое правило:
Это правило будет выполняться каждую пятницу в 1 час ночи. Для указания удобного для вас времени запишите нужные значения в соответствующих колонках. В примере предполагается, что командой резервного копирования является /usr/bin/full-backup . Замените эту команду на имя вашего скрипта.
Результат работы будет отправлен пользователю root по почте (при условии, что у вас настроен SMTP -сервер).
Восстановление из резервных копий
Ниже приведены основные команды для восстановления файлов из архива резервной копии. Перед замещением существующего файла убедитесь, что замена действительно необходима!
Перед извлечением файлов из резервной копии бывает необходимым просмотреть содержимое архива. Для этого укажите опцию -t команды tar . Например, следующая команда позволит просмотреть содержимое архива /backup/backup-07-March-2005.tar.gz :
Подсказка
Не забывайте о конвейерах. Для поиска файла в архиве вы можете использовать программу GNU grep :
Для извлечения файлов из архива предназначена опция -x команды tar . Например, следующая команда восстановит все файлы из архива /backup/backup-12-March-2005.tar.gz :
Для восстановления определенных файлов из архива укажите их имена после имени архива. Например, следующая команда восстановит файлы home/alenitchev/adt/backup.xml и etc/sendmail.cf из архива /backup/backup-17-March-2005.tar.gz :
Перед восстановлением файла из резервной копии убедитесь, что восстанавливаемый файл не заменит более новый экземпляр.
Источник
Сказка о птице фениксе.
Очень часто пользователи и системные администраторы Linux считают, что счастье может исходить только от больших вендоров типа RedHat, SuSE или Ubuntu. В связи с этим хочу поведать о приятных мелочах имеющихся в дистрибутиве от производителя не такого большого масштаба.
В этот раз речь пойдёт о лёгком и безболезненном восстановленнии системы из праха. Возьмём для примера последнюю бету версию ALT Linux 5.0 Office Server и установим его на какой-нибудь компьютер.
Процесс установки мало чем отличается от аналогичного у других продуктов. На шаге подготовки диска для дальнейших экспериментов создадим два раздела. Один будет использоваться для системы, а второй для хранения резервной копии.
Сразу после этого шага мы неожиданно оказываемся на развилке: продолжать установку новой системы или восстановить её из резервной копии. Интересно, неожиданно, непонятно, но поскольку восстанавливать нам пока нечего, то просто продолжим процесс установки.
Далее слава богу всё как обычно. Устанавливаются пакеты и через некоторое время мы можем наблюдать центр управления интерфейсом.
Не буду останавливаться подробно на самом центре управления. Нас интересует модуль настройки под названием «Восстановление системы».
В этом диалоге включается/выключается служба создания резервных копий, отображается самая важная информация, а также производится восстановление отдельных файлов и каталогов. Имеются также две кнопки ведущие в дополнительные диалоги: выбор диска и более детальное управление процессом резервного копирования.
Настройка расписания резервного копирования состоит фактически только из указания времени начала процесса. Но да не введёт вас в заблуждение эта простота. Резервное копирование будет разным в разные дни недели: в будни — это инкрементальное, в выходные — полное или дифференциальное. Более того, система резервного копирования (bacula) достаточно умная для того, чтобы понять : если нет ближайшей полной копии, то надо делать не инкрементальную копию, а полную.
Перейдём в раздел смены диска и укажем в качестве диска тот самый созданный дополнительный раздел. В качестве диска можно указать любой раздел на дополнительном диске (включая внешний USB), имеющий одну из следующих файловых систем:
- ext,ext2,ext3,ext4
- xfs
- ntfs
Файловая система vfat не поддерживается, поскольку файлы с резервной копией могут быть очень большого размера.
Не стоит беспокоится о том смонтирован ли раздел в системе постоянно (есть запись в /etc/fstab) или нет. Модуль сам позаботится об этом. Если раздел не прописан в /etc/fstab, то он там будет прописан автоматически и при последующих перезагрузках системы всё снова окажется на своих местах. В корне выбранного раздела будет создана папка backup, в ней будут храниться файлы с резервными копиями. Если на диске уже были резервные копии, то при подключении его они удалены не будут, но затрутся со временем. Обратите внимание: при смене диска полностью теряется история резервных копий во внутренней базе данных сервера.
Здесь же, при смене диска, указывается время хранения резервных копий. Чем меньше период хранения, тем меньше будет расход места на диске. Поскольку, как было сказано выше, смена диска не разрушает его содержимого, то для того, чтобы увидеть результаты уменьшения периода хранения, надо будет вручную, перед подключением диска, удалить папку backup и всё её содержимое.
Перейдём в раздел дополнительных настроек резервного копирования. Здесь можно увидеть когда и с каким результатом создавались резервные копии, запустить процесс резервного копирования вне расписания или наоборот экстренно остановить этот процесс. Также настраивается список файлов для резервного копирования, а точнее список каталогов которые не надо копировать. Чем меньше копируется данных — тем меньше расход места на диске с архивом, но тем меньше шансов восстановить всю систему целиком.
В этот список автоматически добавляются системные каталоги типа /proc, а также раздел содержащий резервную копию. Настроек по умолчанию достаточно, чтобы корректно создать резервную копию всей системы, даже если эта система физически размещена на нескольких разделах и дисках.
Пусть система настроена и работает, каждый день создаются резервные копии всей системы, вы счастливы и беззаботны как вдруг . вы убиваете всю систему неловким вводом команды типа «rm -rf — /etc». Всё пропало? Нет!
Радостно достаём с полки тот самый диск с которого ставили систему. Проходим несколько первых шагов инсталлятора, вновь разбиваем диск, не забывая, что один важный раздел трогать нельзя ибо там хранится резервная копия. Доходим до загадочной развилки и на этот раз выбираем режим «восстановить систему».
Инсталлятор рыскает по доступным дискам, находит резервную копию на заботливо оставленном разделе, восстанавливает внутреннюю базу данных bacula и предлагает нам выбрать дату на которую будем восстанавливать систему:
Далее вместо установки пакетов наблюдаем восстановление данных.
Больше вопросов по ходу восстановления системы не задаётся, но это не значит, что всё так просто. На самом деле в установленной системе будет автоматически приведён в соответствие с действительностью файл /etc/fstab (иначе она просто не загрузится), а также будет переделан заново файл initrd. Последнее означает, что восстанавливать систему можно на другом оборудовании. Если у вас не просто был удалён каталог /etc, а целиком сломался компьютер, то на новом можно не ставить новую систему, а попытаться по максимуму восстановить то, что было до этого.
В дополнение хочется добавить, что система резервного копирования bacula, которая лежит в основе описываемого модуля, имеет очень развитые средства восстановления в чрезвычайных ситуациях. Поэтому если не сработала автоматика не отчаивайтесь. В комплекте есть утилиты утилиты bls, bextract и bscan, c помощью которых опытный системный администратор восстановит систему даже в самом казалось бы безнадёжном случае.
Через некоторое время процесс восстановления завершается, заново устанавливаем загрузчик и собственно всё готово.
Вы себе наверное даже и не представляете какое это счастье увидить вновь старую и хорошо знакомую систему!
Источник
Бэкап Linux и восстановление его на другом железе
Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.
На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:
- сделать бэкап сервера;
- восстановить бэкап на другом железе.
Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.
Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги 🙂
Ниже я описываю свой частный случай и почему я поступил именно так. Надеюсь, новичкам будет полезно, а бородатые админы улыбнутся вспомнив молодость.
Начинаем копать теорию:
Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.
Итак, план действия:
1. Создание бэкапа
Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.
Переключаемся на root:
Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd или df -l
Наша флэшка уже примонтирована, но в режиме только чтения, нужно перемонтировать для чтения-записи, чтобы писать туда бэкап.
Все готово для создания архива
Здесь у нас параметры: c — создать архив, v — выводить информацию о процессе, z — использовать сжатие gzip, p — сохраняем данные о владельцах и правах доступа, f — пишем архив в файл, путь к файлу, —exclude — исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ — каталог, который архивируем.
Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.
Складываем архив в надежное место за пределами офиса.
Восстановление бэкапа на другом железе
2. Размечаем диск, создаем файловую систему
Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.
Переключаемся на root:
Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.
Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй — 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.
Cоздаем файловую систему на первом разделе.
3. Распаковываем архив.
Монтируем отформатированный раздел
Распаковываем архив прямо с флэшки
Параметр —same-owner — сохраняет владельцев у распаковываемых файлов, x — извлекаем из архива, v — выводить информацию о процессе, p — сохраняем права доступа, f — указываем файл, который распаковываем, C — распаковываем в категорию.
4. Создаем MBR на новом диске.
Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:
Переключаемся на новую систему используя chroot:
Делаем swap-раздел для новой системы:
Подключаем его же:
Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:
Открываем второй терминал (Alt+F2) под root:
И видим текущие UUID разделов.
Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.
Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:
На чистый диск должно встать без ошибок. Обновляем информацию из fstab:
Возвращаемся в Live-систему:
Размонтируем все каталоги:
Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.
Все, поехали. Грузимся с жесткого диска:
Здесь статья должна была закончиться, но у меня возникли проблемы с подключением к интернету. Сервер видит сеть, видит компьютеры в ней, но в интернет не ходит… а это как бы важно для телефонии.
5. Тестирование и устранение неполадок.
Показывет интерфейсы eth1 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.
Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:
Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.
Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:
Подключаем донглы, проверяем, все работает.
Спасибо за внимание.
Источник