Автоматизируем резервное копирование в 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 --exclude="$bdir/virtualbox" \
--exclude="$bdir/backups" \
--exclude="$bdir/downloads" \
--exclude="$bdir/incoming" \
--exclude="$bdir/rpmbuild" \
--exclude="$bdir/.cache" \
--exclude="$bdir/.nv" \
--exclude="$bdir/.Trash" \
--exclude="$bdir/.goldendict/index" \
--exclude="$bdir/.java" \
--exclude="$bdir/.thumb" \
--exclude="$bdir/.thumbnails" \
--exclude="$bdir/.local/share/baloo" \
--exclude="$bdir/.PyCharmCE*/system" \
-cJpf $bfile $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

Откроем редактор заданий crontab от пользователя, домашний каталог которого будет резервироваться:

crontab -e

Внесём изменения, добавив строку вида:

0 2 * * * ~/bin/backup.sh

В этом примере ~/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 /

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

Заключение

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

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

Пока нет комментариев.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *