ownCloud 서버의 자동 데이터베이스 백업 설정 방법

백업 계획의 취약점은 최악의 순간에 발견될 수 있습니다. 업그레이드가 실패하거나, 데이터베이스 테이블이 손상되거나, 서버가 사라지는 등의 상황이 발생할 수 있는데, 유일한 "백업"은 사용자 파일 복사본뿐이라면 문제가 됩니다. ownCloud Server의 경우, 이는 충분하지 않습니다. 데이터베이스에는 사용자, 공유 폴더, 파일 메타데이터, 구성 데이터와 같은 중요한 애플리케이션 상태 정보가 저장되어 있기 때문입니다. 안정적인 복구 계획을 위해서는 데이터베이스뿐만 아니라 동일한 시점의 파일과 구성 데이터도 필요합니다.

이 가이드는 Linux 환경에서 ownCloud 데이터베이스 백업을 자동화하는 실용적인 방법을 보여줍니다. 수동 덤프부터 시작하여 예약된 검증된 백업 작업까지 다룹니다. 예제는 ownCloud에서 권장하는 MySQL/MariaDB 엔진을 중심으로 설명하지만, PostgreSQL을 사용한 예시도 포함되어 있습니다. 명령어는 현재 ownCloud Server 11.0 관리 문서에 맞춰 작성되었으며, Docker를 사용하지 않는 기존 설치 환경에서의 명령어 차이점도 명시되어 있습니다.

먼저 데이터베이스 백업이 포함하지 않는 부분을 이해해야 합니다.

데이터베이스 덤프는 ownCloud 백업의 일부일 뿐입니다. ownCloud Server 11.0 백업 설명서에는 데이터베이스 외에도 구성 디렉터리, 데이터 디렉터리, 해당되는 경우 앱 디렉터리 및 사용자 지정 테마 파일이 포함되어 있다고 명시되어 있습니다. 데이터 디렉터리에는 암호화 키가 포함될 수도 있으므로 데이터베이스만 백업하는 방식으로는 전체 스토리지 손실 후 서버를 완전히 복구할 수 없습니다.

데이터베이스 보호를 위해 아래 자동화 기능을 사용하되, ownCloud 설치의 나머지 부분에 대해서는 파일 수준 백업 또는 스냅샷 전략을 함께 활용하십시오. 완벽하게 일관된 복구 지점이 필요한 경우, 데이터베이스 덤프와 파일 백업을 동일한 유지 관리 기간에 수행하도록 조정하십시오.

1단계: ownCloud에서 사용하는 데이터베이스를 확인합니다.

백업 명령을 작성하기 전에 데이터베이스 유형, 호스트, 데이터베이스 이름 및 사용자를 확인하십시오. 기존 ownCloud 설치에서는 이러한 값이 일반적으로 에 있습니다 config/config.php. ownCloud 명령줄 도구를 사용하여 시스템 구성을 확인할 수도 있습니다. 예를 들어 ownCloud 디렉터리에서 다음과 같이 할 수 있습니다.

sudo -u www-data ./occ config:list system

Docker Compose 배포에서 현재 문서는 다음과 같은 명령어를 사용합니다.

docker compose exec owncloud occ config:list system

dbtype, dbhost, dbname, 및 와 같은 값을 찾아보세요 dbuser. ownCloud Server 11.0은 MySQL/MariaDB 및 PostgreSQL을 공식적으로 지원하며, 일반적인 배포에는 MySQL 또는 MariaDB를 권장합니다.

2단계: 보호된 백업 위치 생성

웹에서 접근할 수 없는 전용 디렉터리를 생성하세요. 예약된 작업이 루트 사용자의 crontab에서 실행되는 경우 루트 소유권이 기본값으로 설정되는 것이 적절합니다.

sudo mkdir -p /var/backups/owncloud-db
sudo chown root:root /var/backups/owncloud-db
sudo chmod 700 /var/backups/owncloud-db

사용 가능한 공간을 확인하려면 다음 명령어를 사용하십시오 df -h /var/backups/owncloud-db. 시스템 디스크를 조용히 가득 채우는 백업 작업은 첫 번째 장애를 방지하려다 오히려 두 번째 장애를 일으킬 수 있습니다.

3단계: cron 명령에 데이터베이스 자격 증명을 포함하지 마십시오.

crontab 라인에 데이터베이스 암호를 직접 입력하지 마십시오. MySQL 또는 MariaDB의 경우, 루트 사용자가 읽을 수 있는 클라이언트 옵션 파일을 사용하는 것이 간단하며 무인 작업에서 잘 작동합니다. 생성 /etc/owncloud/db-backup.cnf:

[client]
user=ownclouduser
password=REPLACE_WITH_DATABASE_PASSWORD
host=localhost

그런 다음 제한하세요:

