무엇을 백업하고, 어떻게 복원하며, 장애에 어떻게 대비할 것인가.

백업 및 재해 복구

ObjectOS 자체는 상태를 저장하지 않습니다(stateless). 런타임은 컨테이너 이미지로부터 재구축할 수 있습니다. 백업은 ObjectOS 자체가 아니라 ObjectOS가 의존하는 데이터에 관한 것입니다. 복구는 이러한 데이터셋을 중심으로 계획하세요.

무엇을 백업할 것인가

자산	소유 주체	백업 전략
비즈니스 데이터베이스	고객	데이터베이스 네이티브 백업(관리형 서비스의 경우 PITR), 분기마다 복원 테스트 수행
컴파일된 아티팩트(`objectstack.json`)	애플리케이션/릴리스 팀	게시된 모든 아티팩트를 변경 불가능한 스토리지에 저장, 절대 덮어쓰지 않음
시크릿 기준선	고객의 시크릿 관리자	벤더 네이티브 백업, 정책에 따른 교체 주기
객체/파일 스토리지(`storage` 기능이 활성화된 경우)	고객	버킷 버전 관리 + 필요 시 리전 간 복제
고객이 관리하는 ID 공급자	IdP 벤더	벤더 네이티브

ObjectOS는 컨테이너 파일시스템에 대한 별도의 백업을 요구하지 않습니다. 캐시 디렉터리(OS_CACHE_DIR)는 재구축이 가능합니다.

데이터베이스 백업

전략을 드라이버에 맞추세요:

드라이버	권장 접근 방식
PostgreSQL	지속적인 WAL 아카이빙 + 베이스 백업, 시점 복원(point-in-time restore)
MySQL	바이너리 로그 아카이빙 + 전체 덤프, 시점 복원
MongoDB	레플리카 세트 스냅샷, PITR를 위한 oplog
SQLite(단일 노드 / 데스크톱)	WAL 모드 + `VACUUM INTO` 또는 Online Backup API를 통한 핫 스냅샷, 필요 시 Litestream으로 지속적 복제 — 아래 SQLite 배포 참조

드라이버와 관계없이 다음을 검증하세요:

백업이 고객의 RPO 내에 완료되는지,
동일한 아티팩트로 새 데이터베이스에서 ObjectOS를 부팅하여 트래픽을 처리할 수 있는지,
복원 테스트가 적어도 분기에 한 번 엔드 투 엔드로 수행되는지.

SQLite는 기본 드라이버이며 단일 노드 ObjectOS — 데스크톱 앱, 소규모 팀용 내부 도구, 엣지 / 온프레미스 어플라이언스, 평가 환경 — 에서 정당한 프로덕션 선택지입니다. 트레이드오프는 구조적입니다. SQLite는 단일 쓰기(single-writer)이므로 멀티 노드 ObjectOS, 높은 동시 쓰기 처리량, 또는 공유 데이터베이스 배포에는 적합하지 않습니다. 그러한 경우에는 PostgreSQL을 사용하세요.

SQLite를 프로덕션에서 실행할 때는, 안전하게 만드는 구성과 백업 레시피가 함께 갑니다:

런타임 구성

WAL 활성화: PRAGMA journal_mode=WAL(리더가 라이터를 차단하지 않으며, 크래시에 안전함).
PRAGMA synchronous=NORMAL은 일반적인 데스크톱/단일 노드 기본값입니다 — WAL과 함께 사용하면 안전하고 FULL보다 훨씬 빠릅니다.
데이터베이스 파일은 로컬 디스크에 두세요. 런타임이 실행 중인 동안에는 NFS, SMB, 또는 Dropbox / OneDrive / iCloud로 동기화되는 폴더 안에 두지 마세요 — 이러한 환경에서는 SQLite의 잠금이 불안정하며, 이것이 SQLite 배포가 손상되는 가장 흔한 원인입니다.

핫 스냅샷(다운타임 없음)

런타임은 SQLite의 Online Backup API 또는 VACUUM INTO를 사용하여 스냅샷을 찍는 동안에도 트래픽을 계속 처리합니다:

VACUUM INTO '/var/backups/objectos/db-2026-05-27T13-00Z.sqlite';

RPO에 맞는 주기로(cron, systemd 타이머, 또는 인프로세스 스케줄러) 이를 예약하세요. 각 스냅샷에 이를 생성한 아티팩트 버전을 태그하여 데이터베이스와 아티팩트를 함께 롤백할 수 있도록 하세요 (아래 아티팩트 버전 관리 참조).

