Бэкап всего сервера linux

Организация 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:

# zpool create backup -m /mnt/backup /dev/md1 

По имени устройства /dev/md1 можно заметить, что я использую линуксовый software raid. Да, я знаю, что у ZFS есть свой способ создавать зеркала. Но поскольку на этой машине уже есть одно зеркало (для корневого раздела) и оно сделано штатным mdadm, то и для второго зеркала я предпочту использовать его же.

Включил дедубликацию и компрессию, сделал видимым каталог со снапшотами:

# zfs set dedup=on backup # zfs set compression=on backup # zfs set snapdir=visible backup 

Положил в /usr/local/bin скрипт для создания снапшотов:

#!/bin/bash export LANG=C ZPOOL='backup' # Храним все снапшоты 7 дней # снапшот на четвертое число каждого месяца храним год NOWDATE=`date +20%g-%m-%d` # дата формата ГГГГ-ММ-ДД OLDDAY=`date -d -7days +%e` if [ $OLDDAY -eq '4' ] then OLDDATE=`date -d -1year-7days +20%g-%m-%d` # получаем дату -1 год и на7 дней else OLDDATE=`date -d -7days +20%g-%m-%d` # получаем дату -7 дней fi /sbin/zfs snapshot $ZPOOL@$NOWDATE /sbin/zfs destroy $ZPOOL@$OLDDATE 2>/dev/null 

Этот скрипт добавил в 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 такого содержания:

uid = nobody gid = nogroup use chroot = yes max connections = 10 pid file = /var/run/rsyncd.pid [kvm01] path = /mnt/backup/kvm01 comment = KVM01 backups hosts allow = 192.168.xxx.xxx hosts deny = * read only = no [kvm02] path = /mnt/backup/kvm02 comment = KVM02 backups hosts allow = 192.168.xxx.yyy hosts deny = * read only = no 

192.168.xxx.xxx и 192.168.xxx.yyy – это адреса тех серверов, которые будут бекапиться. Зовут их kvm01 и kvm02. Их файлы будут лежать в /mnt/backup/kvm01 и /mnt/backup/kvm02. Поэтому:

# mkdir /mnt/backup/kvm01 # mkdir /mnt/backup/kvm02 # chown nobody:nogroup /mnt/backup/kvm01 # chown nobody:nogroup /mnt/backup/kvm02 

3. Rsync на клиентах

Минимально необходимый скрипт для копирования файлов с клиента kvm02 на сервер с адресом 192.168.xxx.zzz будет выглядеть примерно так:

#!/bin/bash RSYNCBACKUPDIR="rsync://192.168.xxx.zzz/kvm02" LOCALDIR="/virt/files" rsync -vrlptD --delete $LOCALDIR $RSYNCBACKUPDIR 

Разумется, если речь идет о бекапе виртуальных машин, то этот скрипт стоит пополнить командами создания и удаления 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 с компрессией и дедубликацией занимают места меньше, чем один бекап занимал бы на файловой системе без этих полезных свойств.

# zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 1.80T 310G 1.49T 16% 10.37x ONLINE - 

# zfs list NAME USED AVAIL REFER MOUNTPOINT backup 3.06T 1.42T 318G /mnt/backup 

Поскольку сам rsync не занимается шифрованием передаваемых данных, высовывать такую схему без изменений в интернет небезопасно. Добавить шифрование можно, пустив трафик через ipsec или stunnel, например.

Выше я написал, что заметных проблем с ZFS у меня не было. На самом деле, одна проблема была. Однажды ночью, когда оба клиента активно бекапились, сервер дважды сообщил в dmesg, что task rsync blocked for more than 120 seconds. При этом оба бекапа успешно завершились, ничего не зависло, данные не потерялись. Подозреваю, что это проявление знаменитого бага 12309. Разнес бекапы по времени, с тех пор проблема не повторялась.

Источник

Резервное копирование на Linux — Бэкап Linux сервера | Boodet.online

Пошаговая инструкция созданию бэкапа и восстановлению для ОС Linux. Бэкап всей системы, бэкап сервера и резервное копирование по расписанию.

08 Июл 2020 07:02 IT GIRL 12

Резервное копирование на Linux — Бэкап Linux сервера | Boodet.online Блог 2020-07-08 ru Резервное копирование на Linux — Бэкап Linux сервера | Boodet.online

286 104

286 104

Бэкап Linux-серверов