sudo chown root:root /etc/owncloud/db-backup.cnf
sudo chmod 600 /etc/owncloud/db-backup.cnf

ownCloud 구성에서 실제 값을 사용하십시오. 데이터베이스가 원격인 경우 적절한 호스트를 설정하십시오. MySQL 설명서에는 클라이언트 프로그램용 옵션 파일에 대한 내용이 나와 있으며, 이 방법을 사용하면 예약된 명령에서 암호를 직접 노출하지 않아도 됩니다.

4단계: 유지 관리 모드에서 수동 백업을 한 번 실행합니다.

ownCloud의 공식 백업 절차에 따르면 데이터베이스를 백업하기 전에 일반적인 접근을 차단하고 인스턴스를 유지 관리 모드로 전환해야 합니다. Docker Compose 배포의 경우 다음과 같습니다.

docker compose exec owncloud occ maintenance:mode --on

ownCloud 디렉토리에서 기존 방식으로 설치하는 경우:

sudo -u www-data ./occ maintenance:mode --on

유지보수 모드는 복구 지점을 생성하는 동안 일반 사용자 활동을 차단합니다. 따라서 자동화된 작업은 트래픽이 적은 시간대에 실행되어야 하며, 덤프가 실패하더라도 항상 유지보수 모드를 해제해야 합니다.

MySQL 또는 MariaDB의 경우 수동 덤프를 테스트하십시오.

sudo mysqldump   --defaults-extra-file=/etc/owncloud/db-backup.cnf   --single-transaction   --quick   owncloud   | gzip -c > /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).sql.gz

ownCloud 문서에서는 `mysqldump`를 사용합니다 mysqldump --single-transaction. MySQL 자체의 `mysqldump` 참조 문서 에 따르면, `mysqldump`는 --single-transactionInnoDB와 같은 트랜잭션 테이블에 대해 덤프하는 동안 테이블 잠금을 유지하지 않고 일관된 스냅샷을 생성합니다. 이 --quick옵션은 대용량 테이블을 메모리에 버퍼링하는 대신 행을 스트리밍 방식으로 전송합니다.

수동 백업이 완료되면 다음 명령어를 사용하여 유지 관리 모드를 해제하십시오.

docker compose exec owncloud occ maintenance:mode --off

또는:

sudo -u www-data ./occ maintenance:mode --off

5단계: 백업 로직을 오류 방지 스크립트에 넣으세요.

스크립트는 오류 발생 시 중지되고, 타임스탬프를 기록하고, 유지 관리 모드를 활성화하고, 덤프를 생성하고, 압축 파일을 검증하고, 보존 기간을 적용하고, 종료 시 유지 관리 모드가 비활성화되도록 보장해야 합니다. 다음 예는 일반적인 설치 환경과 /var/www/owncloudMySQL/MariaDB 데이터베이스(이름은 다음과 같음)를 가정합니다 owncloud.

#!/bin/bash
set -Eeuo pipefail

OC_ROOT="/var/www/owncloud"
BACKUP_DIR="/var/backups/owncloud-db"
DB_NAME="owncloud"
MYSQL_CNF="/etc/owncloud/db-backup.cnf"
STAMP="$(date +%Y%m%d-%H%M%S)"
OUT="$BACKUP_DIR/owncloud-db-$STAMP.sql.gz"

cleanup() {
  cd "$OC_ROOT"
  sudo -u www-data ./occ maintenance:mode --off || true
}
trap cleanup EXIT

mkdir -p "$BACKUP_DIR"
cd "$OC_ROOT"
sudo -u www-data ./occ maintenance:mode --on

mysqldump   --defaults-extra-file="$MYSQL_CNF"   --single-transaction   --quick   "$DB_NAME" | gzip -c > "$OUT"

test -s "$OUT"
gzip -t "$OUT"

find "$BACKUP_DIR"   -type f   -name 'owncloud-db-*.sql.gz'   -mtime +14   -delete

해당 파일을 저장하고 /usr/local/sbin/owncloud-db-backup.sh, 실행 권한을 부여한 chmod 700다음 수동으로 실행하세요. ownCloud가 컨테이너화된 경우, 위의 두 occ줄을 배포 환경에 맞는 Docker Compose 유지 관리 모드 명령으로 바꾸세요.

6단계: cron을 사용하여 일정을 예약합니다.

수동 실행이 성공하면 스크립트를 예약 실행합니다. 루트 사용자의 crontab을 엽니다.

sudo crontab -e

매일 새벽 2시 15분에 달리기를 하려면:

15 2 * * * /usr/local/sbin/owncloud-db-backup.sh >> /var/log/owncloud-db-backup.log 2>&1