오프사이트 복사본

로컬 스냅샷은 디스크 손실에서 살아남지 못합니다. 각 스냅샷을 내구성 있는 스토리지로 푸시하세요:

서버 / VM: S3 또는 S3 호환 버킷으로 푸시하세요(이미 storage 기능을 위해 하나 구성되어 있을 가능성이 높습니다).
데스크톱 앱: 스냅샷을 사용자가 제어하는 동기화 폴더(OneDrive / iCloud / Google Drive)에 기록하세요 — 스냅샷 파일은 라이브 데이터베이스와 달리 닫혀 있고 변경 불가능하므로 여기서는 허용됩니다.

지속적 복제(낮은 RPO)

SQLite를 포기하지 않으면서 1분 미만의 RPO를 원한다면, ObjectOS 프로세스와 함께 Litestream을 실행하세요. WAL을 S3 호환 스토리지로 스트리밍하고 시점 복원을 지원합니다. 단일 노드 SQLite 배포가 거의 제로에 가까운 데이터 손실을 필요로 할 때 권장되는 방법입니다.

복원

런타임을 중지하고, 데이터베이스 파일을 선택한 스냅샷으로 교체한 뒤 (또는 litestream restore 실행), 해당 스냅샷을 생성한 동일한 아티팩트 버전으로 런타임을 시작하세요.

아티팩트 버전 관리

게시된 아티팩트는 변경 불가능한 것으로 취급하세요. 각 아티팩트에 이를 컴파일하는 데 사용된 릴리스 id를 태그하세요(예: objectstack-2026-05-24.json). 알려진 정상 비즈니스 상태로의 복구는 보통 다음을 의미합니다:

데이터베이스를 선택한 시점으로 복원합니다.
ObjectOS를 그 시점에 활성화되어 있던 아티팩트 버전으로 다시 가리킵니다.
런타임을 다시 시작합니다.

아티팩트를 제자리에서 덮어쓰면, 데이터베이스 백업이 완벽하더라도 깔끔하게 롤백할 수 있는 능력을 잃게 됩니다.

RPO/RTO 계획

고객 배포를 위한 실용적인 시작 목표:

등급	RPO	RTO	비고
평가 / 데모	최선의 노력	최선의 노력	SQLite 스냅샷으로 충분
데스크톱 앱 / 소규모 팀 단일 노드	≤ 1시간(스냅샷) 또는 ≤ 수 초(Litestream)	수 분	SQLite + WAL + 예약된 `VACUUM INTO` + 오프사이트 복사본
단일 테넌트 프로덕션	≤ 15분	≤ 1시간	PITR가 있는 관리형 PostgreSQL + 웜 이미지
멀티 테넌트 / 규제 대상	≤ 5분	≤ 30분	HA 데이터베이스 + 멀티 AZ ObjectOS + 테스트된 런북

더 엄격한 목표를 달성하려면 ObjectOS 컨테이너 자체 외부의 플랫폼 변경(HA 데이터베이스, 멀티 AZ 인그레스, 웜 레플리카)이 필요합니다.

연습해 볼 만한 장애 모드

데이터베이스가 장시간 사용 불가. 런타임이 명확한 503을 표출하고 프로브가 파드를 올바르게 비정상으로 표시하는지 확인하세요.
아티팩트 회귀. 아티팩트 포인터를 롤백하세요. 데이터는 영향을 받지 않습니다.
시크릿 교체. AUTH_SECRET을 교체하면 모든 세션이 무효화됩니다. 유지보수 시간대에 실행하거나 레플리카 간에 시차를 두고 진행하세요.
리전 장애. 고객이 리전 페일오버를 요구하는 경우, 비즈니스 데이터베이스, 시크릿 관리자, 인그레스가 모두 리전 간으로 구성되어야 합니다. ObjectOS 자체는 이미지를 사용할 수 있는 곳이라면 어디서든 실행할 수 있습니다.

런북에 담아야 할 것

각 데이터셋에 대한 백업 일정, 보존 기간, 온콜 담당자.
단계별 복원 절차(데이터베이스 먼저, 그다음 아티팩트, 그다음 ObjectOS 시작).
복원된 데이터베이스가 일관적인지 확인하기 위한 검증 쿼리.
ObjectOS 이미지와 아티팩트 버전 모두에 대한 롤백 계획(자세한 내용은 업그레이드 및 롤백 참조).
고객에게 노출되는 인시던트를 위한 커뮤니케이션 템플릿.

백업 및 재해 복구

On this page