백업 및 복구

선택한 콘텐츠 데이터의 오프라인 사본이 필요할 때 JSON 백업을 사용합니다. EmDash는 해당 파일을 가져올 수 없습니다. 복구 계획에는 원시 데이터베이스 백업 또는 특정 시점 복구와 미디어 바이너리의 별도 사본이 필요합니다.

백업에 포함되는 내용

JSON 백업에는 다음이 포함됩니다:

• 초안, 예약 게시물, 삭제된 항목을 포함한 모든 콘텐츠 항목
• 콘텐츠 모델을 구성하는 컬렉션 및 필드 정의
• 택소노미 정의, 용어, 각 항목에 할당된 용어
• 메뉴 및 메뉴 항목, 섹션, 위젯 영역 및 위젯, SEO 기록, 리비전 이력, 미디어 메타데이터, 데이터베이스 마이그레이션 이력
• 제목, 태그라인, URL, 로케일, 로고, 표시 설정, 소셜 프로필, SEO 기본값 등 사이트 설정. 이들은 site:, emdash:site_, emdash:locale 설정 그룹에서 가져옵니다.

다음을 포함한 다른 모든 데이터베이스 테이블은 제외됩니다:

• 사용자 계정, 세션, 패스키, OAuth 데이터, API 토큰 및 기타 인증 데이터
• 플러그인 스토리지 및 플러그인 설정(플러그인 시크릿 포함)
• 댓글과 반응, 리디렉트와 404 로그, 저자 표시, 콘텐츠 관계 및 참조, 감사 로그, 속도 제한, 예약 작업 상태
• 미디어 폴더, 미디어 사용 위치 기록, 불완전하거나 진행 중인 업로드, 미디어 파일 자체
• 미리보기 서명 시크릿과 백업 일정을 포함한 기타 사이트 옵션

백업은 EmDash의 미리보기 시스템에서 사용하는 것과 동일한 스냅샷 형식의 JSON 파일이며, 이를 생성한 EmDash 릴리스로 버전이 지정됩니다.

원클릭 다운로드

관리자의 Settings → Backups에서 Download backup 버튼이 새 백업을 생성하고 JSON 파일로 다운로드합니다. 관리자 역할이 필요합니다.

다운로드는 검사 또는 커스텀 마이그레이션 도구용입니다. 대량 가져오기, 스키마 변경 또는 주요 업그레이드 전에 아래 옵션 중 하나를 사용하여 복원 가능한 데이터베이스 백업을 만드세요.

스토리지로 자동 백업

사이트에 스토리지 백엔드가 설정된 경우(Cloudflare의 R2, S3 또는 로컬 스토리지), 매일 자동 백업을 활성화할 수 있습니다:

아카이브는 버킷의 backups/ 접두사 아래에 emdash-backup-<timestamp>-<random>.json으로 저장됩니다. 관리자의 Stored Backups 목록에서 개별 아카이브를 다운로드하거나 삭제할 수 있으며, Back up now로 온디맨드로 생성할 수 있습니다.

자동 백업은 예약된 유지보수 틱(예약 게시를 구동하는 것과 동일한 메커니즘)에 편승합니다 — Cloudflare에서는 Worker의 cron 트리거, Node에서는 내장 스케줄러입니다. 배포에 cron 트리거가 설정되지 않은 경우 대신 Back up now 또는 다운로드 버튼을 사용하세요.

미디어 객체 백업 및 복원

R2 및 S3 호환 버킷은 데이터베이스 외에 객체 수준 백업이 필요합니다. 다음 AWS CLI 예제는 EmDash의 backups/ 아카이브를 포함한 모든 객체를 로컬 백업 디렉토리에 복사합니다. AWS S3의 경우 --endpoint-url을 생략합니다.

aws s3 sync s3://emdash-media ./emdash-media-backup \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

일상적인 백업 작업에는 읽기 전용 버킷 자격 증명을 사용합니다. 백업을 프로덕션 계정이나 장애 도메인 외부에 저장하고, 동시에 생성한 데이터베이스 백업 또는 Time Travel 포인트를 기록합니다.

프로덕션이 요청을 처리하는 동안 덮어쓰는 대신 빈 복구 버킷으로 복원합니다:

aws s3 sync ./emdash-media-backup s3://emdash-media-recovery \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

복원 작업에는 복구 버킷에 대한 쓰기 접근만 부여합니다. 비프로덕션 배포를 해당 버킷으로 지정하고, 여러 알려진 미디어 URL을 열고, 일회용 파일을 업로드하고 삭제합니다. 복원된 데이터베이스와 미디어 세트가 함께 검사를 통과한 후에만 프로덕션 바인딩이나 버킷 설정을 전환합니다.

Time Travel로 D1 데이터베이스 복구

위험한 작업 전에 Time Travel에 현재 북마크를 요청하고 배포 또는 변경 기록과 함께 기록합니다:

npx wrangler d1 time-travel info my-database

복구가 필요한 경우, 사이트에 대한 쓰기를 중지하고 파괴적인 복원 명령을 실행하기 전에 사용 가능한 복원 지점을 검사합니다:

npx wrangler d1 time-travel restore my-database --timestamp=2026-07-08T13:00:00Z

Time Travel은 콘텐츠, 사용자, 설정, 플러그인 데이터, 마이그레이션 기록을 포함한 전체 데이터베이스를 복원합니다. R2 미디어 객체는 복원하지 않습니다. 명령이 완료되면 복원된 데이터베이스와 일치하는 애플리케이션 버전을 배포하고, 트래픽을 다시 열고, 로그인, 콘텐츠 읽기, 스키마 변경, 쓰기를 확인합니다.

자세한 내용은 D1 Time Travel 문서를 참조하세요.

오프사이트 D1 덤프 생성

원시 데이터베이스의 완전한 SQL 덤프(사용자 및 인증 테이블 포함)에는 Wrangler를 사용합니다:

npx wrangler d1 export my-database --remote --output=backup.sql

SQL 파일을 해당 애플리케이션 버전 및 동시에 생성한 미디어 백업과 함께 보관합니다. 덤프를 새로 프로비저닝한 빈 D1 데이터베이스에 가져오고, 비프로덕션 바인딩을 해당 데이터베이스로 업데이트하고, 사이트를 확인하여 복구를 테스트합니다.

다음 명령으로 빈 복구 데이터베이스에 가져옵니다:

npx wrangler d1 execute my-recovery-database --remote --file=backup.sql

SQLite 백업 및 복구

오프라인 SQLite 백업의 경우, 데이터베이스에 쓰는 모든 프로세스를 중지하고 데이터베이스 파일을 복사합니다. 일관된 온라인 백업의 경우 SQLite의 백업 명령을 사용합니다:

sqlite3 emdash.db ".backup backup.db"

로컬 업로드 디렉토리 또는 S3 호환 버킷은 별도로 백업합니다. 복구하려면 모든 서버 프로세스를 중지하고, 손상된 데이터베이스의 사본을 보관하고, 검증된 백업으로 교체하고, 필요한 미디어 객체를 복원하고, 해당 애플리케이션 버전을 시작합니다. 트래픽을 다시 열기 전에 로그인, 공개 콘텐츠, 편집, 미디어 읽기를 확인합니다.

JSON 내보내기로는 사이트를 복원할 수 없음

EmDash에는 JSON 복원을 위한 관리자 액션, API 엔드포인트 또는 CLI 명령이 없습니다. 위에서 설명한 대로 D1 Time Travel, 원시 D1 SQL 덤프 또는 SQLite 데이터베이스의 사본을 사용하세요.