Restic과 Cron을 사용하여 Nextcloud를 백업하는 방법

예시 시나리오(가상): 조던은 우분투에서 소규모 Nextcloud 서버를 관리합니다. 애플리케이션 파일은 `/etc/nextcloud.js`에 있고 /var/www/nextcloud, 사용자 파일은 `/etc/nextcloud.js`에 있으며 /srv/nextcloud-data, MariaDB에 Nextcloud 데이터베이스가 저장되어 있고, SSH를 통해 원격 Linux 호스트에 접속할 수 있습니다. 조던은 단순히 오류 없이 실행되는 cron 항목이 아니라, 검사 및 복원이 가능한 야간 백업을 원합니다.

이 예제는 Jordan에게 반복 가능한 Restic 및 cron 워크플로를 제공합니다. 경로, 서비스 계정, 데이터베이스 이름 및 일정은 예시이며, 실제 설치 환경에 맞게 값을 변경해야 합니다. 여기에 제시된 명령어는 실제 서버에서 실행되거나 테스트되었다는 것을 의미하지 않습니다.

제대로 작동하는 Nextcloud 백업에는 무엇이 포함되어야 할까요?

폴더만 복사하는 경우 Nextcloud가 파일, 사용자, 공유 및 설정을 다시 연결하는 데 필요한 정보가 누락될 수 있습니다. 최신 Nextcloud 35 관리 설명서에는 구성 디렉터리, 사용자 지정 앱(있는 경우), 데이터 디렉터리, 테마 디렉터리 및 데이터베이스 등 보존해야 할 다섯 가지 항목이 나열되어 있습니다. 복원 가이드에서는 데이터베이스, 데이터 디렉터리 및 구성 파일이 필수적이라고 명시하고 있습니다. 예제를 적용하기 전에 설치된 Nextcloud 버전에 맞는 설명서를 참조하십시오.

조던은 구성, 앱, 테마를 포함한 전체 애플리케이션 디렉터리와 별도의 데이터 디렉터리, 그리고 데이터베이스 덤프를 백업하기로 했습니다. Nextcloud가 사용자 콘텐츠를 외부 저장소에 저장하는 경우, 각 외부 저장소 위치의 별도 복사본도 필요합니다 /srv/nextcloud-data. Restic은 백업 프로세스가 읽을 수 있는 경로만 보호할 수 있습니다.

Nextcloud의 공식 백업 지침에는 유지 관리 모드 및 데이터베이스 백업에 대한 내용이 설명되어 있습니다. 복원 지침 에서는 데이터베이스와 파일 트리를 호환 가능한 복구 지점에서 복원해야 하는 이유를 설명합니다.

1. Restic 및 그 자격 증명을 준비하십시오.

신뢰할 수 있는 패키지 소스에서 Restic을 설치하고 작업을 실행할 계정에서 Restic을 사용할 수 있는지 확인하십시오. 이 예제는 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. 해당 암호의 안전한 복구용 사본을 서버 및 저장소와는 별도의 장소에 보관하십시오. 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 패키지 설정에서 해당 사용자는 `http://`입니다 www-data. Jordan의 유지 관리 기간은 데이터베이스 덤프 및 Restic 백업이 완료될 때까지 지속되므로 사용자는 해당 시간 동안 Nextcloud에서 작업할 수 없습니다.

MariaDB의 경우 Nextcloud 설명서에서는 다음과 같이 사용합니다 . 명령에 암호를 직접 입력하는 대신, 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를 사용하는 경우, 해당 SQLite의 공식 백업 방법을 사용하십시오. MariaDB 명령어를 변경하지 않고 실행하지 마십시오.

3. 보호된 백업 스크립트를 생성합니다.

Jordan은 다음 내용을 저장 /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"

경로를 검토한 후 루트 소유권과 모드로 실행 파일을 생성하십시오 700. 이 스크립트는 설치 시 www-dataMariaDB 및 나열된 경로를 사용한다고 가정합니다. config/config.php웹 서버 구성과 비교하여 이러한 경로를 먼저 확인하십시오. 또한 다른 관리자가 이미 유지 관리 모드를 활성화하지 않았다고 가정합니다. 명령 실행, 덤프 생성 또는 Restic 업로드가 실패하면 셸이 오류와 함께 종료되고 트랩이 서비스 복구를 시도합니다. 로그를 확인하여 복구가 완료되었는지 확인하십시오. 덤프 파일은 제한적인 권한으로 저장되며 실행 후 삭제됩니다.

