Резервное копирование восстановление linux

Бэкап 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 не помог, поэтому перезагружаемся:

Подключаем донглы, проверяем, все работает.
Спасибо за внимание.

Источник

Вместе изучаем Linux. Резервное копирование и восстановление системы

Создание резервной копии

На прошлом занятии мы ознакомились с функциями Терминала. Перед тем как перейти к более сложным занятиям, мы остановимся на одном очень важном моменте, создании резервной копии системы.

Есть различные утилиты (как графические, так и консольные) для создания резервных копий. Мы остановимся и подробно рассмотрим программу QT5-FSArchiver (в графическом интерфейсе консольной утилиты FSArchive) в составе отличной сборки LiveCD Backup/Restore на базе *Ubuntu.

Сборка доступна в различных графических интерфейсах с одинаковыми наборами предустановленных инструментов (установкой некоторых из них займёмся в ближайшие дни).

И так, скачиваем сборку с Tux Comss LiveCD (на базе elementary OS Juno), создаем загрузочную флешку (например с помощью UNetBootin или с помощью любой другой привычной программы). Далее загружаемся с флешки, перед нами появляется стандартное окно запуска/установки Ubuntu, выбираем Запуск.

Загрузились с загрузочной флешки. Запускаем с рабочего стола программу QT5-FSArchiver (открывшийся терминал можно закрыть). Программа имеет различные настройки (кстати FSArchiver не записывает свободные блоки, а только непосредственно данные, таким образом уменьшая объем резервной копии), рекомендую их оставить по умолчанию. Добавлю, что опция «Архив за раскол» отвечает за разбивку архива на файлы выбранного объема. Повторюсь, настройки оставил по умолчанию. Для резервного копирования я выбрал копирование двух разделов, корневого и раздела пользовательских настроек /home. Данные разделы легко определить по типу файловой системы (скорее всего при установке выбрали тип файловой системы — Ext4) и по их объему.

В окне «Найденные разделы» указываем раздел, который хотим скопировать. В окне «Дерево каталогов» указываем место сохранения резервной копии (другой локальный диск), я выбрал диск ntfs (вспоминаем, что разделы монтированы в каталоге media). В окне «Имя образа » указываем название образа, рекомендую в нем же указать и имя раздела (в моем случае имя раздела — sdb2). Далее нажимаем на опцию «Сохранить раздел».

После окончания создания резервной копии, точно так же создаем резервную копию следующего раздела с типом файловой системы Ext4.

Кроме этого можно создать и резервную копию главной загрузочной области — MBR. Для создания копии MBR, открываем опцию «Действия» в главном окне программы QT5-FSArchiver и выбираем опцию «Save MBR-GPT, указываем место сохранения копии (можно указать ту же папку с ранее сделанными резервными копиями).

Восстановление разделов из резервной копии

Для восстановления разделов из резервных копий, в главном окне программы выбираем опцию «Восстановление раздела», в окне «Найденные разделы» указываем раздел в который будет выполнено восстановление. В окне «Файл образа» указываем ранее созданную резервную копию и нажимаем «Восстановить раздел».

Для того что бы восстановить копию MBR, открываем окно «Действие» и выбираем опцию «Restore MBR/GPT» и указываем место ранее сохранённой копии.

Ну вот и все, теперь мы умеет делать резервные копии разделов и с них восстанавливать разделы.

Очень порадовала скорость работы программы и наличие дружественного, интуитивно понятного интерфейса.

Источник

Резервное копирование и восстановление Linux сервера

Стратегия резервного копирования

Мир IT стремительно развивается, новые технологии берутся на вооружение, меняются принципы их использования, но одно правило, древнее как мир, не утратило своей актуальности: резервное копирование по правилу 3-2-1. Что оно из себя представляет:

(3) — создание минимум трёх копий данных. Чем больше тем лучше. Хорошей практикой является проверка резервных копий. Например, иногда развернуть её на тестовой площадке и убедиться в работоспособности резервной копии, ведь её наличие ещё не означает, что резервная копия не повреждена. Естественно, эти копии не следует держать в одном месте, и мы плавно переходим ко второму правилу.

