백업 대상

백업 전략은 둘 이상의 스토어에 쓸 수 있습니다. 각 대상은 독립된 복구 지점이며, 자체 스냅샷과 자체 커밋, 자체 상태 행을 가지므로 한 스토어가 실패해도 다른 스토어는 영향을 받지 않습니다.

모든 스토어는 하나의 계정에 속합니다. config 하나, 라이선스 하나, 청구서 하나가 전부를 포괄합니다. 두 계정에 로그인한 머신은 기존처럼 거부됩니다. 대상이 여러 개라는 것은 한 계정 안에 스토어가 여러 개라는 뜻이기 때문입니다.

스토어

스토어는 계정 서버가 머신을 대신해 쓰는 버킷입니다. 모든 구독에는 첫날부터 home이라는 스토어가 하나 있습니다. 백업 명령이 늘 사용해 온 호스팅 스토어입니다. 스토어를 지정하지 않은 대상은 home에 씁니다.

이 밖에 두 가지 종류를 등록할 수 있습니다.

종류	설명	등록에 필요한 것
hosted-r2	배포 환경이 제공하는 리전 중에서 고르는 두 번째 호스팅 리전	ID와 리전. 자격 증명은 필요 없음
customer-s3	고객이 직접 운영하는 버킷. S3, RustFS 또는 S3 호환 서비스	ID, HTTPS 엔드포인트, 버킷, 서명 리전(기본값 us-east-1), 선택 사항인 공개 엔드포인트, 액세스 키 쌍 하나

머신은 고객 버킷의 키를 절대 보관하지 않습니다. 키는 봉인된 상태로 계정 서버에 있고, 머신은 세션이 지정한 하나의 스토어에 대해서만 수명이 짧은 사전 서명 URL을 받습니다.

스토어 등록

등록은 rdc 명령이 아니라 계정 API 호출입니다. POST /backups/stores는 스토어를 등록하고, GET /backups/stores는 등록된 스토어를 나열하며, DELETE /backups/stores/<id>는 스토어를 폐기합니다. 등록, 교체, 폐기에는 현재 조직 소유자나 관리자가 만든 backup:manage 스코프의 API 토큰이 필요하며, 모두 감사 기록에 남습니다. 목록 조회에는 backup:read가 필요합니다.

서버는 스토어를 받아들이기 전에 검사합니다.

• 적합성 프로브. 서버는 호스팅 스토어가 통과하는 것과 같은 검사를 실행합니다. 체크섬을 강제하지 않는 스토어는 첫 백업에서 발견되는 대신 등록 시점에 거부됩니다.
• 삭제 프로브. 프로브는 삭제도 시도합니다. 스토어가 삭제를 거부하면 정리가 비활성화된 상태로 등록됩니다(아래 참고).
• 엔드포인트 규칙. HTTPS만 허용하며, 포트는 443이고, 내부 네트워크의 엔드포인트는 안 됩니다.
• 스토어 한도. 구독당 스토어 수는 요금제에 따라 다르며, home은 포함하고 폐기된 스토어는 세지 않습니다.

요금제	스토어
Free	1
Community	2
Professional	3
Business	5
Enterprise	10

이미 있는 ID를 등록하면 자격 증명만 교체되고 프로브가 다시 실행됩니다. 자격 증명이 더 이상 작동하지 않는 스토어는 처음 거부된 권한 부여 시점에 일시 중지로 표시됩니다. GET /backups/stores는 엔드포인트, 버킷, 키 ID의 마지막 몇 글자를 보여 주며 시크릿은 절대 보여 주지 않습니다.

활성화된 대상이 아직 이름을 지정하고 있는 스토어는 폐기할 수 없고, home은 폐기할 수 없습니다.

대상의 스토어 지정

대상은 --destination과 함께 쓰는 --target으로 스토어를 지정합니다.

# Write to the home store (the default).
rdc backup strategy set daily --destination primary

# Write to a registered store.
rdc backup strategy set daily --destination offsite --target office-rustfs

옵션	설명
--destination <name>	만들거나 변경할 대상
--target <storeId>	대상이 쓰는 등록된 스토어 ID(기본값 home). --destination이 필요

한 전략의 활성화된 두 대상이 같은 스토어를 지정할 수는 없고, 등록되지 않은 스토어는 등록된 ID 목록과 함께 거부됩니다.