이 간단한 패턴은 Restic 스캔 및 업로드 전체 과정 동안 사이트를 사용할 수 없게 만듭니다. 데이터 디렉터리가 큰 경우 이 시간이 너무 길어질 수 있습니다. 파일 시스템이나 스토리지 플랫폼에서 지원하는 경우, 데이터베이스 덤프와 스토리지 스냅샷을 통합하거나 애플리케이션 일관성을 유지하는 다른 백업 방식을 사용하십시오. 데이터베이스 및 파일 스냅샷이 호환되는 시점을 나타내는지 확인하십시오. 활성 데이터베이스와 변경되는 데이터 디렉터리를 별도로 복사하면 복원하기 어려운 백업이 생성될 수 있습니다.

4. cron을 사용하여 작업을 예약합니다.

수동 실행이 성공적으로 완료되면 Jordan은 스크립트를 설치하고 작업이 적은 시간대에 실행되도록 예약합니다. 루트 권한으로 루트 crontab을 편집하고 sudo crontab -e다음 내용을 추가하세요.

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

이 예제는 서버의 cron 시간대에 따라 오전 2시 15분에 시작합니다. 유지 관리 기간에 적합한 시간을 선택하십시오. cron은 대화형 셸보다 환경이 작으므로 스크립트는 PATH명시적으로 절대 경로를 설정합니다. 로그 파일은 제한적인 권한으로 생성하고 로그 순환을 구성하거나 시스템의 일반 로깅 서비스로 출력을 전송하십시오. cron 예약은 작업 시작만 할 뿐 백업 완료 또는 복원 성공 여부를 확인하지는 않습니다.

5. 보존 기간을 설정하고 결과를 확인합니다.

백업이 성공적으로 완료되면 조던은 스냅샷이 생성되었는지 확인합니다.

restic snapshots --tag nextcloud
restic check

restic check저장소 구조를 확인합니다. 주기적인 작업은 restic check --read-data저장된 데이터를 읽고 상당한 네트워크 및 디스크 시간을 사용할 수 있으므로 저장소 크기와 복구 요구 사항에 따라 일정을 조정해야 합니다. Restic의 스냅샷 보존 가이드에 따르면 스냅샷 삭제와 참조되지 않는 데이터 정리 작업은 별개이며, 정리 작업은 저장소를 잠급니다. 보존 요구 사항에 맞는 정책을 설정하고 사전 테스트(dry run)를 먼저 실행해 보세요.

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의 복원 설명서에는 스냅샷 및 복원 대상 선택에 대한 내용이 나와 있습니다.

이러한 접근 방식을 바꿔야 할 시점을 어떻게 알 수 있을까요?

Jordan의 cron 작업은 유지 관리 기간이 백업 기간과 일치하고 필요한 모든 데이터 경로가 로컬에 있고 읽기 가능한 경우에만 적합합니다. 다음과 같은 징후가 나타나면 설계를 변경하십시오.

사이트가 사용자가 견딜 수 있는 시간보다 더 오랫동안 유지보수 모드에 머물러 있습니다. 체계적인 스냅샷 생성 또는 애플리케이션과 일관된 다른 방법을 계획하십시오.
로그에 경로 누락, 권한 오류, 데이터베이스 덤프 실패 또는 0이 아닌 Restic 종료 코드가 표시될 수 있습니다. 스냅샷을 완료된 것으로 간주하기 전에 이러한 문제를 해결하십시오.
데이터가 외부 저장 장치 또는 다른 서버에 저장되어 있는 경우, 복구 계획에 해당 저장 장치의 일관성 있는 백업을 포함하십시오.
테스트 복원에 파일, 구성, 데이터베이스 상태 또는 필요한 앱/테마 코드가 누락된 경우 백업 입력값을 업데이트하고 복원 과정을 다시 수행하십시오.
Restic 암호 또는 SSH 자격 증명은 백업 대상 서버에만 존재합니다. 복구 자격 증명은 별도로 저장하고 권한 있는 관리자가 해당 자격 증명에 접근할 수 있는지 확인하십시오.

조던에게 있어 성공은 눈으로 확인할 수 있는 것입니다. cron 로그에는 실행 완료 기록이 남고, restic snapshots최근에 태그된 스냅샷 목록이 표시되며, 저장소 검사에서 오류가 보고되지 않고, 복원 시뮬레이션을 통해 안정적인 Nextcloud 인스턴스가 복구되는 것이 그 예입니다. 예약된 명령은 백업 루틴의 시작일 뿐이며, 완전하고 복원 가능한 데이터베이스, 구성, 애플리케이션 및 사용자 데이터 세트만이 실질적인 복구 경로를 제공합니다.