실제 사용 패턴에 맞는 시간을 선택하세요. 데이터베이스 규모가 큰 경우, 유지 관리 모드는 서비스 중단을 유발하므로 수동 실행에 소요되는 시간을 먼저 측정해 보세요. 또한 cron이 예측 가능한 환경을 갖추도록 하세요. 필요한 명령이 cron의 기본 경로에 없는 경우 스크립트에서 절대 경로를 사용하세요 PATH.

7단계: 타임스탬프를 신뢰하는 대신 모든 백업을 검증하십시오.

오늘 날짜가 적힌 파일이라고 해서 백업 복구가 가능하다는 증거는 아닙니다. 최소한 파일이 비어 있지 않은지, gzip 압축 해제 시 손상이 없는지, 작업 로그에 덤프 오류가 없는지 확인하십시오.

ls -lh /var/backups/owncloud-db/
gzip -t /var/backups/owncloud-db/owncloud-db-YYYYMMDD-HHMMSS.sql.gz
tail -n 100 /var/log/owncloud-db-backup.log

보다 강력한 테스트를 위해, 최근 덤프 파일을 비운영 시스템의 임시 데이터베이스에 복원하십시오. 운영 중인 데이터베이스를 덮어쓰는 방식으로 복원 테스트를 진행하지 마십시오. 실제 복원 훈련에서는 파일 무결성뿐만 아니라 자격 증명, 데이터베이스 권한, 덤프 호환성, 그리고 팀에서 실제로 사용할 복구 절차까지 확인합니다.

8단계: ownCloud가 정상 작동으로 복귀했는지 확인합니다.

스크립트 실행이 완료되면 유지보수 모드가 해제되고 사용자는 정상적으로 로그인할 수 있습니다. 웹 인터페이스를 확인하고 백업 로그를 검토하십시오. 견고한 자동화란 단순히 덤프를 생성하는 것뿐만 아니라, 안전하게 실패 처리되고 서비스가 유지보수 모드에 갇히지 않도록 하는 것을 의미합니다.

PostgreSQL을 사용하면 어떤 점이 달라지나요?

ownCloud의 백업 문서에서는 pg_dumpPostgreSQL용 아카이브 형식을 사용합니다. PostgreSQL의 공식 pg_dump 문서에 따르면 pg_dump데이터베이스가 사용 중인 경우에도 일관된 내보내기를 생성합니다. 더 자세한 PostgreSQL 백업 및 복원 장 에서는 논리적 덤프를 파일 시스템 백업 및 연속 아카이빙과 구분합니다.

ownCloud 관련 간단한 명령어는 다음과 같습니다.

PGPASSWORD="REPLACE_WITH_PASSWORD" pg_dump owncloud   -h localhost   -U ownclouduser   -F tar   -f /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).tar

PGPASSWORD자동화를 위해서는 스크립트에 직접 암호를 포함시키는 것보다 PostgreSQL에서 지원하는 암호 파일 메커니즘을 사용하는 것이 좋습니다 . 유지 관리 모드, 보존 기간, 로깅 및 복원 테스트 원칙은 동일하게 유지하십시오.

백업 파일은 몇 개나 보관해야 할까요?

모든 ownCloud 서버에 적합한 단일 데이터 보존 기간은 없습니다. 데이터 보존 기간은 데이터 변경 속도, 사용 가능한 저장 용량, 복구 필요 시점 등을 고려하여 설정해야 합니다. 소규모 서버의 경우 하루 14회 데이터베이스 덤프가 적절한 예시이지만, 모든 서버에 요구되는 사항은 아닙니다.

최종 자가 점검

자동 데이터베이스 백업은 다음 조건이 모두 충족될 때만 준비됩니다.

• 서버가 MySQL/MariaDB를 사용하는지 PostgreSQL을 사용하는지 알고 있으며, 올바른 데이터베이스 이름과 호스트를 확인했습니다.
• 백업 디렉터리는 보호되어 있으며 충분한 여유 공간이 있습니다.
• crontab 명령에서는 자격 증명이 노출되지 않습니다.
• 예약 백업이 활성화되기 전에 수동 백업이 성공적으로 완료되었습니다.
• 스크립트는 덤프 실패 후를 포함하여 항상 유지 관리 모드를 종료합니다.
• 예약된 작업은 로그를 기록하고 비어 있지 않은 백업 파일을 정해진 시간에 생성합니다.
• 오래된 폐기물은 의도적인 보존 정책에 따라 제거됩니다.
• 최근 백업 파일이 비운영 데이터베이스에 성공적으로 복원되었습니다.
• 데이터베이스 백업은 ownCloud 데이터, 구성 및 기타 필수 디렉터리의 백업과 함께 수행됩니다.

이러한 검사 중 하나라도 실패하면 자동화에 의존하기 전에 해당 부분을 수정해야 합니다. 백업 시스템은 복구 경로가 테스트된 후에야 비로소 유용합니다.