Как создать резервную копию Nextcloud с помощью Restic и Cron

Иллюстративный сценарий (гипотетический): Джордан администрирует небольшой сервер Nextcloud на Ubuntu. Файлы приложения находятся в папке /var/www/nextcloud, файлы пользователей — в папке /srv/nextcloud-data, база данных Nextcloud хранится в MariaDB, а удаленный сервер Linux доступен по SSH. Джордану нужна ежедневная резервная копия, которую можно проверить и восстановить, а не просто запись cron, которая выполняется без ошибок.

Этот пример демонстрирует Джордану воспроизводимый рабочий процесс Restic и cron. Пути, учетные записи служб, имена баз данных и расписание приведены в качестве примеров; замените их значениями из вашей установки. Приведенные команды не подразумевают, что эта настройка была запущена или протестирована на реальном сервере.

Что должна содержать пригодная для использования резервная копия Nextcloud

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

Джордан решает создать резервную копию всего каталога приложения, включая конфигурацию, приложения и темы, а также отдельный каталог данных и дамп базы данных. Отдельная копия каждого внешнего хранилища также необходима, если Nextcloud хранит пользовательский контент вне сети /srv/nextcloud-data. Restic может защитить только те пути, которые может прочитать процесс резервного копирования.

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

1. Подготовьте Restic и его учетные данные.

Установите Restic из надежного источника пакетов и убедитесь, что он доступен для учетной записи, которая будет запускать задание. В примере предполагается, что задание запускается от имени root, чтобы иметь возможность читать файлы Nextcloud и дамп базы данных. Используется удаленное SFTP-хранилище, поэтому сбой сервера приложений Jordan не приведет к удалению единственной резервной копии.

restic version

install -d -m 700 /root/.config/restic
install -d -m 700 /root/.config/nextcloud

Создайте надежный пароль для репозитория Restic и сохраните его /root/.config/restic/nextcloud-passwordс правами только для root. Храните резервную копию этого пароля в защищенном месте, отдельно от сервера и репозитория. Restic шифрует данные репозитория, но потеря пароля может сделать зашифрованные резервные копии непригодными для использования. Не указывайте пароль непосредственно в скрипте или строке cron.

Настройте неинтерактивный SSH-доступ для учетной записи резервного копирования на удаленном хосте и проверьте ее ключ хоста через доверенный канал. Укажите ниже путь к репозиторию в каталог, в который учетная запись может записывать данные:

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'
restic init

Инициализируйте репозиторий только один раз. В руководстве по подготовке репозитория Restic описаны поддерживаемые системы хранения данных и инициализация. Файл с паролями и SSH-ключ следует рассматривать как конфиденциальные учетные данные и ограничить к ним доступ.

2. Поддерживайте совместимость базы данных и файлов.

Nextcloud рекомендует использовать режим обслуживания для резервного копирования, поскольку он блокирует новые входы в систему и блокирует существующие сессии, чтобы предотвратить несоответствие данных. Команда должна выполняться от имени пользователя HTTP; в типичной конфигурации пакетов Ubuntu этим пользователем является www-data. Окно обслуживания Джордана длится до завершения дампа базы данных и резервного копирования Restic, поэтому пользователи не могут работать в Nextcloud в это время.

В руководстве Nextcloud для MariaDB используется следующий подход mariadb-dump --single-transaction: храните учетные данные базы данных в защищенном файле настроек клиента, например /root/.config/nextcloud/mariadb.cnf, `.`, вместо того, чтобы встраивать пароль в команду:

[client]
user=nextcloud_backup
password=REPLACE_WITH_A_SECRET
host=localhost

Ограничьте доступ к файлу с помощью параметра chmod 600 /root/.config/nextcloud/mariadb.cnf`.`. Создайте учетную запись базы данных с правами, необходимыми только для вашего сервера, и выполните процедуру дампа. Если ваш Nextcloud использует PostgreSQL или SQLite, замените их описанным в документации методом резервного копирования; не запускайте команду MariaDB без изменений.

3. Создайте защищенный скрипт резервного копирования.

Джордан сохраняет следующий файл /usr/local/sbin/nextcloud-restic-backupи делает его исполняемым. Он использует блокировку, чтобы избежать наложения запусков, включает режим обслуживания перед созданием дампа, создает резервную копию дампа вместе с каталогами приложения и данных и пытается отключить режим обслуживания, даже если последующая команда завершится неудачей.

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

export RESTIC_REPOSITORY='sftp:backup@vault.example.net:/srv/restic/nextcloud'
export RESTIC_PASSWORD_FILE='/root/.config/restic/nextcloud-password'

NC_DIR='/var/www/nextcloud'
DATA_DIR='/srv/nextcloud-data'
DB_NAME='nextcloud'
DB_CNF='/root/.config/nextcloud/mariadb.cnf'
DUMP_DIR='/var/backups/nextcloud'
LOCK_FILE='/run/lock/nextcloud-restic-backup.lock'
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
DUMP_FILE="$DUMP_DIR/nextcloud-$STAMP.sql"
maintenance_started=0

mkdir -p "$DUMP_DIR"
exec 9>"$LOCK_FILE"
flock -n 9 || { echo 'A Nextcloud backup is already running.' >&2; exit 1; }