Резервное копирование и восстановление в Linux выполняют с помощью специальных команд: tar, cpio ufsdump, dump и restore. Их хватит для бэкапа и восстановления небольших объемов данных. Чтобы сохранить и поднять сервер большой компании, потребуются гибкие готовые решения, например, Symantec NetBackup, EMC NetWorker или Amanda. В этот статье мы не будем рассматривать готовые решения — каждое из них имеет свои особенности. Мы расскажем простыми словами, как запланировать резервное копирование, создать бэкап вручную и какие команды для восстановления использовать.

Что это и зачем нужно?

Чтобы сделать резервную копию сервера на Linux, мы будем использовать командную строку и программу rsync. Есть и более современные программы с красивым и более понятным интерфейсом, но алгоритмы rsync стабильные, надежные, допускают использование кода. А еще она использует минимальное количество трафика (может вычислить разницу между файлами в исходном и целевом каталоге и передавать только различия между двумя версиями файла).
Бэкап Linux нужно делать всегда. Не существует ни одной ситуации, когда можно сказать, что резервное копирование не нужно. Потеря любых данных — это плохо. Кроме того, с помощью бэкапа можно сохранить не только документы, но и настройки, состояние сервера на Linux. В любой момент всю систему целиком можно будет быстро восстановить.

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

В этой статье специалисты Boodet.Online расскажут, как создавать резервные копии сервера Linux на внешний диск, удаленный компьютер и по SSH-соединению.

Бэкап на жесткий диск

Если вы не используете облако или протоколы безопасности требуют хранения бэкапов Linux на внешнем диске, скопируйте сервер на жесткий диск: SSD — если хотите, чтобы восстановление было быстрее, или HDD — для большей надежности.
Первый шаг — узнать путь к диску. Откройте браузер файлов (например, Nautilus) в GNOME и найдите имя диска на боковой панели. Наведите указатель мыши на имя внешнего диска — путь будет виден во всплывающей подсказке (например, /media/boodet/NEWHDD). Теперь скопируйте содержимое из исходного каталога. В командной строке нажмите r — это запустит процесс копирования всех вложенных подкаталогов сервера Linux и их содержимого:
rsync -r / server / boodet / Documents / / media / boodet / NEWHDD / После завершения процесса вы вернетесь в командную строку. Проверьте, появились ли каталоги на внешнем диске.
Чтобы скопировать данные с сервера Linux в определенный каталог на целевом жестком диске, добавьте имя каталога к целевому пути. Например, вы хотите скопировать содержимое «/ server / boodet / Documents» в каталог «резервные копии» на внешнем диске. Для этого нужно ввести команду: rsync -r / server / boodet / Documents / / media / boodet / NEWHDD / backups / Чтобы сохранить настройки файлов и разрешений, используйте параметр a (архив). С его помощью можно сохранить атрибуты файлов — даты модификации, права собственности на файлы, права доступа. Это пригодится, если вы планируете восстанавливать состояние сервера Linux из резервной копии целиком: rsync -ra / server / boodet / Documents / / media / boodet / NEWHDD / backups / Чтобы rsync перечислял файлы по мере их копирования, используйте параметр v: rsync -rav / server / boodet / Documents / / media / boodet / NEWHDD / backups / Если вы хотите видеть прогресс в ходе копирования каждого файла, используйте параметр p: rsync -raP / server / boodet / Documents / / media / boodet / NEWHDD / backups / Бэкап сервера Linux на внешний диск обычно происходит медленно. Чтобы ускорить процесс, можно использовать параметр z. Файлы будут сжиматься при передаче, но в целевом каталоге будут храниться в изначальном виде: rsync -ravz / server / boodet / Documents / / media / boodet / NEWHDD / backups /

Бэкап Linux-сервера на NAS

Данные можно сохранять не только на внешний диск, но и в облако или на сетевое устройство хранения данных (NAS). Чтобы использовать сетевое расположение в качестве места копирования бэкапа Linux, укажите путь к облачному хранилищу или NAS в командной строке. Команды будут такими же, как и для внешнего жесткого диска.

Бэкап по SSH

Rsync поддерживает резервное копирование через SSH-соединение. Понадобится указать имя учетной записи пользователя и расположение SSH в командной строке. Здесь нужно использовать сетевое имя, но можно и IP-адрес. Обратите внимание на знак «:» между деталями SSH-соединения и началом сетевого пути на удаленной цепи: rsync -ravz / server / boodet / Documents / boodet@online.local: / server / boodet / Backups /

Источник