(2) — данные должны быть размещены на двух разных носителях. Под носителями подразумеваются два разных автономных сервера, или площадки, куда копии будут делаться по очереди. Если одна из площадок выйдет из строя, у вас останутся резервные копии на второй.

(1) — одна копия данных должна находится вне стен вашей организации. Самый пессимистичный пункт, но он необходим. Одна копия должна храниться как можно дальше, на случай разного рожа ЧП (пожар, катаклизмы и т. д.)

Для резервного копирования существует большое множество специализированных систем и утилит. В данном руководстве мы рассмотрим штатные утилиты, которые должны быть на каждом Linux сервере, и с помощью которых можно без особых усилий обеспечить безопасность вашей инфраструктуры в вопросе хранения данных.

Резервное копирование rsync

rsync является возможно лучшей утилитой для синхронизации данных локально или в удаленный каталог. Использование rsync довольно простое и обладает рядом преимуществ:

• умеет в синхронизацию файлов по дереву каталогов;
• передача данных в один поток;
• позволяет при передаче данных сохранять симлинки, хардлинки, метаданные файлов, а так же права на файлы\каталоги;
• работает локально и по SSH;

Синтаксис использования следующий:

Остановимся подробно на опциях, на наиболее часто используемых. Список не полный, при необходимости вы можете обратиться к man

-v — Выводит подробную информацию о статусе копирования;

-q — «тихое копирование» (quiet), с минимальным выводом;

-R — Рекурсивное копирование с сохранением относительного пути (однако, не сохраняет метаданные и права файлов);

-a — Рекурсиваное копирование с сохранением атрибутов файлов;

-l — Копировать symlink;

-H — Копировать hardlink;

-u — Опция позволяет не перезаписывать файлы с более свежей датой модификации;

-L — Копировать содержимое ссылок;

-p — Сохраняет права владельца файлов;

-g — Сохраняет группу;

-t — Сохраняет время модификации файла;

-e — Изменение протокола синхронизации. Например, при использовании SSH;

-W — полное копирование данных, инкрементация не применяется.

Настройка сервера rsync

Для начала установим утилиту из репозитория на локальном и удаленном хостах:

Для Debian: root@dedicated:

# apt-get -y install rsync

Для RHEL/CentOS: root@dedicated:

# yum -y install rsync

Сразу привыкаем делать правильно 🙂 Копировать от root не самая лучшая идея, для этого создадим локального пользователя rbak, и зададим ему права sudo на использование только определенного софта:

В открывшемся конфигурационном файле, в блоке «User privilege specification» добавьте следующую строку:

Давайте проверим результат. Как видим, прав на запуск fdisk нет, но выполнение указанной выше утилиты разрешено:

Таким образом, мы пользователю rbak (состоящему в группе rbak) разрешили выполнение rsync от sudo. Теперь создадим локальный каталог для бекапа, для примера, пусть это будет в каталоге /home/rbak, и зададим правильные права:

Теперь перейдем к редактированию главного конфигурационного файла, добавив в него параметры: путь к каталогу для резервного копирования, ip адрес, с которого можно подключаться, uid и gid пользователя

Запустите службу и добавьте её в автозагрузку:

Примечание: Внимательный читатель может задать вопрос, зачем мы добавляли пользователя в sudo, с правами запуска rsync, когда достаточно было создать пользователя и назначить ему права на каталог с будущими резервными копиями. В зависимости от того, какую стратегию резервного копирования вы выберете, хорошей практикой является копирование не «С» локального сервера на удаленный, а именно запуск rsync c удаленного, который по тоннелю ssh будет подключаться к серверу который бекапиться, и забирать необходимые данные.

Зачем это нужно: Представьте, что ваш сервер заражен вредоносным кодом. Попадая на машину, в большинстве случаев, ему не составит труда просканировать каталоги, получив в том числе доступ к серверу резервных копий по ssh-keys пользователя root или пользователя rsync.

Примеры использования rsync

Пожалуй, первая опция, которую следует запомнить, это —dry-run. Если вы не уверены в использовании той или иной опции, решим эмуляции позволит увидеть результат выполнения без внесения изменений на продакт площадке:

Локальное копирование (синхронизация) каталога:

Если копируется каталог с большим колличеством данных и вы желаете видеть прогресс копирование, можно использовать ключ —progress.