예약된 실행마다 활성화된 대상별로 스냅샷을 하나씩, 대상을 선언한 순서대로 만들며, 각각 자체 대역폭 제한이 적용됩니다. 모든 스냅샷은 새로운 copy-on-write reflink이므로 각각이 그 자체로 일관된 시점입니다. 실패한 대상이 있어도 다음 대상을 건너뛰지 않습니다. 다만 어느 대상이든 실패하면 유닛은 0이 아닌 코드로 종료하므로 systemd와 누락 실행 점검이 실패를 확인할 수 있습니다.

스토어에서 복원

rdc backup restore, rdc backup restore --path, rdc backup browse --at, rdc backup download --store는 --from <storeId>를 받습니다.

# The best store, chosen automatically.
rdc backup restore my-app --as my-app-copy --at <snapshot-id>

# One named store.
rdc backup restore my-app --as my-app-copy --at <snapshot-id> --from office-rustfs

--from이 없으면 CLI가 계정 서버에 저장소의 계보를 보유한 스토어를 물어봅니다. 마지막 검증을 통과한 최신 스냅샷을 가진 스토어를 맨 앞에 두고 순위를 매기며, CLI는 그 순서대로 시도합니다. 스냅샷이 없는 스토어는 건너뜁니다. 순위를 읽을 수 없으면 복원은 home을 사용하고 그 사실을 알립니다.

--from 없이 실행한 backup restore, restore --path, browse --at, download --store는 그 순위의 첫 번째 스토어에서 시작하며, 문제가 스토어에 있을 때 다음 스토어로 넘어갑니다. 서버 오류, 거부된 권한 부여나 세션, 응답하지 않는 엔드포인트가 해당합니다. 각 명령은 어느 스토어가 처리했는지 알려 줍니다. 스냅샷 자체의 결함으로는 어느 명령도 넘어가지 않습니다. 없거나 만료되었거나 손상된 스냅샷은 어느 스토어에서나 똑같이 보이므로 대신 오류를 보여 줍니다. --from을 준 명령은 그 스토어만 읽고 절대 넘어가지 않습니다.

--from 없이 지정한 스냅샷 ID는 계보의 모든 스토어에서 찾습니다.

대상별 상태

rdc backup status는 일정 표와 함께 대상별로 한 행씩 출력합니다.

열	의미
Store	대상이 쓰는 스토어 ID
Last run	해당 스토어에 대한 마지막 실행이 끝난 시각
Result	그 실행의 결과
Newest snapshot	스토어가 가진 가장 최근 스냅샷
Verify	스토어의 마지막 검증 결과
Clean-up	enabled, 또는 비활성화된 경우 그 이유

계정이 상태를 보고할 수 없는 스토어는 해당 열에 -가 표시됩니다. 누락 실행 점검은 스토어별로 이루어지므로, 백업을 받지 못하게 된 스토어는 자체 경보를 울리고 나머지는 정상으로 유지됩니다.

할당량에 포함되는 것

호스팅 스토어, 즉 home과 두 번째 리전은 물리적으로 저장된 고유 바이트로 측정되며, 그 바이트는 같은 요금제 할당량에 포함됩니다. rdc backup usage로 확인할 수 있습니다.

고객 버킷의 바이트는 Rediacc가 저장하지 않으므로 할당량에 포함되지 않습니다. 계정이 그 버킷을 위해 보관하는 메타데이터(매니페스트 행, 검증 실행, 인덱스 오브젝트)는 호스팅 스토어와 같은 방식으로 측정됩니다.

정리가 비활성화된 스토어

삭제를 거부하는 스토어는 모든 오브젝트를 그대로 둡니다. 보존 정책과 가비지 컬렉션은 그곳에서 아무것도 삭제하지 않습니다. 스냅샷이 만료되면 스위프가 계정에서 해당 스냅샷을 만료로 표시하고, 복원 후보에서 제외하며, 오브젝트는 버킷에 남겨 둡니다.

rdc backup status와 백업 상태 요약은 해당 스토어를 정리 비활성화로 보고합니다. 삭제 권한이 있는 키로 같은 ID를 다시 등록해 삭제 자격 증명을 추가하기 전까지 버킷은 계속 커집니다.