백업 및 복구

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

사이트의 콘텐츠, 설정, 미디어를 새 EmDash 사이트(다른 데이터베이스 포함)로 복사하려면 대신 사이트 패키지를 사용하세요.

사이트가 암호화된 플러그인 설정을 저장하면, 전체 EMDASH_ENCRYPTION_KEY 교체 목록을 별도 비밀 관리자 백업에 보관하세요. 키는 데이터베이스, D1 Time Travel, SQL 덤프, JSON보내기에 절대 저장되지 않습니다.

백업에 포함된 내용

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

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

다음을 포함한 다른 모든 데이터베이스 테이블은 생략합니다.

• 사용자 계정, 세션, 패스키, OAuth 데이터, API 토큰, 기타 인증 데이터
• 플러그인 스토리지 및 플러그인 설정(플러그인 비밀 포함)
• 댓글과 반응, 리다이렉트와 404 로그, 바이라인, 콘텐츠 관계와 참조, 감사 로그, 속도 제한, 예약 작업 상태
• 미디어 폴더, 미디어 사용 위치 기록, 미완료 또는 진행 중 업로드, 미디어 파일 자체
• 설정 시 기록된 배포 URL(emdash:site_url), 미리보기 서명 비밀, 백업 일정을 포함한 기타 사이트 옵션

백업은 EmDash 미리보기 시스템과 같은 스냅샷 형식의 JSON 파일이며, 생성한 EmDash 릴리스로 버전됩니다.

원클릭 다운로드

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

다운로드는 검사 또는 사용자 지정 도구용입니다. 대량 가져오기, 스키마 변경, 주요 업그레이드 전에 아래 옵션 중 하나로 복원 가능한 데이터베이스 백업을 만드세요. 사이트를 다른 EmDash 사이트로 옮기려면 Settings → Transfer에서 사이트 패키지를 내보내세요.

스토리지로 자동 백업

사이트에 스토리지 백엔드(Cloudflare의 R2, S3, 또는 로컬 스토리지)가 구성되어 있으면 일일 자동 백업을 켤 수 있습니다.

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

자동 백업은 예약 유지보수 tick(예약 게시와 같은 메커니즘)에 편승합니다. 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 미디어 객체나 EMDASH_ENCRYPTION_KEY는 복원하지 않습니다. 플러그인 연동을 테스트하기 전에 복구된 플러그인 설정이 참조하는 모든 암호화 키를 복원하세요. 명령 완료 후 복원된 데이터베이스에 맞는 애플리케이션 버전을 배포하고, 트래픽을 다시 연 뒤 로그인, 콘텐츠 읽기, 스키마 변경, 암호화된 플러그인 설정, 쓰기를 검증하세요.

자세한 내용은 D1 Time Travel 문서를 보세요.

오프사이트 D1 덤프 만들기

원시 데이터베이스(사용자 및 인증 테이블 포함)의 전체 SQL 덤프에는 Wrangler를 사용하세요.

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

SQL 파일을 맞는 애플리케이션 버전, 동시에 만든 미디어 백업, 별도 저장한 EMDASH_ENCRYPTION_KEY 교체 목록 복사본과 함께 보관하세요. 새로 프로비저닝한 빈 D1 데이터베이스에 덤프를 가져오고, 런타임 키를 복원하고, 비프로덕션 바인딩을 그 데이터베이스로 업데이트한 뒤 사이트를 검증해 복구를 테스트하세요.

빈 복구 데이터베이스로 가져오기는 다음 명령입니다.

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

SQLite 백업 및 복구

오프라인 SQLite 백업에서는 데이터베이스에 쓰는 모든 프로세스를 멈추고 데이터베이스 파일과 옆의 -wal, -shm 파일을 복사하세요. -wal 파일에는 아직 메인 파일에 없는 커밋된 변경이 있을 수 있습니다. 일관된 온라인 백업에는 SQLite 백업 명령을 사용하세요.

sqlite3 emdash.db ".backup backup.db"

로컬 업로드 디렉터리 또는 S3 호환 버킷과 EMDASH_ENCRYPTION_KEY 교체 목록은 따로 백업하세요. 복구하려면 모든 서버 프로세스를 멈추고, 손상된 데이터베이스 복사본을 보관하고, 검증된 백업으로 교체하고, 런타임 키와 필요한 미디어 객체를 복원한 뒤 맞는 애플리케이션 버전을 시작하세요. 트래픽을 다시 열기 전에 로그인, 공개 콘텐츠, 암호화된 플러그인 설정, 편집, 미디어 읽기를 검증하세요.

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

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

새롭고 빈 EmDash 사이트에 사이트 콘텐츠를 다시 만들려면 원본 사이트가 아직 사용 가능할 때 사이트 패키지를 내보낸 뒤 새 사이트로 가져오세요. 사이트 패키지는 사용자, API 토큰, 플러그인 데이터, 비밀을 복원하지 않으므로 재해 복구용 데이터베이스 백업을 대체하지 않습니다.