Скопируем каталог с нашего сервера на удаленный по ssh:

Из результата следует, что каталог синхронизировался на удаленный сервер, рекурсивно скопировав все подкаталоги с файлами. Удобство использования rsync так же в том, что файлы синхронизируются инкрементально. Давайте на наш локальный сервер добавим в альбом композицию под номером 11 и запустим команду повторно:

Таким образом мы сэкономили время и пропускную способность канала, скопировав лишь новые файлы (или файлы, которые могли быть изменены). Это особенно важно при копировании больших объемов данных.

Синхронизация в обратную сторону, с удаленного хранилища в локальное, будет выглядеть следующим образом:

Если на удаленном сервере используется нестандартный порт для SSH соединения, укажите его:

Мы можем синхронизировать каталоги не полностью, а задать правило, по которому будет выполняться синхронизация c удаленного сервера по заданной маске. Допустим, нам нужно скопировать только конфиги c расширением *.conf:

С помощью опции —remove-source-files, после синхронизации данных на удаленный сервер, их можно автоматически удалить с локальной машины:

Допустим в локальном каталоге у нас 11 файлов, на удаленном хосте тоже 11, но локально мы удалили 1 файл. Синхронизировать необходимо существующее состояние каталога. Для этого существует опция —delete

rsync позволяет ограничить передачу файлов по размеру. Для этого используется опция —max-size, файлы превышающее его значение будут игнорироваться:

В зависимости от комплектующих, которое вы используете, может пригодиться ограничения по скорости копирования. Особенно это важно, если накопители на которые выполняется запись, ограничены в iops. С помощью опции —bwlimit можно ограничить скорость синхронизации, например, установив значение в 500 килобайт\секунда:

Если нам не требуется инкрементальная синхронизация, опция -W позволит выполнить полную синхронизацию каталога.

Что делать если нам необходимо с сервера rsync полключиться к удаленному серверу? Для этого в уже знакомом файле /etc/rsyncd.conf, в конце добавляем две строки:

В файл /etc/rsyncd.pass с новой строки пишем пользователей, и их пароли.

Так как пароли хранятся в открытом виде, обязательно ставим безопасные права. После чего перезапустите службу.

Резервное копирование Duplicity

Duplicity — это пакет, обеспечивающий версионное удаленное резервное копирование файлов на локальное или удаленное хранилище. При необходимости может быть настроенным зашифрованным с цифровой подписью. Важной особенностью является возможность копировать данные черзез SFTP, FTP, что делать rsync «без костылей» не умеет.

Принцип работы прост: локально, или на удаленный каталог, например по FTP, создается полная резервная копия каталога. При последующем использовании будет создаваться инкрементальная резервная копия, если не указано иначе. Восстановление возможно как из full бекапа, так и с инкрементальной копии по дате.

Установка и общие команды

Для примера, создадим резервную копию нашего сайта WordPress в каталог /home/backups/

—no-encryption — без шифрования;

—volsize=1024 — размер тома, сохраненный в /home/backups/;

—include=/var/www/wordpress — каталог, для которого создается бекап. При необходимости в одну строку вы можете указать несколько —include;

