Автоматизируем резервное копирование в Fedora

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

Создаём копию домашнего каталога

Для создания резервных копий создано множество утилит с графическим интерфейсом, например Déjà Dup, однако в данной статье мы будем использовать исключительно базовые консольные утилиты и самописный скрипт.

Пример скрипта backup.sh, использующего утилиты tar и xz для создания и сжатия архива с сохранением прав доступа и политик SELinux, а также gpg2 для шифрования данной резервной копии:

#!/bin/sh
set -e

bdir="/home/$(whoami)"
bfile="$bdir/backups/$(whoami)_$(date +%F).tar.xz"
bkey="1854A51C39584755EAF29C68BF99FC6DD45AB90A"

echo -n "Creating backup $bfile..."
tar --one-file-system --selinux \
	--exclude="virtualbox" \
	--exclude="backups" \
	--exclude="downloads" \
	--exclude="incoming" \
	--exclude="rpmbuild" \
	--exclude=".cache" \
	--exclude=".nv" \
	--exclude=".Trash" \
	--exclude=".goldendict/dicts" \
	--exclude=".goldendict/index" \
	--exclude=".java" \
	--exclude=".thum*" \
	--exclude=".local/share/baloo" \
	--exclude=".local/share/Trash" \
	--exclude=".PyCharmCE*/system" \
	-cJpf $bfile -C $bdir . \
	2>/dev/null && echo " Done." || echo " ERROR!"

echo -n "Encrypting backup using public key..."
gpg2 --out "$bfile.asc" --recipient "$bkey" --encrypt "$bfile" && echo " Done." || echo " ERROR!"

echo -n "Removing unencrypted backup file..."
rm -f "$bfile" && echo " Done." || echo " ERROR!"

echo "Backup $bfile.asc was successfully created."

Теперь подробно рассмотрим наш пример. Базовые переменные:

• bdir — путь к домашнему каталогу пользователя. Автоматически вычисляется скриптом в зависимости от имени пользователя, от которого запущен скрипт;
• bfile — имя файла резервной копии. По умолчанию будет состоять из текущей даты в формате ГГГГ-ММ-ДД.tar.xz и сохранён в каталоге ~/backups;
• bkey — идентификатор открытого ключа GPG, которым будет зашифрована резервная копия. Необходимо заменить его на используемый нами ключ.

Также для утилиты tar прописаны каталоги, которые ни при каком условии не должны попасть в резервную копию. В нашем примере это различные кэши, Корзина графических DE, а также хранилища с всевозможными временными файлами. В случае необходимости этот список можно легко расширить, добавив новую строку —exclude. Допускается использование подстановок оболочки (как в варианте с PyCharmCE).

По окончании создания tar.xz архива, он будет автоматически зашифрован при помощи gpg2 указанным в bkey открытым ключом. Расшифровать такой файл сможет лишь владелец закрытой части ключевой пары.

При отсутствии ключевой пары GnuPG, создадим её:

gpg2 --gen-key

Для вывода списка всех доступных открытых ключей с их идентификаторами, выполним:

gpg2 --list-keys

Автоматизируем создание резервных копий

Как известно, если резервные копии не создаются в автоматическом режиме, то можно считать, что их вообще нет, поэтому настроим их создание по расписанию.

Для начала разместим наш скрипт backup.sh в каталоге ~/bin (если он отсутствует, создадим его) и обязательно установим флаг +x, разрешающий его выполнение:

chmod +x ~/bin/backup.sh

Каталог ~/bin в Fedora уже содержится в переменной среды $PATH для bash и остальных командных интерпретаторов, поэтому скрипт можно будет запускать по имени откуда угодно:

[user1@localhost ~]$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/user1/.local/bin:/home/user1/bin

Создадим каталог для пользовательских systemd-юнитов (при отсутствии):

mkdir -p ~/.config/systemd/user

Добавим юнит ~/.config/systemd/user/home-backup.service:

[Unit]
Description=Backup contents of user's home directory

[Service]
Type=oneshot
ExecStart=$HOME/bin/backup.sh

Добавим таймер ~/.config/systemd/user/home-backup.timer:

[Unit]
Description=Daily backup contents of user's home directory

[Timer]
OnCalendar=*-*-* 2:00:00
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Обновим конфигурацию systemd для текущего пользователя:

systemctl --user daemon-reload

Настроим автоматический запуск таймера согласно его установок:

systemctl --user enable home-backup.timer

Теперь скрипт ~/bin/backup.sh будет выполняться каждый день в 02:00 по местному времени.

Выгружаем резервные копии в облако

Так как наш скрипт сразу создаёт зашифрованные файлы с резервными копиями, мы можем их совершенно спокойно выгружать в любые облачные хранилища данных для удобства: Яндекс.Диск, Google Drive, Dropbox, Amazon Glasier или S3 и т.д. Это может спасти нас от безвозвратной потери данных в случае пожара, наводнения, кражи всего оборудования и т.п.

Перед началом загрузки наших бэкапов в облако следует внимательно прочитать его условия использования (Terms of Service или TOS) и проверить, нет ли у них запрета на загрузку зашифрованных контейнеров, ведь в таком случае они могут отключить учётную запись.

Для того, чтобы настроить сохранение в облако, просто добавим в конец нашего backup.sh:

echo -n "Moving encrypted file to cloud storage directory..."
mv "$bfile.asc" "~/dropbox/backups/$(basename $bfile).asc" && echo " Done." || echo " ERROR!"

Здесь ~/dropbox/backups — локальный каталог хранения данных, который автоматически синхронизируется с облачным хранилищем его официальным клиентом.

Ни в коем случае не следует сразу изменять значение переменной bfile на каталог облачного хранилища, т.к. в таком случае в облако попадёт и незашифрованный tar.xz архив, что очень небезопасно, на наш взгляд.

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

Для начала необходимо расшифровать контейнер при помощи gpg2:

gpg2 --out "~/backups/user1_2017-09-03.tar.xz" --decrypt "~/backups/user1_2017-09-03.tar.xz.asc"

Теперь распакуем архив в корневой каталог, т.к. он уже содержит внутри всю вложенную структуру:

tar -xf "~/backups/user1_2017-09-03.tar.xz" -C ~

На этом восстановление завершено.

Заключение

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

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