Автоматизируйте согласованное резервное копирование Nextcloud с помощью Restic и Cron.

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

В этом примере предполагается наличие сервера Debian или Ubuntu, прямой установки Nextcloud по адресу /var/www/nextcloud, отдельного каталога данных по адресу /srv/nextcloud-dataи базы данных MariaDB. Замените эти значения на ваши фактические пути и имя базы данных. Шаги были проверены на соответствие руководству администратора Nextcloud 35 и документации Restic 0.19.1 в октябре 2026 года.

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

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

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

В официальных инструкциях Nextcloud по резервному копированию описаны компоненты и параметры экспорта базы данных. Данная процедура использует MariaDB; для PostgreSQL, MySQL или SQLite используйте соответствующие команды дампа и восстановления в разделе базы данных соответствующего руководства .

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

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

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

sudo install -d -m 700 /root/.config/restic
sudo install -m 600 /dev/null /root/.config/restic/nextcloud-password
sudo install -m 600 /dev/null /root/.config/restic/nextcloud.env

Надежно сохраните выбранный пароль Restic в файле паролей. Укажите расположение репозитория и путь к файлу паролей в файле переменных окружения:

RESTIC_REPOSITORY=/mnt/backup/nextcloud
RESTIC_PASSWORD_FILE=/root/.config/restic/nextcloud-password

Для удаленного бэкэнда используйте указанный в документации URL-адрес репозитория и учетные данные этого бэкэнда, хранящиеся с ограниченными правами доступа. В руководстве по подготовке репозитория Restic описана настройка репозитория и поддерживаемая переменная среды password-file . Инициализируйте новый репозиторий один раз, а не при каждом запуске:

set -a
. /root/.config/restic/nextcloud.env
set +a
restic init

Учетные данные MariaDB также нуждаются в защите. Настройте файл параметров клиента, доступный для чтения root, например, /root/.my.cnfс именем пользователя базы данных, паролем и хостом, а затем установите для него права доступа 600. Приведенный ниже скрипт передает этот файл в mariadb-dump, поэтому пароль базы данных не будет отображаться в аргументах процесса.

Создайте скрипт резервного копирования, который вернет Nextcloud в рабочее состояние.

Сохраните следующее как /usr/local/sbin/nextcloud-restic-backup. Отрегулируйте NC_DATA_DIRи DB_NAMEв соответствии с config/config.php. Скрипт включает режим обслуживания, экспортирует MariaDB, создает резервную копию приложения, данных и временного дампа SQL, а затем отключает режим обслуживания, даже если последующая команда завершится с ошибкой.

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

NC_DIR=/var/www/nextcloud
NC_DATA_DIR=/srv/nextcloud-data
DB_NAME=nextcloud
RESTIC_ENV=/root/.config/restic/nextcloud.env
DB_CNF=/root/.my.cnf

set -a
source "$RESTIC_ENV"
set +a
exec 9>/run/lock/nextcloud-restic.lock
flock -n 9 || exit 0

mountpoint -q /mnt/backup || {
  echo "Backup target is not mounted" >&2
  exit 1
}

install -d -m 700 /var/backups/nextcloud
STAGE_DIR=$(mktemp -d /var/backups/nextcloud/db.XXXXXX)
maintenance_on=0

cleanup() {
  if [[ "$maintenance_on" -eq 1 ]]; then
    sudo -u www-data php "$NC_DIR/occ" maintenance:mode --off ||
      logger -t nextcloud-restic "Could not disable maintenance mode"
  fi
  rm -rf "$STAGE_DIR"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM

sudo -u www-data php "$NC_DIR/occ" maintenance:mode --on
maintenance_on=1

mariadb-dump --defaults-extra-file="$DB_CNF"   --single-transaction --default-character-set=utf8mb4 "$DB_NAME"   > "$STAGE_DIR/nextcloud.sql"
test -s "$STAGE_DIR/nextcloud.sql"

restic backup "$NC_DIR" "$NC_DATA_DIR" "$STAGE_DIR" --tag nextcloud

Настройте права доступа и владения таким образом, чтобы только root мог редактировать или запускать скрипт, а затем протестируйте его вручную во время планового технического обслуживания. Эта mountpointпроверка предотвращает скрытую отправку большого репозитория в локальную файловую систему сервера из-за отсутствия резервного диска. Если ваш репозиторий находится на удалённом устройстве, а не смонтирован локально, замените эту проверку надёжной проверкой для вашего бэкэнда.

Перед первым запуском проверьте пути. Если папка с данными уже находится внутри каталога /var/www/nextcloud, не следует считать, что указанный пример пути верен; используйте фактический каталог данных из конфигурации Nextcloud. Также убедитесь, что пользовательские приложения или темы, хранящиеся вне каталога приложения, явно включены.

Запустите cron и проверьте результат.

После успешного выполнения вручную добавьте запись в crontab с правами root sudo crontab -e. В этом примере задача запускается ежедневно в 2:30 утра с использованием полного пути к скрипту и записывается вывод для устранения неполадок:

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

Cron предоставляет ограниченные возможности, поэтому скрипт задает явное расписание PATHи загружает настройки Restic самостоятельно. Убедитесь, что cron включен в вашем дистрибутиве и что это время не совпадает с фоновым запуском задач Nextcloud или другой задачей обслуживания. В руководстве по crontab для Linux описан формат расписания и предоставляемые cron возможности.

/var/log/nextcloud-restic.logПодтвердите успешное завершение задачи, проверив ее выход и перечислив последние снимки состояния:

sudo bash -lc 'set -a; source /root/.config/restic/nextcloud.env; set +a; restic snapshots'
sudo bash -lc 'set -a; source /root/.config/restic/nextcloud.env; set +a; restic check'

В стандартной конфигурации Restic checkпроверяется структура репозитория. Полное чтение данных занимает больше времени и может потребовать значительной пропускной способности для удаленного репозитория; планируйте проверку restic check --read-dataпериодически или используйте ее для проверки отдельных частей в течение определенного времени. См. документацию--read-data-subset Restic по целостности репозитория .

Просмотр снимка не является проверкой восстановления. Восстановите недавний снимок в отдельную временную директорию с помощью команды `npm run snapshot` , затем убедитесь, что файлы приложения, директория данных и дамп SQL присутствуют. Не восстанавливайте поверх работающей установки в качестве проверки. Для фактического восстановления восстановите файлы и базу данных как единый набор; инструкции по восстановлениюrestic restore latest --target /tmp/nextcloud-restore-test Nextcloud охватывают вопросы воссоздания базы данных и синхронизации клиента.

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