exclude=/** — исключить для резервирования все остальные файлы и каталоги;
file:// — локальный путь (При удаленном копировании на ftp, опция имела бы вид ftp://)

Далее нужно выполнить инкрементальный бекап. Для этого в целевом каталоге создадим info.php и запустим команду с опцией incremental

В каталоге /home/backups/ будут созданы полный и инкрементальный архивы *.gz

Отобразить резервные копии которые были нами созданы:

Выполним верификацию данных и последнюю версию резервной копии:

Теперь давайте выполним в каталог тестовый каталог /tmp/restore/ несколько примеров восстановления:

Успешным выполнением есть следующее:

Проверяем каталог /tmp/restore/, в котором от корня скопировано дерево каталогов нашего сайта (/tmp/restore/var/www/wordpress). Восстановился последний инкрементальный бекап с файлом info.php

Выполним проверку по количеству файлов:

Восстановить определенный каталог можно командой (аналогично можно указать путь к файлу). Удалим каталог plugins и запустим восстановление

Мы так же можем восстановить бекап десятидневной давности. Для этого существуют ключи «-t 10D»:

10D — количество дней. Другие возможные опции: секунды (s), минуты (m), часы (h), дни (D), недели (W), месяцы (M), годы (Y).

Удалить бекапы старше 14 дней:

Удаленное копирование

Установим необходимые зависимости:

Команда удаленного копирования на FTP будет выглядеть так:

где: cf900585 — логин; yq77q1Ad14hD — пароль; backup60.freehost.com.ua — сервер резервных копий; 21 — порт.

В целом, особенно использование duplicity удобно с помощью скриптов, так как необходимо указывать множество параметров. В данном примере мы рассмотрим, как можно скопировать наш каталог wordpress и на удаленный ftp сервер. И настроить автоматическое удаление резервных копий старше 14 дней.

Если на удаленном FTP сервере нужно явно указать каталог, создайте переменную $DESTFOLDER

Ставим его на выполнение и зппускаем:

Выше рассмотрены далеко не все возможности Duplicity, с полным перечнем вы можете ознакомиться обратившись к официальной документации.

Копирование диска с помощью dd

При резервном копировании так же очень полезна будет стандартная утилита dd (dataset definition). С помощью этой простой утилиты можно создать полный клон диска сервера. При этом он будет занимать такое же место, как и исходный носитель. Другими словами, если, например, диск /dev/vda1 имеет емкость 20Gb, с которых информации на 15Gb, то образ все равно будет занимать 20Gb, куда по блокам будет выполнено полное зеркалирование исходного носителя.

где: if — исходный носитель; of — куда копируем (имя копии). Соответственно, при восстановлении, меняем местами if и of, указывая правильные пути для восстановления.

Команда dd имеет на вооружении некоторый опции, рассмотрим некоторые из них:

bs=8M — по умолчанию копирование выполняется по 512 байт «за раз», ускорить выполнения копирования можно увеличением кеша bs. Однако, увлекаться с ускорением зеркалирования не стоит, рекомендованное значение — 2-4-8М;
sync — данные которые повреждены будут заменены на нули;

noerror — копирование будет выполняться даже при наличии бэд-блоков на носителе;
status=progress — отображает прогресс копирования носителя;

Выполнить удаленное копирование по SSH:

Выполнить удаленное копирование по SSH с максимальным сжатием:

Команда dd полезна не только при резервном копировании. Если диски ранее использовались в RAID массивах, на них могут остаться данные которые обязательно нужно удалить. Полностью «занулить» диск можно командой:

Удалить данные можно частично. Следующая команда удалит первые 20Mb

Возможно нужно затереть еще конец диска , т.к. данные о разметке, raid могут храниться еще в конце диска. Смотрим общее кол-во секторов:

Чистим конец диска , указываем с какого сектора начинать (я отнимаю приблизительно 20 — обычно хватает)

seek — опция указывает на то, сколько необходимо пропустить количество байт (obs-size блоков) в начале вывода;

C полным перечнем опций можно ознакомиться в man

Заключение

Мы рассмотрели три простые, но в тоже время мощные утилиты, которые следует взять на вооружение каждому администратору. Важно так же следовать стратегии «3-2-1». С нашей стороны мы выполняем нашу часть обязательств, предоставляя бесплатное место для хранения резервных копий на FTP сервере, в размере 20Gb для виртуальных VPS серверов и физических серверов, куда вы можете самостоятельно настроить резервное копирование. Кроме этого мы делаем недельный бекап виртуальных VPS серверов, что позволяет откатить состояние сервера на исходную дату в несколько минут. Так же мы предлагаем обратить внимание на дополнительное высоконадежное облачное хранилище CEPH, которое мы предоставляем. Хранилище использует технологию, позволяющую хранить информацию на распределенном компьютерном кластере с тройным дублированием данных за вполне доступную сумму. Стоимость за 1 Gb составляет 2.68 грн. в месяц. Даже если ваша инфраструктура расположена в другом дата-центре или личной серверной, заказав самый простой VPS, и подключив к нему облачное хранилище CEPH, вы получаете отказоустойчивый сервер для хранения резервных копий, который позволит обеспечить надежность вашей инфраструктуры по стратегии 3-2-1.

Источник