finish() {
  result=$?
  trap - EXIT
  if [[ "$maintenance_started" == 1 ]]; then
    sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --off || result=1
  fi
  rm -f -- "$DUMP_FILE" || result=1
  exit "$result"
}
trap finish EXIT

sudo -u www-data -- php "$NC_DIR/occ" maintenance:mode --on
maintenance_started=1
mariadb-dump --defaults-extra-file="$DB_CNF" --single-transaction \
  --default-character-set=utf8mb4 --databases "$DB_NAME" > "$DUMP_FILE"
restic backup --tag nextcloud "$NC_DIR" "$DATA_DIR" "$DUMP_FILE"

После проверки путей создайте исполняемый файл с правами root и режимом доступа 700. Скрипт предполагает, что установка использует www-dataMariaDB и указанные пути; config/config.phpсначала проверьте их на соответствие конфигурации вашего веб-сервера. Он также предполагает, что ни один другой администратор еще не включил режим обслуживания. Если команда, дамп или загрузка Restic завершаются с ошибкой, оболочка завершает работу с ошибкой, и ловушка пытается восстановить службу; проверьте журналы, чтобы подтвердить это. Дамп сохраняется с ограниченными правами доступа и удаляется после выполнения.

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

4. Запланируйте выполнение задания с помощью cron.

После успешного завершения ручного запуска Джордан устанавливает скрипт и планирует его запуск на период затишья. От имени root отредактируйте crontab sudo crontab -eи добавьте:

15 2 * * * /usr/local/sbin/nextcloud-restic-backup >> /var/log/nextcloud-restic.log 2>&1

Этот пример начинается в 2:15 утра в соответствии с часовым поясом cron сервера; выберите время, когда окно технического обслуживания приемлемо. Cron имеет меньшую среду, чем интерактивная оболочка, поэтому скрипт PATHявно задает и использует абсолютные пути. Создайте файл журнала с ограниченными правами доступа и настройте ротацию журналов или отправьте вывод в обычную службу логирования вашей системы. Планирование Cron только запускает задачу: оно не подтверждает завершение резервного копирования или работоспособность восстановления.

5. Установите срок хранения и проверьте результат.

После успешного резервного копирования Джордан проверяет, появился ли снимок:

restic snapshots --tag nextcloud
restic check

restic checkПроверяет структуру репозитория. Периодическая проверка restic check --read-dataтакже считывает сохраненные данные и может занимать значительное время сети и диска, поэтому планируйте ее в соответствии с размером репозитория и потребностями в восстановлении. В руководстве Restic по хранению моментальных снимков объясняется, что удаление моментальных снимков и удаление неиспользуемых данных — это отдельные операции, и что удаление блокирует репозиторий. Начните с пробного запуска и политики, соответствующей вашим требованиям к хранению:

restic forget --tag nextcloud --keep-daily 7 --keep-weekly 5 \
  --keep-monthly 12 --dry-run

Просмотрите снимки, которые предлагается удалить. Если вас всё устраивает, удалите --dry-runи добавьте новые --prune; запустите удаление, когда это не будет конфликтовать с ночным резервным копированием. Эти значения времени хранения являются примером, а не универсальной политикой. Учитывайте допустимый срок хранения, доступное хранилище и то, как далеко назад вам может потребоваться восстановить данные.

Наиболее показательный тест — это восстановление. Восстановите недавний снимок во временную директорию на отдельной системе, а не поверх действующих путей Nextcloud Джордана:

restic restore latest --tag nextcloud --target /tmp/nextcloud-restore-check

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

Как определить, когда этот подход нуждается в изменении?

Задание cron, предложенное Джорданом, подходит только в том случае, если окно обслуживания совпадает с продолжительностью резервного копирования, и все необходимые пути к данным находятся локально и доступны для чтения. Измените дизайн при появлении любого из следующих признаков:

• Сайт находится в режиме технического обслуживания дольше, чем могут выдержать пользователи: следует запланировать скоординированные снимки состояния или использовать другой метод, совместимый с конкретным приложением.
• В логах отображаются отсутствующие пути, ошибки доступа, неудачный дамп базы данных или ненулевой код завершения Restic: исправьте эти ошибки, прежде чем считать снимок завершенным.
• Данные хранятся на внешнем накопителе или на другом сервере: включите в план восстановления согласованную резервную копию этого хранилища.
• При тестовом восстановлении отсутствуют файлы, конфигурация, состояние базы данных или необходимый код приложения/темы: обновите входные данные резервной копии и повторите процедуру.
• Пароль Restic или учетные данные SSH существуют только на сервере, резервное копирование которого выполняется: храните учетные данные для восстановления отдельно и убедитесь, что авторизованный администратор имеет к ним доступ.

Для Джордана успех очевиден: в журнале cron отображается завершенный запуск, restic snapshotsуказывается недавний помеченный снимок, проверки репозитория не выявляют ошибок, а процедура восстановления возвращает целостный экземпляр Nextcloud. Запланированная команда — это начало процедуры резервного копирования; только полный, восстанавливаемый набор данных базы данных, конфигурации, приложений и пользователей обеспечивает практический путь восстановления.

Официальные ссылки

• Руководство администратора Nextcloud 35: Резервное копирование
• Руководство администратора Nextcloud 35: Восстановление резервной копии
• Документация Restic 0.19.1