1. Стратегия резервного копирования
2. Резервное копирование rsync
• Настройка сервера rsync
• Примеры использования rsync
3. Резервное копирование Duplicity
• Установка и общие команды
• Удаленное копирование
4. Копирование диска с помощью dd
5. Заключение

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

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

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

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

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

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

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

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

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

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

 

root@dedicated:~#  rsync [опции] [источник] [назначение]

 

Остановимся подробно на опциях, на наиболее часто используемых. Список не полный, при необходимости вы можете обратиться к 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 на использование только определенного софта:

 

root@dedicated:~# adduser rbak
root@dedicated:~# apt-get install visudo
root@dedicated:~# visudo

 

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

 

rbak ALL= NOPASSWD:/usr/bin/rsync

 

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

 

root@dedicated:~# groups rbak
rbak : rbak

 

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

 

root@dedicated:~# mkdir /home/rbak/backup
root@dedicated:~# chown rbak:rbak /home/rbak/backup/

 

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

 

root@dedicated:~# mcedit /etc/rsyncd.conf

pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsync.log
[share]
path = /home/rbak/backup/
hosts allow =  109.108.**.**
hosts deny = *
list = true
uid = rbak
gid = rbak
read only = false

 

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

 

root@dedicated:~# sudo systemctl start rsync
root@dedicated:~# sudo systemctl enable rsync

 

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

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

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

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

 

root@dedicated:~# rsync -avh --dry-run /etc/ /home/rbak/backup/

 

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

 

root@dedicated:~# rsync -av /etc/ /home/rbak/backup/

 

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

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

 

dmt@dmt:~$ rsync -avz /home/dmt/ACDC-1980-Back-In-Black/ root@178.20.156.173:/home/rbak/backup/

 

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

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

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

 

rsync -avz root@178.20.156.173:/путь/ /home/путь/

 

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

 

dmt@dmt:~$  rsync -avze "ssh -p 2292" root@178.20.156.173:/путь/ /home/путь/

 

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

 

rsync -avze ssh --include '*.conf' --exclude '*' 
root@178.20.156.173:/home/rbak/backup/home/dmt/

 

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

 

dmt@dmt:~$ rsync -avzhe ssh --remove-source-files /home/dmt/directory/
root@178.20.156.173:/home/rbak/backup/

 

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

 

dmt@dmt:~$  rsync -avzhe ssh --delete
/home/dmt/directory/root@178.20.156.173:/home/rbak/backup/

 

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

 

dmt@dmt:~$ rsync -avzhe ssh --max-size='200M' /home/dmt/directory/
root@178.20.156.173:/home/rbak/backup/

 

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

 

dmt@dmt:~$ rsync -avzhe ssh --bwlimit=500 /home/dmt/directory/
root@178.20.156.173:/home/rbak/backup/

 

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

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

 

auth users = viktor, viktoria
secrets file = /etc/rsyncd.pass

 

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

 

viktor:password01
viktoria:password02

 

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

 

root@dedicated:~# chown root:root /etc/rsyncd.pass && chmod 600 /etc/rsyncd.pass

 

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

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

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

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

Установка:

 

root@dedicated:~# apt-get install duplicity

 

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

 

root@dedicated:~# duplicity full --no-encryption --volsize=1024
--include=/var/www/wordpress --exclude=/** / file:///home/backups/

 

где:

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

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

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

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

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

 

root@dedicated:~# duplicity incremental --no-encryption --volsize=1024
--include=/var/www/wordpress --exclude=/** / file:///home/backups/

 

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

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

 

root@dedicated:~# duplicity collection-status --no-encryption file:///home/backups/

 

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

 

root@dedicated:~# duplicity verify --no-encryption file:///home/backups/ /var/www/wordpress/

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Tue Jul  7 17:59:23 2020
Verify complete: 4230 files compared, 0 differences found.

 

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

 

root@dedicated:~# duplicity --no-encryption restore file:///home/backups/ /tmp/restore/

 

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

 

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Tue Jul  7 17:59:23 2020

 

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

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

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

 

root@dedicated:~# duplicity --no-encryption --file-to-restore
var/www/wordpress/wp-content/plugins file:///home/backups/
/tmp/restore/var/www/wordpress/wp-content/plugins

 

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

 

root@dedicated:~# duplicity --no-encryption -t 3D --file-to-restore
var/www/wordpress/wp-content/plugins  file:///home/backups/
/tmp/restore/var/www/wordpress/wp-content/plugins

 

где:

-t — time

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

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

 

root@dedicated:~#  duplicity remove-older-than 30D  --force  file:///home/backups/

 

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

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

 

root@dedicated:~# apt-get install lftp

 

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

 

duplicity full --no-encryption --volsize=1024 --include=/var/www/ --exclude=/** /
ftp://cf900585:yq77q1Ad14hD@backup60.freehost.com.ua:21

 

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

Результат:

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

 

root@dedicated:~# mcedit /root/ftp-bkp.sh

 

Содержание скрипта:

 

#!/bin/bash

FTPPORT="21"
FTPUSER="cf900585"
FTPPASS="yq77q1Ad14hD"
FTPSERVER="backup60.freehost.com.ua"
DAYS_FULL=3
DAYS_STORE=14
 
#Every three days Full Backup
duplicity --full-if-older-than ${DAYS_FULL}D --no-encryption --volsize=1024 
--include=/var/www  --exclude=/** / ftp://$FTPUSER:$FTPPASS@$FTPSERVER:$FTPPORT
 
#Remove Dackup older 14 days
duplicity remove-older-than ${DAYS_STORE}D --force
ftp://$FTPUSER:$FTPPASS@$FTPSERVER:$FTPPORT

 

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

 

ftp://$FTPUSER:$FTPPASS@$FTPSERVER:$FTPPORT/$DESTFOLDER

 

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

 

root@dedicated:~# chmod +x ftp-bkp.sh 
root@dedicated:~# ./ftp-bkp.sh

 

Результат:

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

 

root@dedicated:~#  man duplicity

 

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

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

Синтаксис прост:

 

root@dedicated:~# dd if=/dev/vda2 of=/home/vda1.img

 

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

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

 

root@dedicated:~# dd if=/dev/vda2 of=/home/vda1.img bs=8M conv=sync,noerror status=progress

 

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

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

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

 

dd if=/dev/vda | ssh user@111.111.11.11 dd of=/home/user/vda.img

 

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

 

dd if=/dev/vda | gzip -9 - | ssh user@111.111.11.11 dd of=/home/user/vda.img

 

Восстановить архив:

 

ssh user@111.111.11.11 dd if=/home/user/vda.img.gz | gunzip - | dd of=/dev/vda bs=2M

 

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

 

dd if=/dev/zero of=/dev/vda

 

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

 

dd if=/dev/zero of=/dev/vda bs=1M count=20

 

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

 

fdisk -s /dev/sdb
976762584

 

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

 

dd if=/dev/zero of=/dev/sdb seek=976762564

 

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

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

 

root@dedicated:~#  man dd

 

Заключение

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

 

Дата: 10.07.2020 Автор: Виктор

Голосування 1 2 3 4 5