Автор ХостМастерНа чтение 30 минПросмотров135Опубликовано
В предыдущих статьях мы уже говорили о том, как выполнять локальное и удаленное резервное копирование с помощью и как настроить . В этом уроке мы узнаем очень полезную технику, которую мы можем использовать для выполнения инкрементальный резервные копии и планируйте их, используя старый добрый cron .
В этом уроке вы узнаете :
Разница между жесткими и символическими ссылками
Что такое инкрементное резервное копирование
Как работает параметр rsync –link-dest
Как создавать инкрементные резервные копии с помощью rsync
Как запланировать резервное копирование с помощью cron
Как создавать инкрементные резервные копии с помощью rsync в Linux
Требования к программному обеспечению и используемые условные обозначения
Жесткие и символические ссылки
Прежде чем мы продолжим и узнаем, как создавать инкрементные резервные копии с помощью rsync, нам следует потратить некоторое время, чтобы четко понять разницу между символический и жесткий , ссылки, поскольку последние будут играть решающую роль в нашей реализации (вы можете пропустить эту часть, если вам это кажется очевидным).
В системах на основе Unix, таких как Linux, у нас есть два типа «ссылок»: жесткие и символические. В пер команда по умолчанию генерирует жесткие ссылки; если мы хотим создать символические ссылки, мы должны вызывать его с помощью -s вариант (сокращение от --символический ).
Чтобы понять, как жесткие_ссылки работы, мы должны сосредоточиться на концепции индекс . Inode — это структура данных в файловой системе, которая содержит различную информацию о файле или каталоге (который, согласно это просто «особый» тип файла), например, его разрешения и расположение блоков жесткого диска, содержащих фактические данные.
На этом этапе вы можете подумать, что имя файла также «хранится» в его индексном дескрипторе: это не так. То, что мы обычно называем «именами файлов», — это просто удобные для человека ссылки на inodes, установленные внутри каталогов.
Каталог может содержать более одной ссылки на один и тот же индексный дескриптор: эти ссылки мы называем жесткие_ссылки . Все файлы имеют (конечно) хотя бы одну жесткую ссылку.
Жесткие ссылки имеют два основных ограничения: они не работают. через файловые системы и нельзя использовать для каталогов .
Когда количество жестких ссылок для inode достигает 0 , сам индексный дескриптор удаляется, и поэтому указанные блоки на диске становятся доступными для рабочего системы (фактические данные не удаляются и иногда могут быть восстановлены, если они не были перезаписаны новым данные). Количество жестких ссылок, связанных с индексным дескриптором, указывается в выходных данных ls команда, когда она вызывается с -l вариант:
$ ls -l ~ / .bash_logout. -rw-r - r--. 1 egdoc egdoc 18 января 28 13:45 /home/egdoc/.bash_logout.
В выходных данных выше, сразу после обозначения разрешений, мы можем ясно видеть, что ~ / .bash_logout это единственная ссылка (единственная жесткая ссылка) на его конкретный индексный дескриптор. Давайте создадим еще одну жесткую ссылку и посмотрим, как изменится вывод команды:
Как и ожидалось, количество жестких ссылок было увеличено на одну единицу и теперь составляет 2 . Опять таки: ~ / .bash_logout и ~ / bash_logout это не два разных файла; это всего лишь две записи каталога, указывающие на один и тот же индексный дескриптор. Это легко продемонстрировать, запустив ls на этот раз с -я вариант (сокращение от --иноде ): это делает так, что индекс inode включается в вывод:
Как видите, упомянутые индекс является 131079 в обеих строках.
Символические ссылки разные. Они представляют собой более современную концепцию и преодолевают два ограничения жестких ссылок: они могут использоваться для каталогов и могут быть установлены для разных файловых систем. А символическая ссылка — это особый вид файла, который указывает на совершенно другой файл (его цель). Удаление символической ссылки не влияет на ее цель: удаление всех символических ссылок на файл не приводит к удалению исходного файла. С другой стороны, при удалении «целевого» файла символическая ссылка (-ы), указывающая на него, разрывается.
На этом этапе должно быть ясно, почему с точки зрения занимаемого места на диске создание жестких ссылок является более сложным. удобно: когда мы добавляем жесткую ссылку, мы создаем не новый файл, а новую ссылку на уже существующий.
Создание инкрементных резервных копий с помощью rsync
Прежде всего, что такое так называемый инкрементное резервное копирование ? В инкрементной резервной копии хранятся только те данные, которые были изменены с момента создания предыдущей резервной копии. В стратегии инкрементного резервного копирования только первая резервная копия серии является «полной»; последующие просто сохранят инкрементные различия. Это имеет то преимущество, что требует меньше места на диске и меньше времени для завершения по сравнению с полным резервным копированием.
Как мы можем использовать rsync создавать инкрементные резервные копии? Допустим, мы хотим создавать инкрементные резервные копии наших $ HOME каталог: сначала мы создадим его полную резервную копию и сохраним в каталоге, который назовем после текущей метки времени. Затем мы создадим ссылку на этот каталог и назовем его последний чтобы иметь легко узнаваемую ссылку.
Последующие резервные копии будут сделаны путем вычисления разницы между текущим состоянием $ HOME каталог и последняя существующая резервная копия. Каждый раз при создании новой резервной копии текущая последний ссылка, по-прежнему указывающая на предыдущую резервную копию, будет удалена; затем он будет воссоздан с новым каталогом резервных копий в качестве целевого. Ссылка всегда будет указывать на последнюю доступную резервную копию.
Даже если резервные копии инкрементные, заглянув внутрь каждого каталога, мы всегда увидим полный набор файлов, а не только тех, которые изменились: это потому, что неизмененные файлы будут представлены жесткими ссылками. Те, кто был изменен с момента последней резервной копии, будут единственными, кто займет новое место на диске.
Для реализации нашей стратегии резервного копирования мы будем использовать --link-dest вариант rsync . Эта опция принимает в качестве аргумента каталог. При вызове rsync мы укажем:
Исходный каталог
Каталог назначения
Каталог, который будет использоваться в качестве аргумента --link-dest вариант
Содержание источник будет сравниваться с каталогом, переданным в --link-dest вариант. Новые и измененные файлы, существующие в исходном каталоге, будут скопированы в каталог назначения как всегда (и файлы, удаленные в источнике, также не появятся в резервной копии, если --Удалить вариант); неизмененные файлы также появятся в каталоге резервных копий, но они будут просто жесткими ссылками, указывающими на inodes, созданные в ранее сделанных резервных копиях.
Реализация
Вот простой сценарий bash с реальной реализацией нашей стратегии:
#! / bin / bash # Сценарий для выполнения инкрементного резервного копирования с использованием rsync set -o errexit. set -o существительное. установить -o pipefail только для чтения SOURCE_DIR = "$ {HOME}" только для чтения BACKUP_DIR = "/ mnt / data / backups" readonly DATETIME = "$ (дата '+% Y-% m-% d_% H:% M:% S')" readonly BACKUP_PATH = "$ {BACKUP_DIR} / $ {DATETIME}" readonly LATEST_LINK = "$ {BACKUP_DIR} / latest" mkdir -p "$ {BACKUP_DIR}" rsync -av --delete \ "$ {SOURCE_DIR} /" \ --link-dest "$ {LATEST_LINK}" \ --exclude = ". Cache" \ "$ {BACKUP_PATH}" rm -rf "$ {LATEST_LINK}" ln -s "$ {BACKUP_PATH}" "$ {LATEST_LINK}"
Первым делом мы объявили некоторые переменные, доступные только для чтения: SOURCE_DIR который содержит абсолютный путь к каталогу, который мы хотим сделать резервную копию (в данном случае наш домашний каталог), BACKUP_DIR каталог, содержащий путь к каталогу, в котором будут храниться все резервные копии, ДАТА ВРЕМЯ в котором хранится текущая временная метка, BACKUP_PATH который является абсолютным путем к каталогу резервных копий, полученному «присоединением» BACKUP_DIR и нынешний ДАТА ВРЕМЯ . Наконец, мы устанавливаем LATEST_LINK переменная, которая содержит путь к символической ссылке, которая всегда будет указывать на последнюю резервную копию.
Затем мы запускаем rsync команда, обеспечивающая -а вариант (сокращение от --архив ), чтобы сохранить наиболее важные атрибуты исходных файлов, -v параметр, чтобы сделать команду более подробной (необязательно), и --Удалить возможность сделать так, чтобы файлы, удаленные из источника, также удалялись по назначению (мы объяснили этот и другие параметры rsync в .
Обратите внимание, что мы добавили косую черту в конце SOURCE_DIR в команде rsync: это обеспечивает синхронизацию только содержимого исходного каталога, а не самого каталога.
Запускаем команду с --link-dest вариант, передав LATEST_LINK каталог в качестве аргумента. В первый раз, когда мы запустим сценарий, этот каталог не будет существовать: это не вызовет ошибки, но приведет к выполнению полного резервного копирования, как и ожидалось.
Мы решили исключить .cache каталог из резервной копии с --исключать вариант, и, наконец, мы предоставили BACKUP_PATH чтобы указать rsync, где создать резервную копию.
После успешного выполнения команды ссылка, указывающая на предыдущую резервную копию, удаляется, и создается другая с тем же именем, указывающая на новую резервную копию.
Вот и все! Прежде чем использовать сценарий в реальном мире, нам лучше добавить в него некоторую обработку ошибок (например, мы могли бы удалить новый каталог резервных копий, если резервное копирование не было завершено успешно), и, поскольку rsync потенциально может работать в течение довольно длительного периода времени (по крайней мере, в первый раз, когда создается полная резервная копия), мы можем захотеть реализовать некоторую форму распространения сигнала от родительского скрипта к дочернему процессу (как это сделать, может быть хорошей темой для другого руководство).
Периодически запускайте скрипт с помощью cron
Этот скрипт не предназначен для запуска вручную: удобнее всего запланировать его выполнение, создав запись в нашем личном кабинете. crontab . Чтобы отредактировать наш crontab и добавить новый cron работа , все, что нам нужно сделать, это выполнить следующую команду:
$ crontab -e.
В crontab откроется в текстовом редакторе по умолчанию. В нем мы можем создать новый cron работа . Например, чтобы сценарий выполнялся каждые 12 часов, мы могли бы добавить эту запись:
0 * / 12 * * * /path/to/backup-script.sh.
Выводы
В этом уроке мы объяснили разницу между символический и жесткий ссылки в Linux, и мы узнали, почему это важно в контексте стратегии инкрементного резервного копирования, реализованной с помощью rsync. Мы увидели, как и почему мы используем rsync --link-dest вариант для выполнения нашей задачи, и мы создали простой сценарий bash, чтобы проиллюстрировать поток стратегии; наконец, мы увидели, как периодически запускать скрипт по расписанию с помощью cron.
LinuxConfig ищет технических писателей, специализирующихся на технологиях GNU / Linux и FLOSS. В ваших статьях будут представлены различные руководства по настройке GNU / Linux и технологии FLOSS, используемые в сочетании с операционной системой GNU / Linux.
Ожидается, что при написании статей вы сможете идти в ногу с технологическим прогрессом в вышеупомянутой технической области. Вы будете работать самостоятельно и сможете выпускать как минимум 2 технических статьи в месяц.
относительно недавно появилась интересная задача: делать бэкап только одной папки на сервере, которая мало того что занимала немногоим больше 70 гигабайт, так в ней ещё и было огромное количество мелких файлов. А данные для работы нужны, просто так пожертвовать ими нельзя. Вариант с архивированием отпадает практически сразу. На сервере с 16 Gb оперативки он сжимался 20 часов. Сразу стало очевидно, что дело пахнет инкрементальностью. То есть архивироваться/бекапиться должны не все данные, а только те, которые изменились с момента предыдущего добавочного резервирования. Хотел написать скрипт, да вот как подумал, что разворачивать контент придется ровно в противоположном порядке создания бэкапов, сразу и перехотел.
Недолгие поиски привели меня к тому, что мне нужно: rsync. Как понятно из названия мало того, что это синхронизация (sync) так ещё и удаленная (r). То есть можно стягивать данные с удаленных серверов. А это большой плюс к безопасности, так как утилита умеет использовать ssh.
Работает rsync по принципу клиент-сервер. Тут есть замечательный нюанс: в один момент клиент и сервер могут поменяться местами. Далее попробую объяснить подробнее.
Принцип работы rsync довольно прост. Есть сервер-ресурс (назовем условно SRC) и сервер-назначение (DST).
Как видим данные можно гонять в обе стороны.
rsync является самодостаточным (он устанавливает сразу и клиент и сервер) и работает на своем порту (по умолчанию 873).
Правильной будет следующая схема реализации создания резервных копий: на машине, куда будем сливать копии поднимаем rsync-сервер. На машине-источнике будет достаточно только клиента. На последней будем запускать rsync что бы он необходимые данные гнал на rsync-сервер. При необходимости просто меняем местами SRC и DST и данные синхронизируются в обратном порядке. Главное в этой ситуации смотреть за rsync-сервером. Что бы по закону Мерфи они одновременно не вышли из строя.
С теорией вроде всё ясно. Переходим к реализации. Для начала займемся конфигурацией rsync-сервера.
Поехали
cd /usr/ports/net/rsync/
make config
Я выбрал только SSH для возможности безопасной передачи данных. Пока что я не использую этот параметр, но все может случиться.
make && make install && make clean && rehash
Забегая наперёд хочу сказать, что это же нужно будет выполнить и втором сервере. rcync-клиент установиться, чего нам будет достаточно.
Пилим конфиги:
cd /usr/local/etc/
ls -la | grep rsync
-r--r--r-- 1 root wheel 477 May 29 10:29 rsyncd.conf
-r--r--r-- 1 root wheel 766 May 29 10:29 rsyncd.conf.sample
Правим rsyncd.conf до подобного состояния
# Set this if you want to stop rsync daemon with rc.d scripts
pid file = /var/run/rsyncd.pid
#Hello
motd file = /etc/new_motd
#Log
log file = /var/log/rsyncd.log
# Edit this file before running rsync daemon!!
uid = nobody
gid = nobody
use chroot = no
max connections = 4
#syslog facility = local5
# Название секции
[Backup] # Путь к дириктории path = /home/gleb/backup # Коментарий comment = Matter Corporate Backup (requires authentication) # Разрешаем запись read only = no # Разрешаем просмотр list = yes # Указываем пользователей, которым будет разрешено устанавливать соединение auth users = gleb, smart # Указываем путь к файлу с данными для аутентификации secrets file = /usr/local/etc/rsyncd.secret
Создаём необходимые файлы:
cat > /etc/new_motd
TradeNarK rsync server
ctrl+D
touch /var/log/rsyncd.log
chmod 0600 /var/log/rsyncd.log
chown root:wheel /var/log/rsyncd.log
cat > /usr/local/etc/rsyncd.secret
gleb:Password
smart:passworD
ctrl+D
chown root:wheel /usr/local/etc/rsyncd.secret
chmod 0600 /usr/local/etc/rsyncd.secret
echo rsyncd_enable=\"YES\" >> /etc/rc.conf
chmod 777 /home/gleb/backup # Для возможности записи в этот каталог
/usr/local/etc/rc.d/rsyncd start
Starting rsyncd.
ps aux | grep rsync
root 21810 0.0 0.1 9528 1288 ?? Ss 6:54PM 0:00.00 /usr/local/bin/rsync --daemon
root 21815 0.0 0.1 9748 1048 0 S+ 6:54PM 0:00.01 grep rsync
На rsync-клиенте пробуем залить все на новоиспеченный сервер:
rsync --update --recursive -v .ssh/ gleb@tradenark.com.ua::Backup
TradeNarK rsync server
Password:
sending incremental file list
authorized_keys
id_rsa
id_rsa.pub
known_hosts
sent 5156 bytes received 84 bytes 1497.14 bytes/sec
total size is 4883 speedup is 0.93
Ну вот и все. Наш сервер полностью рабочий и может служить хранилищем для удаленного инкрементального защищенного бекапа.
Ещё один момент. Так как у нас сервер не проходной двор и мы его запаролили, то логично что каждый раз при попытке синхронизации запрашивается пароль. Что бы избежать этого(к примеру для постановки задачи в cron) существует опция —password-file=FILE .
Создадим этот файл на клиенте и пропишем в нем ТОЛЬКО пароль для пользователя, под которым хотим производить синхронизацию. Ну и проверим:
rsync --update --recursive --password-file=rsync_password -v .ssh/ gleb@tradenark.com.ua::Backup
TradeNarK rsync server
sending incremental file list
sent 101 bytes received 8 bytes 218.00 bytes/sec
total size is 4883 speedup is 44.80
Есть, все прошло автоматически без запроса пароля
Типа готово. Можно ставить в крон и не париться за актуальность данных. Так же рекомендую изучить все доступные опции rsync-а. Их там на 3 странички A4
До новых записей
Rsync backups are versatile. You can can create full, differential and incremental backups of a directory. Rsync can backup files locally or remotely.
Local Backups
If you are backing up to another directory, removable storage, or a locally mounted network file system, then you will be creating local backups.
Создание локальных резервных копий
Чтобы создать локальную резервную копию, запустите rsync с соответствующими параметрами, исходным каталогом и целевым каталогом.
tyler@desktop:~/rsync$ rsync -avh stuff/ backup/
Косые черты в конце имеют значение. Если вы опустите косую черту после , будет создан каталог с именем stuff в . В примере это будет клон .
Обратите внимание на то, как копируется, когда косая черта отсутствует.
tyler@desktop:~/rsync$ rsync -ah stuff backup/
tyler@desktop:~/rsync$ ls backup/
stuff
Если косая черта включена, в резервную копию будут скопированы только файлы из stuff.
tyler@desktop:~/rsync$ rsync -ah stuff backup/
tyler@desktop:~/rsync$ ls backup/
filea fileb
Опция отображает размеры в удобочитаемом формате. т.е. он будет отображать размер передачи в КБ, МБ и т. д., а не в байтах.
Эта опция называется архивным режимом. Это ярлык для нескольких других опций. Он указывает rsync сохранять метки времени, разрешения , и некоторые другие вещи. Если вам интересно, справочная страница описывает все детали.
Наконец, включает подробный вывод. При включенном подробном выводе rsync будет отображать скорость передачи, список переданных файлов и размер передачи.
Восстановление из локальных резервных копий
Чтобы восстановить резервную копию, поменяйте местами источник и место назначения.
tyler@desktop:~/rsync$ rsync -ah backup/ stuff/
Удаление файлов
Иногда вам может понадобиться сделать резервную копию или восстановить точную копию ваших данных. Если вы хотите удалить файлы в месте назначения, которых нет в источнике, добавьте параметр. Например, у вас может быть приложение, которое создает временные файлы или файлы кэша.
Вот пример восстановления резервной копии с опцией.
tyler@desktop:~/rsync$ ls backup/
filea fileb
tyler@desktop:~/rsync$ rsync --delete -ah backup/ stuff/
tyler@desktop:~/rsync$ ls stuff/
filea fileb
Обновление резервной копии
Если вы хотите обновить резервную копию, просто снова запустите rsync с теми же аргументами. Rsync только скопирует изменения. Помните, что при этом будут удалены все лишние файлы, находящиеся в целевом каталоге, но не в исходном. Это эффективный способ сохранить точную копию каталога.
Удаленное резервное копирование
Существует два метода удаленного резервного копирования. Вы можете либо отправить резервную копию на удаленный хост, либо перетащить резервные копии с исходного хоста на резервный хост. Если вы планируете создавать инкрементные или дифференциальные резервные копии, вы должны использовать метод извлечения. Rsync может работать через rsh, ssh или собственный протокол. Я рекомендую ssh, потому что ваши данные будут зашифрованы во время их отправки по сети.
Я бы избегал push-бэкапов. Если машина, для которой выполняется резервное копирование, скомпрометирована, ваши резервные копии могут быть скомпрометированы.
указывает rsync использовать ssh в качестве удаленной оболочки. Rsync регистрируется на удаленном хосте, используя указанную оболочку, а затем передает данные через соединение с удаленной оболочкой.
В примере с извлечением rsync регистрируется как и копирует в каталог на локальном хосте.
Полные резервные копии
Существует несколько подходов к полному резервному копированию. Вы можете поддерживать один каталог резервных копий или каждый раз создавать новый каталог. Если вы просто пытаетесь поддерживать зеркальное отображение каталога, вам, вероятно, нужно первое. Если вы используете rsync для создания регулярных резервных копий с возможностью возврата к различным моментам времени, вам потребуется создавать новый каталог назначения при каждом запуске.
Дедупликация
Если вы планируете периодически создавать полные резервные копии, рассмотрите систему хранения со встроенной дедупликацией. Встроенная дедупликация позволит вам делать регулярные полные резервные копии без использования чрезмерного объема хранилища.
Существуют коммерческие продукты, предлагающие встроенную дедупликацию, а также ZFS . Если вы не хотите тратить много денег, ZFS изначально поддерживается на FreeBSD и FreeNAS . Существует также проект ZFS для Linux . если вы предпочитаете систему на базе Linux.
Инкрементальные и дифференциальные резервные копии
Для создания инкрементных и дифференциальных резервных копий используйте опцию . Указанный каталог сравнивается с исходным каталогом. Любые файлы в каталоге, которые идентичны или новее, чем файл в источнике, не скопировано в место назначения.
Инкрементальные и дифференциальные резервные копии не могут работать с файлами, которые были намеренно удалены после создания указанной полной резервной копии. Предположим, у вас есть каталог, который вы хотите регулярно создавать резервные копии. Вы создаете полную резервную копию. После создания полной резервной копии вы удаляете файл. Теперь вы создаете дифференциальную резервную копию. В восстановлении будет файл, который вы удалили между двумя резервными копиями.
Есть несколько подходов к решению проблемы удаленных файлов:
Вы можете согласиться с тем, что файлы, которые должны были быть удалены, будут в ваших резервных копиях и, следовательно, восстановлены.
Вручную сохраняйте список файлов, которые вы удалили между каждым резервным копированием.
Рассмотрите возможность использования только полных резервных копий.
Используйте программное обеспечение для резервного копирования, такое как Аманда вместо rsync.
Напишите сценарий, который сравнивает, какие файлы находятся в ваших резервных каталогах с исходным каталогом, и выводит список удаленных файлов.
Дифференциальные резервные копии
Чтобы создать дифференциальную резервную копию, используйте абсолютный путь к последней полной резервной копии в качестве значения параметра:
Если вы выполняете удаленное резервное копирование, вы должны используйте метод вытягивания. Опция не будет принимать удаленный каталог. Если извлечение невозможно, вы, вероятно, можете обойти это, смонтировав FUSE удаленный каталог с помощью sshfs. Я еще не писал об этом гайд, но nixCraft хорошо покрывает его.
Инкрементальные резервные копии
Поскольку для инкрементного резервного копирования требуется несколько параметров, необходимо использовать rsync версии 2.6.4 или новее.
Команда для проверки вашей версии:
tyler@desktop:~/rsync$ rsync --version
rsync version 3.1.2 protocol version 31
Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes, prealloc
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details./
Инкрементальные резервные копии создаются так же, как дифференциальные резервные копии, за исключением того, что используются несколько каталогов.
Даже при инкрементном резервном копировании многие инкременты требуют много места на диске. Кроме того, он просто не динамичен, поэтому не подходит в качестве надлежащего решения для резервного копирования. Мы создали новую итерацию, позволяющую вам установить несколько интервалов (например, ежечасно, ежедневно, еженедельно, ежемесячно, ежегодно) и установить количество приращений для каждого интервала.
Надеюсь, это будет последний резервный скрипт, который вам понадобится за долгое время. Во всяком случае, это единственный, которым я пользуюсь.
#!/bin/bash # Title: Perfacilis Incremental Back-up script # Description: Create back-ups of dirs and dbs by copying them to Perfacilis' back-up servers # We strongly recommend to put this in /etc/cron.hourly/backup # Author: Roy Arisse <support@perfacilis.com> # See: https://www.perfacilis.com/blog/systeembeheer/linux/rsync-daily-weekly-monthly-incremental-back-ups.html # Version: 0.12 # Usage: bash /etc/cron.hourly/backup
# ++++++++++ NO CHANGES REQUIRED BELOW THIS LINE ++++++++++
set -e export LC_ALL=C
rm -rf $EMPTYDIR }
OPTS="$OPTS --exclude-from=$EXCLUDE" fi
OPTS="$OPTS --password-file=$SECRET" fi
log "Back-up list of installed packages" dpkg --get-selections > $BACKUP_LOCAL_DIR/packagelist.txt }
INC=$(get_next_increment $PERIOD) log "Moving $PERIOD back-up to target: $INC"
log "Back-up initiated at `date`"
trap "cleanup" EXIT
check_only_instance prepare_local_dir
backup_packagelist backup_mysql backup_folders
log "Back-up completed at `date`" }
INCREMENTS переменная хранит количество приращений для сохранения за период. DURATIONS переменная хранит продолжительность — в секундах — период, эту переменную нужно изменить только в том случае, если вы хотите изменить продолжительность или добавить новые периоды.
В INCREMENTS , вы можете установить количество » 0 «, чтобы исключить инкремент. Для каждого добавляемого вами инкремента папка в целевом расположении резервного копирования создается автоматически.
Имейте в виду, что обе переменные являются ассоциативными массивами , убедитесь, что форматирование правильное. Если вам интересно, сообщение в блоге Энди Балама отличное объяснение. Если вам это не интересно, просто посмотрите на текущее форматирование и измените его по своему усмотрению.
Скопируйте содержимое всего скрипта в файл, который вы называете» backup «, храни это в» /etc/cron.hourly «:
Не забывайте, если вы создали почасовой или даже более короткий период, скрипт нужно вызывать чаще. Сохраните файл в другом месте и назовите его соответствующим образом из /etc/crontab (или любой другой способ, который вам нравится).
Мы уже несколько лет делаем резервные копии для других. Раньше мы использовали полных резервных копий , создавая простую копию всей исходной системы на каждый день недели. Это означало, что размер резервной копии в семь раз превышал размер исходной системы. Чтобы снизить затраты и повысить эффективность, мы перешли на добавочное резервное копирование.
В этой статье показано, как мы нашли решение для создания добавочных резервных копий через rsync в удаленное место. Если вам не интересно развлечение, просто скопируйте Финальный сценарий , измените его в соответствии с вашими потребностями и вперед.
Эта страница является только объяснением
На этой странице подробно объясняется, как можно сделать инкрементное резервное копирование с помощью rsync. Он основан на идее, которая была сильно изменена и улучшена.
Если вы не хотите изучать, как это работает, а просто хотите рабочий скрипт: Улучшенный сценарий инкрементного резервного копирования Rsync
Базовые полные резервные копии
Если у вас есть опыт работы с Rsync, вы, возможно, знаете, что скопировать важные файлы в резервную копию очень просто. Как показывает приведенный ниже простой пример, логика практически не меняется, если вы используете внешний диск, удаленный сервер, на котором работает rsyncd , или запустить rsync через ssh:
# Rsync на внешний диск rsync -av /home/$USER/Документы /mount/externaldisk/backup
Это настолько просто, насколько это возможно, и даже если оно выполняет свою работу, это далеко не надежное решение.
Резервное копирование нескольких папок
Используя волшебство скрипта bash, вы можете настроить массив для папок, для которых вы хотите создать резервную копию, и просмотреть их в цикле:
#!/bin/bash
Изменить BACKUP_DIRS массив в соответствии с вашими потребностями, просто разделите каждую папку пробелом, сохраните текст как backup.sh , и просто запустите его из командной строки: bash backup.sh и ваша резервная копия будет работать. При желании вы можете запустить исполняемый файл chmod +x backup.sh , это можно запустить без вызова bash: ./backup.sh .
Заметка о ясности кода Bash
Чтобы не загромождать сценарий, я буду разбивать логику на функции, хотя это приведет к большему количеству кода. Не забудьте последнюю строку, где main вызывается, иначе ничего не произойдет. Если ваш сценарий стал странным, используйте bash -x ./backup.sh для отладки. Также вы можете использовать man bash в качестве справочника по языку.
Автоматизация резервного копирования
После изменения приведенного выше примера в соответствии с вашими потребностями у вас будет очень простое резервное решение. Лично у меня нет дисциплины запускать его вручную каждый день, поэтому давайте автоматизируем его.
Запланируйте резервное копирование с помощью Crontab (если ваш компьютер/сервер всегда включен)
11*** user bash /home/user/backup.sh
При желании можете поместить свой резервный скрипт в /etc/cron.hourly , /etc/cron.daily , /etc/cron.weekly или /etc/cron.monthly папки вместо использования файлов crontab. Убедитесь, что файл сценария является исполняемым и не содержит специальных символов (используйте man run-parts для ограничений имени файла), например:
Запланируйте резервное копирование с интервалом (опционально, если ваш компьютер не всегда включен)
Использование планировщика Crontab, как описано выше, имеет один большой недостаток, потому что, если ваш компьютер выключен в запланированное время, ваше резервное копирование не запустится. Используя системный таймер вместо Crontabs, вы можете настроить его на запуск при пропуске расписания или даже при загрузке компьютера, но некоторые дистрибутивы Linux не имеют systemd или строго против systemd .
Добавив немного дополнительной логики в наш существующий сценарий резервного копирования, мы можем проверить, когда он выполнялся в последний раз. Например, для моего ноутбука я использую что-то вроде приведенного ниже примера с интервалом в 8 часов (интервал определяется в секундах: 3600 * 8 = 28800 ) или как только он пропустил расписание:
#!/bin/bash
prepare_local_dir создает локальный резервный каталог, если он не существует. check_interval проверяет, превышает ли время изменения папки заданный интервал. Наконец, я заканчиваю signoff_interval чтобы снова обновить время изменения папки резервного копирования, чтобы она была настроена для следующего выполнения.
Вам нужно изменить свой Crontab, чтобы скрипт резервного копирования запускался чаще, например, каждый час:
1 * * * * пользователь bash /home/user/backup.sh
check_interval метод гарантирует, что время между фактической rsync'ацией никогда не будет меньше заданного $INTERVAL .
Инкрементное резервное копирование с помощью rsync
Просматривая Примеры Rsync на странице ниже я нашел основу сценария инкрементного резервного копирования. Идея состоит в том, чтобы сохранить последнюю версию всех наших файлов в «текущем» каталоге и переместить старые файлы в отдельное возрастающее имя каталога. Опять нам придется добавить больше логики bash:
#!/bin/bash
$RSYNC $DIR/ $RSYNC_PROFILE/current/$TARGET готово
Прежде всего, prepare_current_dir гарантирует, что «текущий» каталог существует в цели rsync. Затем в backup_foldersget_next_increment вызывается, который возвращает число между 0 и $INCREMENTS . Для 0 , будет создана полная резервная копия данного $DIR , число больше 0 сохранит предыдущую версию в $INC папку и обновляет файлы в «текущем» каталоге, чтобы отразить последнюю версию.
Для локальных резервных копий (например, внешний жесткий диск) мы могли бы легко перечислить существующие приращения в целевом объекте, чтобы определить следующее приращение. Жаль, что мы не можем перечислить содержимое удаленных целей rsync, поэтому нам нужно отслеживать последнюю цель локально, что делается с «последним» файлом. signoff_increment Функция поддерживает этот файл в актуальном состоянии. Если сумма $INCREMENTS достигается, он воссоздает новую полную резервную копию в «текущую», таким образом вращая / сбрасывая все это. Этот метод безопасен для использования как с удаленными, так и с локальными целями.
Вы можете изменить количество приращений в любой момент времени. Увеличение количества создаст больше папок с числовым приращением. Однако уменьшение числа не приведет к удалению более высоких чисел, оно просто пропустит их.
Пропавшие миры
Пароль профиля Rsync
При использовании удаленного профиля rsync обычно требуется аутентификация. Вместо использования RSYNC_PASSWORD переменная, это безопаснее для установки файла паролей:
только для чтения RSYNC_SECRET='u53Y0ur0wnPa55w0rdPlz' только для чтения RSYNC_DEFAULTS="-trlqz4 --delete --delete-excluded --prune-empty-dirs"
Где мы использовали $RSYNC_DEFAULTS до сих пор нам нужно использовать $(get_rsync_opts) вместо. См. упрощенный пример выше или окончательный сценарий ниже. Кроме того, trap добавляется к main функция обеспечения rsync.exclude и rsync.secret удаляются, даже если скрипт убит.
Бэкап Mysql
Если вы используете Mysql, вы можете добавить этот простой backup_mysql функция для создания gzip-файлов вашей базы данных. Не забудьте позвонить в main хотя функция.
только для чтения MYSQL="mysql --defaults-file=/etc/mysql/debian.cnf" только для чтения MYSQLDUMP="mysqldump --defaults-file=/etc/mysql/debian.cnf --events --routines --max-allowed-packet=512MB --quick --quote-names --skip-comments"
Лесозаготовка
Обычно вы хотите, чтобы cronjobs хранил молчание, но вы также хотите иметь возможность искать, что на самом деле сделал или делает ваш резервный скрипт. Поэтому простой log можно добавить функцию для пересылки вывода в файлы журнала. Он будет выводиться только в том случае, если вы вручную запустите скрипт с активного терминала.
Можно найти в нашем блоге о нашем улучшенном сценарии резервного копирования Rsync , последнюю версию можно найти на GitHub .
Заключение
Несмотря на то, что полученный в результате сценарий немного более интригующий, чем другие существующие инструменты, в результате получается надежная инкрементная резервная копия, которую вы можете изменить по своему вкусу. Он способен передавать ваши резервные копии как на локальные, так и на удаленные цели, и вы можете изменять приращения в любое время.
По сравнению со старой ситуацией, когда нам требовалось в семь раз больше места, чем в исходной системе, теперь мы можем хранить один полный и от 20 до 28 приращений в том же пространстве, это почти месяц! Другими словами, улучшение существенное. Тем не менее, мы хотели бы улучшить сценарий, чтобы он поддерживал настройку количества ежедневных, еженедельных и ежемесячных резервных копий, чтобы обеспечить более длительный период хранения. В настоящее время мы изучаем возможности и сообщим об этом, как только найдем стабильное и проверенное решение.
Заметка о двуличности
Если вам так не нравится писать сценарии, Двойственность вероятно, хорошая замена для вас. Он поддерживает шифрование (что является большим преимуществом), отправку файлов по многим протоколам и может быть настроен в одной строке кода. Совсем не хотите писать сценарии? Попробуйте Дежа Дюп , этот графический интерфейс для Duplicity упрощает настройку резервного копирования.
Хотя я предпочитаю ручной сценарий. Его легко изменить, и я точно знаю, где найти какой файл, так как в результате получается простой плоский формат файла. Duplicity создает несколько архивов для каждого снимка, которые необходимо искать с помощью инструментов duplicity. Для меня это слишком хлопотно.
Резервная служба Perfacilis
Служба резервного копирования Perfacilis оповещает вас, когда резервное копирование не завершено в запланированные сроки или если одновременно изменяется много данных (что может указывать на вирус-шифровальщик). Вы платите только за то пространство, которое занимают ваши резервные копии.
Источники
Список изменений
2022-06-29
Удален полный скрипт и добавлена ссылка на наш последний пост в блоге или на GitHub.
22.06.2020
Добавлено --skip-comments вариант $MYSQLDUMP избавиться от Свалка завершена … комментарий. Это позволяет избежать удаленного сохранения дампа, если сами данные не изменились.
03.07.2020
Заменено ${INC/0/current} с ${INC/#0/current} , чтобы избежать замены чисел, оканчивающихся на «0».
Файл отключенного rsync исчез ошибки, используя пример от Бенуа Жакмон
