как сделать бэкап сервера linux
Бэкап Linux и восстановление его на другом железе
Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.
На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:
Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги 🙂
Ниже я описываю свой частный случай и почему я поступил именно так. Надеюсь, новичкам будет полезно, а бородатые админы улыбнутся вспомнив молодость.
Начинаем копать теорию:
Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.
Итак, план действия:
1. Создание бэкапа
Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.
Переключаемся на root:
Наша флэшка уже примонтирована, но в режиме только чтения, нужно перемонтировать для чтения-записи, чтобы писать туда бэкап.
Все готово для создания архива
Ждем… у меня вся подготовка и создание архива заняли 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. Распаковываем архив.
Монтируем отформатированный раздел
Распаковываем архив прямо с флэшки
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 не помог, поэтому перезагружаемся:
Подключаем донглы, проверяем, все работает.
Спасибо за внимание.
Организация backup-сервера. Linux, ZFS и rsync
TL;DR:
Статья о настройке бекапа линуксовых серверов. В качестве хранилища используется раздел ZFS с включенными дедубликацией и компрессией. Ежедневно делаются снапшоты, которые сохраняются в течение недели (7 штук). Ежемесячные снапшоты хранятся в течение года (еще 12 штук). В качестве транспорта выступает rsync: на сервере он запущен демоном, на клиентах он запускается из crontab.
Так получилось, что у меня есть пара серверов, на которых под KVM живут виртуальные машины. Хотелось бекапить образы этих машин в сеть, но так, чтобы выполнялись условия:
Можно ли всё это совместить? Да, и очень просто.
Все компьютеры, о которых идет речь в этой статье, являются серверами. Но как-то глупо и длинно делить их на “сервер, который хранит бекапы” и “сервер, бекапы которого хранит сервер, который хранит бекапы”. Поэтому первый я буду называть просто сервером, а второй уже начал называть клиентом.
1. ZFS с компрессией и дедубликацией
Наиболее привычная для меня ОС – Linux. Всё то же самое без особых изменений должно подойти и к Solaris, и к FreeBSD, в которых ZFS есть давно и что называется “из коробки”. Но Linux мне ближе и роднее, а проект по портированию на него ZFS выглядит уже достаточно зрелым. За год экспериментов у меня не было с ним заметных проблем. Поэтому поставил на сервер Debian Wheezy, подключил официальный репозитарий проекта и установил нужные пакеты.
Создал пул, указав что zfs у меня будет на /dev/md1 и что монтировать эту файловую систему я хочу к каталогу /mnt/backup:
По имени устройства /dev/md1 можно заметить, что я использую линуксовый software raid. Да, я знаю, что у ZFS есть свой способ создавать зеркала. Но поскольку на этой машине уже есть одно зеркало (для корневого раздела) и оно сделано штатным mdadm, то и для второго зеркала я предпочту использовать его же.
Включил дедубликацию и компрессию, сделал видимым каталог со снапшотами:
Положил в /usr/local/bin скрипт для создания снапшотов:
Этот скрипт добавил в crontab для ежедневного запуска. Чтобы содержимое снапшота соответствовало его дате, скрипт лучше запускать ближе к концу суток. Например, в 23:55.
Четвертое число месяца выбрано почти случайно. Запускал я всё этого третьего августа и хотелось поскорее сделать бекап, который будет храниться год. Следующий день был четвертым.
Снапшоты будут сохраняться в каталоге /mnt/backup/.zfs/snapshot. Каждый снапшот – отдельный каталог с именем в виде даты на момент создания этого снапшота. Внутри снапшота полная копия каталога /mnt/backup в том виде, в котором он был в этот момент.
2. Rsync на сервере
Традиционно rsync настраивают для работы поверх ssh. На клиентах настраивается авторизация по ключам (и без пароля), а эти ключи складываются на бекап-сервер. Сервер ходит по ssh на клиентов и забирает с них файлы. Преимущество этого подхода – шифрование трафика. Но мне не нравится идея с беспарольным входом по ssh (особенно в свете последних уязвимостей в bash). Так же мне не нравится идея инициировать бекап со стороны сервера: иногда перед бекапом на клиенте хочется выполнить какой-нибудь скрипт (например, сбросить дамп mysql), и только после завершения этого скрипта начинать бекап. Поэтому мой выбор – rsync, запущенный демоном на сервере и запускаемый из crontab на клиентах.
Поставил на сервер rsync (штатный, из репозитария), и чтобы он запускался при старте системы, написал в /etc/default/rsync:
Создал на сервере /etc/rsyncd.conf такого содержания:
192.168.xxx.xxx и 192.168.xxx.yyy – это адреса тех серверов, которые будут бекапиться. Зовут их kvm01 и kvm02. Их файлы будут лежать в /mnt/backup/kvm01 и /mnt/backup/kvm02. Поэтому:
3. Rsync на клиентах
Минимально необходимый скрипт для копирования файлов с клиента kvm02 на сервер с адресом 192.168.xxx.zzz будет выглядеть примерно так:
Разумется, если речь идет о бекапе виртуальных машин, то этот скрипт стоит пополнить командами создания и удаления LVM-снапшота, монтирования и отмонтирования его содержимого и так далее. Но эта тема уже выходит за рамки данной статьи.
4. Восстановление
Для восстановления файлов из бекапа клиента KVM01 за 4 августа 2014 года достаточно будет на сервере перейти в каталог /mnt/backup/.zfs/snapshot/2014-08-04/kvm01/ и скопировать оттуда файлы любым привычным способом. Каждый конкретный бекап выглядит как обычный каталог, доступный только для чтения. Для поиска определенного файла в этом бекапе можно использовать стандартные утилиты, такие как find или grep.
5. Заключение
Сейчас на сервере 9 снапшотов: 7 ежедневных и 2 ежемесячных. Плюс сегодняшний бекап, снапшот с которого снимется вечером. Размер раздела с бекапами составляет 1.8T. Общий объем файлов — 3.06T. Физически занимают на диске они 318G. Суммарный объем сегодняшнего бекапа — 319G. Да, 10 бекапов на ZFS с компрессией и дедубликацией занимают места меньше, чем один бекап занимал бы на файловой системе без этих полезных свойств.
Поскольку сам rsync не занимается шифрованием передаваемых данных, высовывать такую схему без изменений в интернет небезопасно. Добавить шифрование можно, пустив трафик через ipsec или stunnel, например.
Выше я написал, что заметных проблем с ZFS у меня не было. На самом деле, одна проблема была. Однажды ночью, когда оба клиента активно бекапились, сервер дважды сообщил в dmesg, что task rsync blocked for more than 120 seconds. При этом оба бекапа успешно завершились, ничего не зависло, данные не потерялись. Подозреваю, что это проявление знаменитого бага 12309. Разнес бекапы по времени, с тех пор проблема не повторялась.
Программы резервного копирования Linux
Системные администраторы шутят, что люди делятся на два типа: те кто не делает резервные копии и те, кто уже делает резервные копии. В работе любого пользователя или системного администратора рано или поздно возникнет момент, когда что-то сломается и важные данные будут утеряны. Если до этого человек резервных копий не делал, то теперь научится и начнёт делать.
Если для домашних пользователей это, в принципе, не очень актуально, то для производственных серверов потеря данных может привести к большим финансовым потерям, поэтому важно всегда иметь хотя бы копию файлов и базы данных просто на всякий случай. В этой статье мы рассмотрим основные инструменты, которые можно использовать для резервного копирования различных элементов системы.
Программы для резервного копирования в Linux
1. Rsync
Утилита rsync не предназначена специально для резервного копирования, но её можно для этого использовать. Эта программа позволяет копировать файлы из одного компьютера на другой по протоколу SSH или своему собственному протоколу Rsync, но для последнего понадобиться чтобы на целевом компьютере был установлен сервер Rsync. Одно из преимуществ программы в том, что она позволяет не передавать через сеть всё содержимое файлов, а только те данные, которые изменились с последнего копирования. Это удобно для того чтобы не перегружать сеть лишними операциями. Никаких автоматизированных решений здесь нет, вам самим придётся настраивать что и куда копировать. Подробнее про Rsync читайте в этой статье.
2. AutoMysqlBackup
Если вам надо делать резервную копию базы данных MySQL, то для этого нельзя просто скопировать все файлы базы данных. Лучше скопировать нужные базы с помощью специального инструмента. К таким инструментам относится скрипт AutoMySQLBackup. С помощью него вы можете настроить регулярное резервное копирование вашей базы данных на другой сервер или в облако. Поддерживается ротация и удаление устаревших резервных копий.
3. Duplicity
4. Rdiff-backup
Ещё одна небольшая утилита для резервного копирования, похожая на rsync. Она написана на Python и позволяет делать резервные копии только изменённых файлов. Кроме того, можно хранить резервную копию на другом сервере. На удалённый сервер можно записывать данные по протоколу rsync или ssh.
5. Bacula
Это уже не просто скрипт, а полноценная система резервного копирования, которую надо размещать на нескольких серверах. Она состоит из нескольких компонентов, каждый из которых имеет своё предназначение. Программа имеет открытый исходный код и предназначена, в первую очередь, для предприятий. Кроме полных резервных копий, так же как и в Rsync поддерживаются инкрементные, когда копируются только изменённые данные.
6. Backupninja
7. Kbackup
Это небольшая графическая утилита для резервного копирования файлов разработанная для KDE. Позволяет выполнять как полные резервные копии так и архивировать только изменённые файлы. Копии хранятся только на том же компьютере, что и установлена программа, а автоматическое резервное копирование не поддерживается.
8. BackupPC
Это кроссплатформенная программа для резервного копирования, разработанная для больших предприятий. Для управлением резервным копированием используется веб-интерфейс. Можно делать как полные резервные копии, так и только для изменённых файлов. Можно запланировать автоматическое обновления или настроить уведомления о необходимости делать резервные копии.
9. Amanda
Amanda расшифровывается как Advanced Maryland Automatic Network Disk Archiver. Это тоже кроссплатфноменная программа для резервного копирования, созданная, в первую очередь, для предприятий. Она может располагаться на нескольких компьютерах, благодаря клиент-серверной архитектуре и сохранять резервные копии на другой сервер. Для создания резервных копий используются системные утилиты, в Linux это tar.
10. Back In Time
Это простая графическая утилита для настройки автоматического резервного копирования. Поддерживается как копирование на локальный компьютер, так и хранение копий удалённо. Вы можете выбрать папки, которые надо копировать и расположение, куда копировать.
11. Box Backup Tool
Ещё один инструмент корпоративного уровня. Его можно установить на несколько машин и выполнять резервное копирование между ними. Программой можно управлять только с помощью командной строки. Поддерживаются инкрементальные копии, а также шифрование данных.
12. Luckybackup
Это ещё одна оболочка над утилитой rsync, только на этот раз с графическим интерфейсом. Она позволяет планировать автоматическое резервное копирование, выполнять полные копии или только синхронизировать изменения с сервером. Интерфейс утилиты интуитивно понятный и достаточно удобен в использовании.
13. Timeshift
Раньше мы рассматривали программы, предназначенные для резервного копирования отдельных файлов и каталогов, однако существуют программы предназначенные для полного копирования всех файлов операционной системы. К ним относится Timeshift. Программа имеет как графический так и консольный интерфейс и позволяет создавать резервные копии системы с помощью rsync или btrfs. Подробнее об её возможностях читайте тут.
14. Clonezilla
В отличие от Timeshift программа Clonezilla поставляется на отдельном образе и запускается из BIOS. Она позволяет создать резервную копию как Linux так и Windows потому что копирует весь диск побайтово и потом позволяет всё это восстановить. Подробнее о том как пользоваться Clonezilla читайте в отдельной статье.
15. Systemback
Утилита Systemback чем-то похожа на Timeshift. Она тоже позволяет создавать точки восстановления операционной системы и потом с помощью них восстанавливать работу вашего дистрибутива. Кроме того, с помощью утилиты можно скопировать систему на другой диск или создать LiveCD образ для будущего восстановления.
Выводы
Всегда помните, что резервное копирование очень важно, оно помогает предотвратить потерю данных. Существует огромное количество программ резервного копирования Linux, которые помогут регулярно копировать ваши данные.
Вы можете выбрать один из выше рассмотренных инструментов, просто выберите что для вас подходит лучше. Если вы используете другую программу, не описанную здесь, напишите в комментариях!
Резервное копирование Linux сервера
Резервное копирование Linux сервера
Введение
Правильное создание и безопасное хранение бэкапов задача важная и необходимая. Можно относится халатно, но тогда в случае проблем можете обнаружить что резервных копий нет или они просто испорчены.
Из статьи вы узнаете как я подхожу к этому вопросу и защищаю бэкапы всех своих ресурсов надежно и безопасно в системах Linux.
В примере будет рассмотрен вариант для резервного копирования файлов и базы данных сайта, но можно этот подход использовать и для других задач.
Можно использовать для резервных копий разные программные комплексы или пользоваться средствами которые предоставляют хостинги, но для этого необходимо их изучать или производить финансовые затраты. Лично я предпочитаю использовать механизмы проверенные временем и хранить все бэкапы на своих ресурсах.
Основа безопасности бэкапов
Правильность и безопасность бэкапов включает в себя несколько простых правил:
Ниже я по порядку опишу все свои действия которые использую на практике. Будут использованы стандартные программы используемые во всех версиях Linux.
Создание бэкапов на сервере
Самое надежное это когда производится создание резервных копии на самом сервере, так как это гарантирует что вы не получите проблем возникших с удаленным подключением к сторонним ресурсам. Например, при использовании бэкапа на Yndex Disk у меня периодически были ошибки при создании бэкапа.
Структура папок для бэкапов
Создавать папки можно где угодно. Например, мне больше нравится создавать их в корне папку backup и держать там всё что связанно с резервными копиями.
Создадим необходимые папки куда будем класть бэкапы
В итоге мы получили следующие папки:
Backup и его периодичность
Всегда сложно выбрать какой необходим период хранения и интервал резервного копирования. Для меня удобней организовать резервное копирование по следующей схеме:
Подход к резервированию сугубо личное дело и зависит от множества факторов. Главное чтобы эти копии всегда были доступны, исправны и удовлетворяли вашим требованиям.
Создание скриптов для бэкапов
Создадим два скрипта для ежедневного и ежемесячного бэкапа.
Создадим скрипт который будем ежедневно запускать по расписанию:
Для ежемесячных бэкапов создадим такой скрипт:
Первая и последняя команда в обоих скриптах взаимоисключающие. При варианте когда мало места и есть возможность хранить только один бэкап первая команда должна выполняться а последняя нет. В случае достаточного места под бэкапы первую команду не выполняем а в последней выставляем количество дней за которые хранятся бэкапы.
После создания скриптов сделаем их исполнительными выполнив необходимую команду:
Добавление заданий в cron
Время в которое необходимо выполнять выбирайте на свое усмотрение. В большинстве случаев лучше использовать ночное время так как в это время сервера загружены минимально и можно использовать их ресурсы для выполнения своих внутренних задач.
Обязательно учитывайте время когда делается первый бэкап, так как дальнейшие копии сделанных бэкапов надо делать позже по времени для правильного мониторинга.
В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времини которое необходимо для создания бэкапа.
Открываем необходимый файл и добавляем нужный код:
Согласно команде каждый день в 1:20 бедет выполнятся скрипт для создания ежедневного бэкапа и ежемесячно первого числа в 1:25 будет создаваться ежемесячная резервная копия.
Перезагрузим cron в системе CentOS для применения изменений:
Проверка создания бэкапов
Убедится что все работает правильно можно только запустив скрипт у посмотреть результат его работы.
Мне больше нравится брать код непосредственно из файла crontab, так как это последнее место которое выявит ошибки связаные с правильностью написания пути к скрипту.
Из вывода видно какие файлы забекапились и что база данных тоже успешно зарезервиловалась.
Осталось дождаться времени выполнения и проверить как отрабатывает команду cron.
Посмотреть результат работы cron можно заглянув в файл:
Никогда не игнорируйте проверку резервных копий и обязательно настройте надежную систему мониторинга.
Создание копии backups используя rsync
В моем случае под всевозможные бэкапы используется специальный сервер настроенный только для бэкапов.
Подключается к серверу с которого надо забирать бэкапы будем по сертификату. Для копирования будем использовать утилиту rsync.
Именно на этом сервере производится мониторинг правильности создания бэкапов и их размеры средствами программы для мониторинга Zabbix.
Узнать как работать со свободным программным комплексом для мониторинга вы можете из раздела Мониторинг Zabbix.
Возможности Zabbix удовлетворят любые потребности для осуществления любых параметров практически любой системы.
Подключение по сертификату
Более подробно о том как настраивать механизм подключения по сертификаты можете найти в статье RSA или авторизация SSH по ключу.
Скопируем на подключаемый ресурс необходимую часть ключа:
После успешного выполнения пробуем подключиться:
В случае успеха идём дальше.
Для безопасности можно создать пользователя на ресурсе откуда забираете данные и ограничить его только в папке откуда забираем резервные копии.
Создание скрипта для выполнения rsync
Создадим необходимый скрипт:
Скрипт задокументирован и выберите параметры исходя из ваших требований.
Расшифрую параметры указанные в коде:
После создания скриптов сделаем их исполнительными выполнив необходимую команду:
Добавление задания в cron
Обязательно учитывайте время когда делается первый бэкап, так как дальнейшие копии сделанных бэкапов надо делать позже по времени для избежания путаницы и правильного мониторинга.
В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времени которое необходимо для создания бэкапа.
Открываем необходимый файл и добавляем нужный код:
Согласно команде каждый день в 6:30 бедет выполнятся скрипт который будет забирать резервные копии согласно вашим пожеланиям.
Дальнейшие проверки аналогичны действиям указаным в разделе выше.
В случае вывода ошибки при выполнении скрипта:
Смотрите правильность указания всех путей и параметров или выполните в консоли команду rsync —help и разбирайте в параметрах команды.
Использование Yndex.Disk для backups
При регистрации домена мне нравится переводить его управление на Yandex. Для бэкапов создаю отдельный почтовый ящик на домене и туда копирую бэкапы сайта. Удобно передовать заказчику управление доменом и резервные копии в одном месте.
Yandex.Disk дает возможность подключится с помощью WebDav. Необходимо добавить пакет davfs2 для работы по WebDav.
К сожалению на данный момент невозможно передавать данные большого размера по WebDav на Yandex.
Вы можете установить на систему консольный клиент от Yandex и проводить резервное копирование с помощью его.
Официальная страница руководства пользователя имеет понятное описание по установке и использованию на разных системах.
Более подробно с описанием сервиса Yandex Disk вы можете ознакомиться перейдя в раздел техподдержки Яндекса.
Установка Davfs2
Рассмотрим настройку на примере системы CentOS 7.
Подключим репозиторий Еpel:
Установим пакет davfs2:
Настройка WebDav для Yandex.Disk
Создадим папку куда будем монтировать:
Чтобы не путаться в конце я указываю логин почты на котором находиться диск.
Смонтируем Yandex.Disk в необходимую папку:
Диск смонтировался в указанную папку.
Отмантировать диск можно командой:
Введение вручную данных при монтировании не всегда удобно и для удобства мы автоматизируем этот процесс.
Отредактируем файл /etc/davfs2/secrets, добавив в конец строку с данными для авторизации:
Так мы можем задать любое количество строчек с необходимыми ресурсами Yandex.Disk.
В случае если вы хотите чтобы диск монтировался при перезагрузке системы то в etc/fstab необходимо добавить строчку:
Теперь при перезагрузке сервера диск автоматически монтируется.
Не советую использовать монитрование через fstab, так как в случае обрыва связи копии не будут копироваться.
Можно конечно настроить механизм который будет окнтролировать это подключение и поднимать его в случае обрыва, но мне это кажется ненужным усложнением.
Создание скрипта для работы с Yandex.Disk
Создалим скрипт для выполнения копирования резервных копий на Yandex.Disk:
Скрипт выполнит следующие действия:
Очищать кэш созданный при работе davfs2 надо обязательно иначе место на диске быстро закончиться.
После создания скриптов дадим необходимые права для всех файлов в папке backup:
Добавление задания в cron
Откроем для редактирования /etc/crontab файл откуда выполнятся задания:
Перезагрузим cron в системе CentOS 7 для применения изминений:
Проверки осуществляем по аналогии с предыдущими главами.
Заключение
Постарался описать максимально понятно все варианты которые я использую при создании резервных копий данных сайтов. В случае если вы найдете ошибки или знаете как можно улучшить данные примеры пожалуйста напишите в комментариях к статье.