백업 및 복원
Rediacc는 암호화된 저장소를 백업하고, 같은 머신 또는 다른 머신에서 복원합니다. 백업이 암호화되는 이유는 저장소 자체가 암호화되어 있기 때문입니다. 머신을 벗어나는 것은 암호문뿐이며, 복원하려면 저장소의 LUKS 자격 증명이 필요합니다.
백업에는 두 가지 방법이 있으며, 각각 서로 다른 질문에 답합니다.
- 청크 스토리지로의 스냅샷(
rdc backup snapshot)은 되돌아볼 수 있는 이력을 유지합니다. 이것이 주된 경로입니다. - 다른 머신으로의 사본(
rdc repo push,rdc repo pull)은 직접 관리하는 하드웨어에 지금 상태 그대로의 저장소를 유지합니다. 클라우드 계정은 관여하지 않습니다.
이 둘은 서로 독립적입니다. 한 방법으로 백업한 저장소는 다른 방법으로는 백업되지 않습니다.
스냅샷의 작동 방식
저장소 이미지는 고정된 크기의 그리드 위에서 고정 크기의 셀로 잘립니다. 각 셀은 한 번도 기록된 적 없는 구멍이거나, 그 셀의 암호문의 SHA-256인 키 아래에 저장되어 있는 둘 중 하나입니다.
바로 이 하나의 결정에서 모든 특성이 나옵니다.
비용이 드는 것은 실제 변경분뿐입니다. 첫 스냅샷은 기록된 셀을 모두 업로드합니다. 그 이후의 모든 실행은 어떤 익스텐트가 건드려졌는지 파일 시스템에 물어보고, 그 부분만 읽고 해시한 뒤, 스토어가 아직 갖고 있지 않은 셀만 업로드합니다. 데이터가 거의 움직이지 않은 저장소는 거의 아무것도 업로드하지 않으며, 실행 시간은 이미지 크기에 비례하지 않고 몇 분 안에 끝납니다.
동일한 데이터는 한 번만 저장됩니다. 키가 콘텐츠 해시이기 때문에, 셀을 공유하는 두 스냅샷은 같은 오브젝트를 공유합니다. 저장소와 그 포크도 마찬가지입니다. 하나의 포크 계열은 부모를 중복해서 백업하지 않고 하나의 계보에 대해서만 백업됩니다.
오래된 스냅샷을 복원한다고 해서 최근 스냅샷보다 느려지지 않습니다. 차례로 재생해야 하는 증분의 체인이 존재하지 않습니다. 복원은 스냅샷을 완전한 셀 목록으로 해석한 뒤 그 셀들을 곧바로 가져오므로, 복원 시간은 백업을 시작한 지 얼마나 됐는지가 아니라 이미지 크기와 대역폭을 따라갑니다. 구멍은 구멍인 채로 복원되므로 희소 이미지는 희소하게 복원되며, 이미지 안 여러 곳에 나타나는 셀도 한 번만 다운로드됩니다.
모든 스냅샷은 그 자체로 완결됩니다. 잃어서는 안 되는 “전체 백업” 같은 것은 없고, 깨진 증분 하나가 그 뒤의 모든 것을 무효화하는 구간도 없습니다. 목록에 있는 어떤 스냅샷이든 곧바로 복원 가능합니다.
검증은 신뢰가 아니라 재해시입니다. 키가 콘텐츠의 해시인 이상, 백업을 확인한다는 것은 셀을 가져와 해시하는 것과 같습니다. rdc backup verify는 표본을 추출하고, rdc backup verify --deep은 기록된 모든 셀을 다시 해시합니다.
중단된 실행도 낭비되지 않습니다. 업로드는 이미 도착한 셀을 다시 보내지 않고 재개되며, 중단된 복원을 다시 시작하면 이미 디스크에 있는 것을 재해시해서 재사용할 뿐 다시 다운로드하지 않습니다.
여러분에게 드는 비용
할당량은 물리적으로 고유하게 저장된 바이트 수로 계산됩니다. 이는 중복 제거 후 실제로 보관 중인 양이며, 스냅샷들이 논리적으로 나타내는 총량이 아닙니다. 천천히 변하는 저장소의 스냅샷 30개는 1개에 가까운 비용이 듭니다.
rdc backup usage는 저장된 바이트 수를 할당량과 대비해서 보여주며, 이는 구독별 수치로 Community 플랜에서는 10 GB부터 시작합니다.
스냅샷에 필요한 것
스냅샷 업로드는 계정 서버를 거칩니다. 계정 서버는 저장소에 설치된 라이선스에 대해 각 실행을 인가하고, 머신에 짧게 유효한 쓰기 권한을 발급합니다. 그래서 이 경로에는 머신이 도달할 수 있는 계정 서버와 라이선스가 있는 저장소가 필요합니다. 이것들이 없으면 스냅샷은 조용히 건너뛰어지는 게 아니라 거부되며, rdc backup manifests, rdc backup usage, rdc backup retention은 읽을 것이 아무것도 없게 됩니다.
이는 --dry-run에도 그대로 적용됩니다. 실행이 계획 중인지 업로드 중인지 판단하기 전에 라이선스를 읽으므로, 드라이런은 자격 증명 없이 명령을 시험해보는 방법이 아니라 실제 작업의 미리보기입니다.
머신 간 푸시와 풀은 둘 다 필요하지 않습니다. 이미 설정에 들어 있는 두 머신 사이의 직접 전송입니다.
스냅샷이 보장하지 않는 것
- 스냅샷은 하나의 저장소를 대상으로 하며, 머신 전체를 한 번에 대상으로 하지 않습니다. 각 저장소는 각자의 순간에 캡처됩니다. 두 저장소가 서로 의존한다면, 그 스냅샷들은 서로 맞물린 짝이 아닙니다.
- 지속적인 복제가 아닙니다. 스냅샷은 여러분이 찍은 한 시점이며, 마지막 스냅샷 이후 기록된 모든 것을 잃을 수 있습니다. 그 양은 실행 빈도에 따라 달라집니다.
- 저장된 오브젝트는 한 번만 쓰이며, 인증된 WORM은 아닙니다. 셀은 생성 전용 조건부로 기록되며, 머신이 받는 권한으로는 아무것도 삭제할 수 없고, 삭제는 보존 정책에 따라 서버 측에서 이루어집니다. 이는 침해된 머신이 자신의 백업을 파괴하는 것에 대한 실질적인 장벽이지만, 컴플라이언스 인증은 아니며 그렇게 감사받지도 않습니다.
rclone 스토리지 경로는 사라졌습니다
rdc repo push --to <storage>와 그 관련 명령들은 예전에는 직접 등록한 클라우드 프로바이더로 백업 파일 전체를 복사했습니다. 이제는 스토리지 대상을 거부하고 대체 경로의 이름을 알려줍니다. 머신 간 전송은 애초에 rclone을 거친 적이 없으므로 영향을 받지 않습니다. 그 방식으로 작성된 아카이브를 아직 읽어야 한다면 폐지 이전에 작성된 아카이브 읽기를 참조하세요.
청크 스토리지 명령
# 스냅샷을 업로드한다. 첫 실행은 시드하고, 이후 실행은 변경된 셀만 전송한다.
rdc backup snapshot my-app
# 업로드하지 않고 계획만 세운다: 무엇이 이동할지 보고한다.
rdc backup snapshot my-app --dry-run
# 컨테이너를 멈추고, 동결하고, 재시작한 뒤 업로드한다.
rdc backup snapshot my-app --cold
# 로컬 앵커를 신뢰하지 않고 전체 인벤토리를 다시 업로드한다.
# 이는 모든 것을 다시 업로드하고 할당량을 다시 소진시키므로,
# 앵커가 손상되었다고 알고 있을 때만 사용한다.
rdc backup snapshot my-app --reseed
# 저장된 인벤토리와 할당량을 확인한다.
rdc backup verify my-app
rdc backup manifests my-app
rdc backup usage| 옵션 | 설명 |
|---|---|
<repo-ref>(위치 인자) | 스냅샷을 찍을 저장소 |
--dry-run | 계획만: 업로드 없음. 무엇이 이동할지 보고 |
--cold | 컨테이너를 멈추고, 동결하고, 재시작한 뒤 업로드. --dry-run과 함께 쓸 수 없음 |
--reseed | 로컬 앵커를 신뢰하지 않고 전체 인벤토리를 업로드. 모든 것을 다시 업로드하고 할당량을 다시 소진 |
--debug | 상세 출력 활성화 |
콜드 스냅샷(--cold)
콜드 스냅샷은 동결하기 전에 저장소를 먼저 멈춥니다. 그래서 저장되는 이미지는 크래시 일관성이 아니라 애플리케이션 일관성을 갖습니다. 명령은 머신에서 직접 실행합니다.
# 기본 데이터스토어에 있는 모든 저장소.
sudo renet backup snapshot --cold
# 지정한 저장소만. --repo는 저장소 GUID를 받으며 반복 지정할 수 있습니다.
sudo renet backup snapshot --cold --repo <guid> --repo <guid>--cold는 --dry-run과 함께 쓸 수 없습니다. 컨테이너를 멈추는 드라이런은 드라이하지 않고, 멈추지 않는 실행은 콜드가 아닙니다. 그래서 renet은 의미를 임의로 정하는 대신 이 조합을 거부합니다.
콜드 실행이 하는 일
선택된 각 저장소에 대해, 다음 순서로 진행됩니다.
- 컨테이너를 멈춘다.
- 저장소 마운트와 데이터스토어를 디스크에 플러시한다.
- 컨테이너가 실제로 멈췄는지 확인한다.
- 저장소 이미지의 카피온라이트 reflink를 뜬다.
- 컨테이너를 다시 시작한다.
업로드는 그 이후에야 시작되며, 그때는 이미 모든 저장소가 다시 돌아가고 있습니다.
다운타임은 동결이지 전송이 아닙니다. reflink는 메타데이터일 뿐이므로 저장소가 1 GB든 100 GB든 걸리는 시간은 같습니다. 업로드는 그렇지 않습니다. 변경된 바이트 수에 비례해서 늘어나며, 첫 스냅샷은 0이 아닌 인벤토리 전체를 업로드합니다. 업로드가 끝날 때까지 컨테이너를 내려둔다면 다운타임이 데이터 양에 묶이게 되어, 첫 시드에서는 밀리초가 아니라 몇 시간이 걸리게 됩니다.
선택된 모든 저장소는 하나씩이 아니라 하나의 윈도우 안에서 함께 멈춥니다. 이는 저장소당 다운타임을 약간 늘리는 대신, 전체에 걸쳐 하나의 일관성 지점을 얻게 해줍니다.
컨테이너가 하나도 실행 중이지 않은 저장소는 이미 조용한 상태입니다. 다운타임 없이 스냅샷이 찍히며, 이는 실패가 아니라 정상적인 결과입니다.
다운타임의 비용
실제 머신에서 측정한 결과, 전체 다운타임은 222 ms였습니다.
| 단계 | 측정값 | 내용 |
|---|---|---|
cold_down | 64 ms | 컨테이너가 멈춘다 |
cold_sync | 26 ms | 저장소 마운트와 데이터스토어를 디스크에 플러시한다 |
cold_verify | 31 ms | 컨테이너가 멈췄는지 확인한다 |
cold_stage | 0 ms | 저장소 이미지의 reflink |
cold_up | 99 ms | 컨테이너가 다시 시작된다 |
대부분을 차지하는 것은 컨테이너 재시작이며, 스테이징은 사실상 0입니다. reflink는 밀리초 단위 해상도에서는 잡히지 않습니다. 다만 이 0은 단독으로가 아니라 저장소별 레코드와 함께 읽으세요. 모든 저장소를 거부한 실행도 cold_stage=0ms로 보고하므로, 둘 중 어느 쪽인지는 레코드만이 말해줍니다.
이 분석은 장식이 아니라 근거입니다. 다섯 단계 중 어느 것도 저장소 데이터를 읽거나 보내지 않으므로, 백업이 커져도 이들은 늘어나지 않습니다. 늘어나는 것은 업로드뿐이며, 이는 다운타임이 끝난 뒤에 실행됩니다.
renet은 실행이 끝날 때 동일한 수치를 출력하므로, 저희 측정치를 믿는 대신 여러분의 머신에서 직접 재보실 수 있습니다.
Cold backup: <n> repositories quiesced, outage 222ms (cold_down=64ms cold_sync=26ms cold_verify=31ms cold_stage=0ms cold_up=99ms)각 저장소의 JSON 레코드에도 동일한 다운타임과 단계가 기록되므로, 나중에 시간을 근거로 추측하지 않고도 콜드 스냅샷과 핫 스냅샷을 구분할 수 있습니다.
콜드를 선택하는 경우
기본값은 핫이며, 대부분의 저장소에는 그것이 옳은 선택입니다. 핫 스냅샷은 크래시 일관성을 가지며, 이는 정전 직후의 저장소가 처했을 상태와 같습니다. 다운타임은 전혀 발생하지 않습니다. 대부분의 데이터베이스와 큐는 그 상태에서 스스로 복구합니다.
콜드는 기록되는 도중에는 안전하게 캡처할 수 없는 데이터를 위해 선택합니다. 자체 선행 기입 로그와 메모리 내 상태를 가진 데이터베이스가 전형적인 예입니다. 짧고 측정 가능한 다운타임을 감수하는 대신, 애플리케이션이 복구 과정 없이 곧바로 열 수 있는 스냅샷을 얻게 됩니다.
콜드 실행이 거부하는 것
거부하는 것 자체가 기능입니다. 아무것도 정지시키지 않았으면서 콜드라고 자칭하는 백업은, 복원할 때가 되어서야 드러나는 거짓말입니다. 그래서 renet은 콜드 실행을 조용히 핫으로 격하시키지 않습니다.
- 멈추지 않은 컨테이너. 정지 이후, renet은 저장소 자체의 Docker 소켓에 아직 실행 중인 것이 있는지 물어봅니다. 있다면, 그 저장소는 스냅샷 없이 거부됩니다. 이 검사는 안전한 쪽으로 실패합니다. 소켓에 접근할 수 없거나 컨테이너 목록을 읽을 수 없으면, 정지 여부는 미확인으로 간주되고 미확인은 거부됩니다.
- 읽을 수 없는 라이선스. 라이선스는 다운타임 이후가 아니라 이전에 확인됩니다. 라이선스를 읽을 수 없는 저장소는 애초에 아무것도 업로드할 수 없었을 것이기 때문입니다. 그런 저장소는 멈추지도 않고 건너뛰어집니다. 선택된 저장소 중 어느 하나도 읽을 수 있는 라이선스가 없다면, 컨테이너가 단 하나도 내려가기 전에 전체 실행이 거부됩니다.
- 같은 데이터스토어에 대한 두 번째 콜드 실행. 잠금은 데이터스토어 전체를 덮으며, 잠금이 사용 중이면 아무것도 멈추지 않은 채 즉시 거부됩니다. 겹치는 두 실행은 서로 자신의 것이라 믿는 컨테이너를 각각 멈춰버리고, 두 번째 실행은 첫 번째 실행이 아직 동결 중인 저장소를 재시작해버릴 수 있습니다. 실행을 건너뛰고 다음을 기다리는 편이 낫습니다.
컨테이너가 내려가 있는 동안 systemctl stop이나 재부팅으로 실행이 중단되면, renet은 종료하기 전에 컨테이너를 다시 시작합니다. 머신 측 복구는 최후의 안전망입니다. 소유자가 사라진 콜드 백업을 발견해서 해당 저장소들을 다시 살립니다.
다른 머신으로 백업 푸시하기
SSH를 통해 저장소를 두 번째 머신으로 복사합니다.
rdc repo push my-app --to server-1--to <machine>은 설정에서 대상을 해석하며, --to-machine <machine>은 같은 것을 명시적으로 지정합니다. 스토리지 이름은 거부됩니다. 그 경로는 폐지되었습니다.
암호화된 이미지는 동일한 GUID로 복사되므로, 이는 포크가 아니라 백업 또는 마이그레이션입니다. 독립된 사본이 필요하다면 먼저 rdc repo fork를 실행한 뒤 그 포크를 푸시하세요.
첫 번째 푸시는 이미지 전체를 전달합니다. 그 이후의 모든 푸시는 두 머신 모두에 보관된 불변 베이스 이미지를 기준으로 변경된 블록만 전송하며, 별도의 플래그가 필요 없습니다. 그 베이스를 직접 지정하려면 --delta-base <guid>를 사용하세요.
푸시된 사본은 대상 머신에서 실행 중인 저장소가 아니라 백업 아티팩트로 존재합니다. rdc backup restore로 이를 저장소로 바꿉니다.
rdc backup restore my-app@server-1 --as my-app --machine server-1 --up특정 시점 기준의 백업이 필요하다면 청크 스토리지를 사용하세요. rdc backup snapshot my-app은 변경된 셀만 업로드하고, rdc backup restore my-app --at <snapshot>은 그중 어떤 것이든 되살립니다.
| 옵션 | 설명 |
|---|---|
<ref>(위치 인자) | 푸시할 저장소 참조 |
--to <remote> | 대상 머신 또는 클러스터 |
--to-machine <machine> | 대상 머신, 명시적으로 지정 |
--provision <provider> | 대상 머신이 존재하지 않으면 이 클라우드 프로바이더를 통해 프로비저닝 |
--checkpoint | 푸시 전에 CRIU 체크포인트 생성(rediacc.checkpoint=true 라벨이 붙은 컨테이너용). 대상은 repo up 시 자동 복원 |
--force | 기존 백업을 덮어씀 |
--bwlimit <limit> | rsync 전송의 대역폭 제한(예: 10M, 500K) |
--delta-base <guid> | 이 불변 베이스 GUID를 기준으로 변경된 블록만 전송. 생략하면 자동으로 베이스가 선택됨 |
--strategy <strategy> | 델타 베이스 사용 시의 블록 델타 전략: auto, physical, shared |
--debug | 상세 출력 활성화 |
--skip-router-restart | 작업 후 라우트 서버 재시작 건너뛰기 |
다른 머신에서 백업 풀하기
저장소를 보관 중인 머신에서 다시 가져옵니다.
rdc repo pull my-app --from server-1--up을 추가하면 같은 명령으로 마운트와 배포까지 진행합니다. 대신 청크 스토리지에서 복원하려면 rdc backup restore my-app --at <snapshot-id>를 사용하세요.
풀은 현재 마운트된 저장소를 덮어쓰는 것을 거부합니다. 먼저 언마운트한 뒤 풀을 실행하고, 그다음 rdc repo up으로 다시 올리세요. 디렉터리 기반 저장소는 예외로, 마운트된 상태 그대로 동기화됩니다.
| 옵션 | 설명 |
|---|---|
<ref>(위치 인자) | 풀할 저장소 참조 |
--from <remote> | 소스 머신 또는 클러스터 |
--from-machine <machine> | 소스 머신, 명시적으로 지정 |
--force | 기존 로컬 백업을 덮어씀 |
--up | 풀 이후 저장소를 마운트하고 배포 |
--bwlimit <limit> | rsync 전송의 대역폭 제한(예: 10M, 500K) |
--delta-base <guid> | 이 불변 베이스 GUID를 기준으로 변경된 블록만 수신 |
--strategy <strategy> | 델타 베이스 사용 시의 블록 델타 전략: auto, physical, shared |
--debug | 상세 출력 활성화 |
--skip-router-restart | 작업 후 라우트 서버 재시작 건너뛰기 |
백업 목록 보기
청크 스토리지에 있는 스냅샷을 나열합니다.
rdc backup manifests my-app각 행은 저장된 한 시점을 나타냅니다.
| 열 | 의미 |
|---|---|
Repo | 로컬 설정에서 해석된 저장소 이름(설정에 없는 저장소는 GUID로 대체) |
Snapshot | 스냅샷 ID. rdc backup restore --at이 받는 값이 바로 이것 |
Created | 스냅샷이 찍힌 UTC 시각 |
Total | 이 스냅샷이 나타내는 저장소 이미지의 크기 |
Added | 이 스냅샷이 이전 스냅샷들 위에 실제로 업로드한 바이트 수 |
Chunks | 추가된 셀의 개수 |
rdc repo push --to <machine>이 대상에 남긴 것을 보려면, 그 머신에 무엇이 있는지 물어보세요.
rdc repo list --machine server-1푸시된 사본은 자기 이름으로 나타납니다. 그 옆에 순수 GUID를 가진 두 번째 행이 있다면, 그것은 보관 중인 델타 베이스이며, 그 머신으로의 다음 푸시를 전체 전송이 아니라 증분 전송으로 만들어주는 것입니다.
rdc backup list --machine <machine>은 예약 실행이 기록하는 hot/과 cold/ 폴더를 읽으므로, 푸시가 남긴 사본에는 맞지 않는 도구이며 아무것도 보여주지 않습니다.
| 열 | 의미 |
|---|---|
Mode | hot 또는 cold. 이 항목이 속한 예약 백업 폴더 |
Name | 로컬 설정에서 해석된 저장소 이름(설정에 없는 저장소는 GUID로 대체) |
GUID | 디스크에 있는 저장소 GUID |
Size | 백업 파일의 사람이 읽기 쉬운 크기 |
Modified | 머신에 있는 파일의 UTC 타임스탬프 |
스토리지 백엔드 목록 보기는 rclone 계열과 함께 폐지되었습니다. 명령은 거부되며 대체할 이 두 가지를 알려줍니다.
보존 정책
서버가 청크 스토어 전체에 대해 저장소별 보존 정책을 강제하므로, 손으로 아무것도 지우지 않아도 오래된 스냅샷이 정리됩니다. 정책이 선언되지 않으면 모든 스냅샷이 보존됩니다.
# 지금 강제되고 있는 정책.
rdc backup retention my-app
# 롤링 윈도우를 유지한다: 일간 7, 주간 4, 월간 6.
rdc backup retention set my-app --keep-daily 7 --keep-weekly 4 --keep-monthly 6
# 모든 것을 보존하는 상태로 되돌린다.
rdc backup retention clear my-app| 옵션 | 설명 |
|---|---|
--keep-last <n> | 가장 최근 스냅샷을 이 개수만큼 유지 |
--keep-hourly <n> | 이 시간 수만큼, 각 시간의 최신 스냅샷을 유지 |
--keep-daily <n> | 이 일수만큼, 각 일의 최신 스냅샷을 유지 |
--keep-weekly <n> | 이 주 수만큼, 각 주의 최신 스냅샷을 유지 |
--keep-monthly <n> | 이 월 수만큼, 각 월의 최신 스냅샷을 유지 |
--keep-yearly <n> | 이 연 수만큼, 각 연의 최신 스냅샷을 유지 |
규칙을 최소 하나는 지정하세요. 규칙 없이 set을 실행하면 “아무것도 보존하지 않음”으로 취급되지 않고 거부됩니다. 정책을 비우는 것은 clear의 역할이기 때문입니다.
복원
rdc backup restore는 백업을 실제 저장소로 바꾸는 명령이며, 두 경로 모두에 같은 동사를 사용합니다. 다른 점은 무엇을 대상으로 지정하느냐입니다.
# 청크 스토리지에서의 특정 시점.
rdc backup restore my-app --as my-app-yesterday --at <snapshot-id> --up
# 푸시가 머신에 남긴 아티팩트.
rdc backup restore my-app@server-1 --as my-app --machine server-1 --up--at은 rdc backup manifests가 알려주는 스냅샷 ID나, 2026-08-14T12:00:00Z와 같은 RFC 3339 시각을 받습니다. 시각을 지정하면 그 시점 또는 그 이전 중 가장 최신 스냅샷으로 해석됩니다. 그 이전에 스냅샷이 없는 시각을 지정하면 앞으로 반올림되는 대신 거부됩니다.
--as로 새 이름 아래 복원하면 아무것도 덮어쓰지 않으므로, 운영 중인 머신에서도 복원 드릴을 안전하게 실행할 수 있습니다. 이미 존재하는 이름으로 복원하는 것은 거부됩니다.
| 옵션 | 설명 |
|---|---|
<artifact-ref>(위치 인자) | 복원할 대상. 청크 스토어 스냅샷은 repo, 머신 위의 아티팩트는 repo@place |
--as <name> | 복원된 저장소의 이름(기본값은 아티팩트 이름) |
-m, --machine <machine> | 복원할 머신 |
--datastore <name> | 이 이름의 데이터스토어로 복원(연결된 머신이 이를 호스팅) |
--at <time> | 특정 시점을 복원: 스냅샷 ID 또는 RFC 3339 시각 |
--up | 전송 후 복원된 저장소를 배포 |
--health-window <seconds> | 배포된 저장소의 상태를 관찰할 시간 |
--health-timeout <seconds> | 정상 상태가 될 때까지 기다릴 시간 |
-y, --yes | 확인 건너뛰기 |
--debug | 상세 출력 활성화 |
저장소를 복원하려면 설정에 있는 LUKS 자격 증명이 필요합니다. config storage를 활성화했다면 이 자격 증명은 새 머신에서도 설정과 함께 돌아옵니다. 활성화하지 않았다면, 머신 고장이 함께 앗아가지 않을 곳에 설정 사본을 보관해두세요.
머신별로 복원을 검증하기
한 번도 왕복해본 적 없는 머신은 업로드가 아무리 순조로워 보여도 백업된 것이 아닙니다. 업로드와 복원은 실패하는 이유가 서로 다르며, 후자의 종류는 실제로 시도했을 때만 드러납니다.
백업에 의존하기 전에, 머신마다 한 번씩 이렇게 해보세요.
- 스냅샷을 찍는다:
rdc backup snapshot my-app. - 기록되었는지 확인한다:
rdc backup manifests my-app. - 일회용 이름으로 복원한다:
rdc backup restore my-app --as my-app-drill --at <snapshot-id>. - 복원된 저장소를 원본과 비교하고,
rdc repo delete my-app-drill --yes로 드릴 사본을 삭제한다.
이 절차는 실제 운영 중인 저장소를 전혀 건드리지 않으므로, 트래픽을 처리 중인 머신에서도 안전합니다. 이전 백업 체계에서 넘어오는 중이라면, 그 머신에서 이 과정이 적어도 한 번 통과할 때까지는 이전 체계도 계속 돌려두세요. 백업 경로 두 개는 저장 공간 비용이 들지만, 검증되지 않은 경로 하나는 데이터 자체를 잃는 비용이 듭니다.
저장소를 한 번에 하나씩 동기화하기
푸시와 풀은 ref(name, name:tag, name@machine 중 하나)로 지정한 단일 저장소에 대해 동작합니다. “모든 저장소를 한 번에”라는 형태는 없습니다. 저장소마다 명령을 한 번씩 실행하세요.
포크와 머신을 함께 지정한 ref도 단순한 이름과 똑같이 동작합니다.
rdc repo push shop:nightly@server-1 --to server-2
rdc repo pull shop:nightly@server-1 --from server-2전체 옵션 목록은 다른 머신으로 백업 푸시하기와 다른 머신에서 백업 풀하기에 있습니다.
예약 백업
Rediacc는 이름이 지정된 백업 전략을 사용합니다. 각 전략은 일정, 백업 모드, 선택적 대역폭 제한, 파일 필터를 정의합니다. 전략 이름을 머신에 바인딩해서 어디서 어떤 백업이 실행될지 제어합니다.
백업 모드
| 모드 | 동작 | 다운타임 |
|---|---|---|
hot | 서비스가 계속 실행되는 동안 저장소 이미지를 동결(크래시 일관성) | 없음 |
cold | 서비스 정지, 스냅샷 촬영, 서비스 재시작, 스냅샷 업로드(애플리케이션 일관성) | 저장소별 정지+시작 윈도우, 저장소 간 병렬화. 아래 “콜드 백업 다운타임 예측” 참조. |
크래시 일관성 스냅샷이 허용되는 서비스에는 hot을 사용하세요. 보장된 일관성이 필요하고 짧은 재시작을 감수할 수 있다면 cold를 사용하세요.
콜드 백업의 시맨틱스
콜드 백업은 포함된 저장소마다 세 단계로 실행됩니다: 정지 → 스냅샷 → 시작. 보장의 경계가 어디까지인지 알면 부분적인 실패를 일찍 잡아낼 수 있습니다.
콜드 백업이 보장하는 것:
- 스냅샷 전에, 포함된 각 저장소에서 실행 중인 모든 컨테이너가 Rediaccfile의
down()훅을 통해 정상적으로 정지되고, 저장소별 Docker 데몬이 정지됩니다. 따라서 스냅샷은 단순한 크래시 일관성이 아니라 애플리케이션 일관성을 갖습니다. - 스냅샷 이전에 실행 중이던 컨테이너 ID 집합은
/var/run/rediacc/cold-backup-<guid>.running.json사이드카에 저장됩니다. 이것이 “작업이 끝났을 때 다시 실행되어 있어야 할 목록”의 근거입니다. - 스냅샷 이후, 저장소의 Rediaccfile
up()훅이 호출되어 전체 compose 스택이 복구됩니다. - 실행별 상태 사이드카
/var/run/rediacc/cold-backup-<guid>.status.json에 각 시도의 단계, 결과, 오류가 기록됩니다.
콜드 백업이 보장하지 않는 것:
up()은 최선의 노력일 뿐입니다. 콜드 백업이 통제할 수 없는 이유로 실패할 수 있습니다(depends_on: service_healthy조건이 계속 대기 중이거나, compose 파일 구문 오류, 이미지를 받아오는 도중 일시적인 네트워크 장애 등). 실패하면 콜드 백업은 오류 수준으로 로그를 남기고, 상태 사이드카를 기록한 뒤 다음 저장소로 넘어갑니다.up()이 실패하면 폴백 직접 재시작이 개입합니다. 실행 사이드카를 읽어서 기록된 각 컨테이너 ID를 compose 없이 Docker API를 통해 직접 재시작합니다. compose 흐름에 문제가 있어도, Rediaccfile 훅을 다시 실행하지 않고 서비스를 되살립니다.- 일부 컨테이너 ID에 대해 폴백마저 실패하면(예: Docker 데몬 자체가 다운된 경우), 사이드카는 그대로 남아 라우터 watchdog이 매 틱마다 재시도할 수 있게 합니다.
Watchdog 복구: 매 틱마다 watchdog은 실행 사이드카가 있는지 확인합니다. 거기 나열된 컨테이너 ID 중 현재 멈춰 있는 것은, 컨테이너에 저장된 restart_policy와 관계없이 재시작됩니다. 덕분에 restart: on-failure(Docker가 정상 정지 이후에는 재시작하지 않는 정책)로 설정된 서비스도 콜드 백업 이후 다시 돌아옵니다. 나열된 모든 컨테이너가 실행 중이 되면 사이드카는 삭제됩니다.
오퍼레이터가 실패를 감지하는 방법:
rdc machine status <machine> --containers로 실행 상태를 확인하세요. 예상되는 목록과 비교하세요.- 머신에 있는
/var/run/rediacc/cold-backup-<guid>.status.json을 확인하세요.rdc term connect <repo> -c "cat /var/run/rediacc/cold-backup-$GUID.status.json"로 살펴볼 수 있습니다.success: false와 오래된startedAt은 마지막 백업이 깔끔하게 끝나지 않았음을 뜻합니다. - renet 백업 실행의 로그(
journalctl -u renet-*또는 직접 실행한rdc backup schedule)는Cold backup: post-snapshot restart summary total=N compose_ok=N fallback_ok=N failed=N failed_repos=[...]형태의 최종 요약 줄을 출력합니다. 비어 있지 않은failed_repos가 grep 대상입니다.
콜드 백업 다운타임 예측
각 저장소는 자신의 down() + up() 윈도우 동안에만 다운됩니다. 워밍업된 호스트에서는 보통 다음과 같습니다.
| 저장소 형태 | 전형적인 정지+시작 |
|---|---|
| 소형(컨테이너 1-2개, DB 없음) | 5-15초 |
| 중형(웹 앱 + 캐시) | 20-45초 |
| 대형(DB + 큐 + 메일) | 60-120초 |
동결 단계는 저장소 이미지의 카피온라이트 reflink입니다. 메타데이터일 뿐이므로 저장소가 1 GB든 100 GB든 걸리는 시간은 같으며, 실측에서는 밀리초 단위 해상도에서 잡히지도 않았습니다. 한 저장소가 다른 저장소의 동결 때문에 계속 멈춰 있지는 않습니다. 업로드는 동결된 사본에 대해 실행되며, 그동안 모든 저장소는 이미 다시 올라와 있습니다.
**전체 실행의 총 소요 시간(wall-clock)**은 동시에 재시작하는 저장소 수에 따라 결정됩니다. renet은 이 값을 호스트로부터 도출합니다.
concurrency = min(repoCount, max(2, NumCPU/2), 8)예시:
| 호스트 | 저장소 | 동시성 | Wall-clock 재시작 시간 |
|---|---|---|---|
| 4 CPU VM | 5개 저장소, 평균 30초 | 2 | ~75초 |
| 16 CPU 서버 | 10개 저장소, 평균 40초 | 8 | ~80초 |
| 64 CPU 플릿 노드 | 50개 저장소, 평균 40초 | 8 | ~4분 |
환경변수를 통한 재정의: 백업 서비스 환경에서 REDIACC_COLD_BACKUP_CONCURRENCY=N을 설정하면(보통 systemd 드롭인 방식) 값을 고정할 수 있습니다. =1은 엄격하게 순차적인 재시작을 강제하며, 특정 저장소의 up() 훅에서 발생하는 크래시 루프를 디버깅할 때 유용합니다.
지연에 민감한 저장소(공개 웹 앱, 메일)를 운영 중이라면, 그 다운타임은 전체 실행 길이가 아니라 자신의 정지+시작(보통 30-90초)으로 제한됩니다. 저장소는 발견된 순서대로 동시성 슬롯에 배치되며, 우선순위 큐는 없습니다. 더 세밀한 스케줄링이 필요하다면, 무거운 저장소를 --include로 한정한 별도의 전략으로 분리하세요.
장시간 실행되는 백업과 겹치는 일정
자신의 일정 간격보다 오래 걸리는 콜드 백업(예: 500 GB 저장소의 첫 시드는 적당한 회선에서 정당하게 24시간 이상 걸릴 수 있고, 그동안 야간 타이머가 다시 발동함)은 두 번째 실행을 큐에 넣거나 시작하지 않습니다. systemd의 Type=oneshot 유닛은 단일 인스턴스입니다. 타이머가 발동했을 때 서비스가 이미 activating 상태라면, systemd는 시작을 기존 작업에 병합합니다. 새 프로세스는 시작되지 않으며, 실행이 나중을 위해 큐에 들어가지도 않습니다.
구체적으로, 월요일 03:00 UTC에 시작해서 목요일 정오에 끝나는 실행을 봅시다.
| 요일 | 03:00 UTC 발동 | 결과 |
|---|---|---|
| 월요일 | 첫 발동 | 실행 시작 |
| 화요일 | 두 번째 발동 | 조용히 폐기됨(이전 실행이 아직 진행 중) |
| 수요일 | 세 번째 발동 | 조용히 폐기됨(이전 실행이 아직 진행 중) |
| 목요일 | 실행이 정오에 종료 | 따라잡기 없음. 다음 실행은 금요일 03:00 UTC |
타이머의 Persistent=true 지시자는 이 발동들을 구제하지 않습니다. Persistent=true는 타이머 자체가 비활성 상태였기 때문에(시스템 종료, 타이머 비활성화) 놓친 발동을 재생하는 것입니다. 서비스가 바빠서 폐기된 발동은 그냥 사라집니다.
이 기본값은 의도된 것입니다. 같은 데이터스토어에 대해 두 개의 콜드 백업을 동시에 실행하면 동결 경로, 업로드, /var/run/rediacc/cold-backup-<guid>.status.json의 저장소별 사이드카에서 서로 충돌합니다. 실행 중인 인스턴스 뒤에서 기다리는 편이, 같은 데이터를 양쪽에서 두들기는 것보다 낫습니다. 데이터스토어 잠금이 이를 강제합니다. 두 번째 콜드 실행은 잠금이 사용 중임을 발견하고, 아무것도 멈추지 않은 채 즉시 거부됩니다.
모니터링에 대한 함의. 멈춰버린 백업(예: 네트워크 블랙홀에 걸려 멈춘 업로드)은 이후의 모든 타이머 발동을 조용히 무시합니다. 스케줄러는 어떤 경고도 보내지 않습니다. systemctl show <unit> -p ActiveEnterTimestamp를 지켜보세요. 서비스가 예상 실행 시간보다 오래 activating 상태라면(예: 야간 타이머에서 48시간 이상), 조사해보세요.
모든 예약 발동이 실행되어야 한다면, 타이머를 OnCalendar=<cron>에서 OnUnitInactiveSec=<간격>으로 전환하세요. 이는 고정된 wall-clock 일정이 아니라 이전 실행이 끝난 뒤 N시간 후에 발동하므로, 실행이 길어져도 발동이 폐기되지 않습니다. 다음 실행이 뒤로 밀릴 뿐입니다. 트레이드오프는 일정의 표류입니다. 03:00 야간 실행이 “마지막 실행이 끝난 지 24시간 후”가 됩니다.
스냅샷, 중단, 그리고 풀 공간
모든 푸시는 순간적인 데이터스토어 스냅샷에서 동작하므로, 저장소가 계속 기록 중이어도 업로드되는 데이터는 일관성을 유지합니다. 백업이 실행되는 동안, 그 스냅샷은 라이브 저장소와 공유하는 모든 블록을 계속 참조하므로, 사이클이 끝나 스냅샷이 삭제될 때까지 삭제와 트림으로 해제되는 풀 공간은 줄어듭니다. 스토리지 상태 보고서에서 백업 스냅샷이 현재 얼마만큼의 공간을 붙잡고 있는지 확인할 수 있습니다.
중단은 안전합니다. 서비스를 정지하면(또는 머신을 재부팅하면) 백업은 전송을 중단하고 종료 전에 자신의 스냅샷을 삭제합니다. 이미 저장된 셀은 다시 업로드되지 않으므로, 다음 예약 실행이 중단된 지점부터 이어받습니다. 프로세스가 정리할 틈도 없이 강제 종료된 경우(전원 손실 등), 고아가 된 스냅샷은 스토리지 관리자에 의해 몇 분 안에 자동으로 감지되어 제거됩니다.
전략 정의하기
기본 구성은 두 가지 전략의 조합입니다. 모든 저장소를 포착하는 빠른 매시간 핫 스트림과, 애플리케이션 일관성 스냅샷을 위해 컨테이너를 정지시키는 느린 주간 콜드 스트림입니다. 둘 다 같은 청크 스토어에 기록되며, 공유하는 블록은 스트림마다가 아니라 한 번만 저장됩니다.
rdc backup strategy set hourly-hot \
--destination rediacc \
--cron "0 * * * *" \
--mode hot \
--bwlimit 20M \
--enablerdc backup strategy set weekly-cold \
--destination rediacc \
--cron "15 3 * * 0" \
--mode cold \
--include shop --include mail \
--enable--destination <name>은 전략 내부의 대상에 이름을 붙입니다. 이는 직접 고르는 라벨이며, 청크 스토어를 나타냅니다. --include는 백업할 저장소를 나열하며, 반복할수록 추가됩니다. 생략하면 전략은 데이터스토어의 모든 저장소를 대상으로 합니다. 이름은 로컬 설정의 저장소 이름(:tag 제외)과 일치해야 합니다.
--exclude는 청크 스토어 대상에서는 조용히 무시되는 대신 거부됩니다. 기반이 되는 backup snapshot이 저장소를 이름으로 선택하는 방식이며 자체 제외 기능이 없기 때문입니다. 이를 존중한다면 제외하려던 저장소까지 백업해버리는 셈이 됩니다. 대신 --include로 전략의 범위를 좁히세요. 그러면 예약 실행이 무엇을 다루는지가 추측이 아니라 명시된 값이 됩니다.
| 옵션 | 설명 |
|---|---|
<strategy>(위치 인자) | 전략 이름(머신 바인딩에 사용) |
--destination <name> | 전략 내부의 대상 이름. 기본값은 청크 스토어 |
--storage <name> | 폐지된 rclone 대상 종류를 옵트인. 이를 사용하는 스케줄은 배포할 수 없음 |
--cron <expression> | cron 표현식(예: "0 2 * * *"는 매일 오전 2시) |
--mode <hot|cold> | 백업 모드 |
--bwlimit <limit> | 업로드 대역폭 제한(예: 10M) |
--include <repos> | 이 전략이 다루는 저장소(반복 가능) |
--exclude <repos> | 건너뛸 저장소(반복 가능). 청크 스토어 대상에서는 거부됨 |
--folder <path> | rclone 버킷 내 하위 폴더. 청크 스토어 대상에서는 거부됨 |
--enable / --disable | 전략 활성화 또는 비활성화 |
전략 보기
rdc backup strategy list
rdc backup strategy show weekly-cold전략 제거
rdc backup strategy remove weekly-cold머신에 전략 바인딩하기
어떤 머신에도 바인딩되지 않은 전략은 절대 배포되지 않습니다. 하나 이상을 머신에 바인딩하세요.
rdc backup strategy bind hourly-hot --machine hostinger
rdc backup strategy bind weekly-cold --machine hostinger
rdc backup strategy unbind weekly-cold --machine hostinger바인딩은 설정 안에 머신에 대한 목록으로 기록되며, rdc backup schedule이 어떤 유닛을 배포할지 판단할 때 이를 읽습니다.
{
"machines": {
"hostinger": {
"backupStrategies": ["hourly-hot", "weekly-cold"]
}
}
}바인딩은 로컬 설정에서만 이루어집니다. 전략을 정의하고 머신에 바인딩해도 머신 자체는 건드리지 않습니다. systemd 타이머를 배포하려면
rdc backup schedule -m <machine>을 실행하세요(머신에 일정 배포하기 참조). 전략이나 바인딩을 변경한 뒤에는 다시 실행하세요.
핫과 콜드 선택하기, 그리고 저장소별 필터링
한눈에 보는 핫 대 콜드
| 핫 | 콜드 | |
|---|---|---|
| 일관성 | 크래시 일관성(실행 중에 이미지 동결) | 애플리케이션 일관성(정지 → 동결 → 시작) |
| 다운타임 | 없음 | 저장소별 정지+시작 윈도우(보통 5-120초) |
| 적합한 빈도 | 높음(예: 매시간) | 낮음(예: 매일 또는 매주) |
| 전형적인 용도 | 고빈도 안전망 | 예약된 일관성 보장 백업 |
핫은 고빈도 실행에 적합한 기본값입니다. 스냅샷을 찍는 동안에도 서비스는 계속 실행되므로, 앱에는 다운타임이 전혀 없습니다. 스냅샷은 크래시 일관성을 가지며, 이는 비정상 종료 직후 얻게 될 상태와 같습니다. 대부분의 최신 데이터베이스와 메시지 큐에는 이것으로 충분합니다.
콜드는 보장된 애플리케이션 일관성 스냅샷이 필요하고 저장소별로 짧은 재시작을 감수할 수 있을 때 적합합니다. 서비스는 스냅샷 전에 정지되고 업로드가 시작되기 전에 재시작되므로, 느리거나 실패한 업로드가 다운타임 윈도우를 늘리는 일이 없습니다. 전체 보장 모델은 콜드 백업의 시맨틱스를 참조하세요.
두 모드 모두 같은 청크 스토어에 기록됩니다. 모드가 좌우하는 것은 이미지가 동결되는 동안 저장소를 어떻게 다루느냐이지, 데이터가 어디에 놓이느냐가 아닙니다. 매시간 핫 일정과 매주 콜드 일정 양쪽에 모두 포함된 저장소는 공유하는 셀을 두 번이 아니라 한 번만 저장합니다.
전략별 저장소 범위 지정
--include가 없는 전략은 데이터스토어의 모든 저장소를 대상으로 합니다. --include를 반복하면 지정한 이름의 저장소로만 범위가 좁혀지며, 로컬 설정의 저장소 이름(:tag 제외)과 일치시킵니다.
# 핫 전략: 모든 것을 매시간 백업
rdc backup strategy set hourly-hot \
--destination rediacc \
--cron "0 * * * *" \
--mode hot \
--bwlimit 6M \
--enable
# 콜드 전략: 매주, 정지가 필요한 저장소만
rdc backup strategy set weekly-cold \
--destination rediacc \
--cron "15 3 * * 0" \
--mode cold \
--include shop --include mail \
--enable고빈도 핫 전략에서 저장소를 제외해야 할 때
다음의 경우, 전부 포함시키는 대신 고빈도 실행에 넣을 저장소를 직접 지정하세요.
- 저장소가 크고, 볼륨 안에 이미 있는 소스 데이터로부터 완전히 재생성 가능해서, 매시간 백업이 의미 있는 복구 가치를 더하지 못한 채 대역폭만 소비하는 경우.
- 백업 실행이, 사용 가능한 업로드 속도로는 자신의 일정 간격을 넘어서는 경우.
예시. analytics-demo 저장소는 같은 볼륨 안에 저장된 원본 CSV 덤프로부터 완전히 재구성할 수 있는 약 114 GB의 파생 Postgres 테이블을 담고 있습니다. 6 MB/s 업로드 제한에서는 이 저장소의 첫 스냅샷에만 5시간 이상이 걸립니다. 이를 매시간 실행하면 다음 실행이 발동할 때 이전 실행이 아직 진행 중이며, 그 이후의 모든 발동이 조용히 폐기됩니다(장시간 실행되는 백업과 겹치는 일정 참조). hourly-hot에는 다른 저장소만 나열하고 analytics-demo를 weekly-cold에 맡기면, 전혀 백업되지 않는 대신 주 1회 백업되게 됩니다.
데이터가 순수하게 재생성 가능하다면, 애초에 백업이 필요한지부터 검토하세요. 대안으로 원본 소스 입력(이 예시에서는 CSV 덤프)만 백업하고 파생 사본은 완전히 건너뛸 수도 있습니다. 소스 입력의 주간 콜드 백업이 훨씬 작으면서도 복구에는 충분합니다.
두 전략 모두가 다루는 저장소는 매시간의 크래시 일관성 스냅샷과 매주의 애플리케이션 일관성 스냅샷을 함께 얻습니다. rdc backup manifests <repo>는 이들을 한데 모아 보여주며, 공유되는 셀은 한 번만 저장됩니다.
백업 작업
머신에 일정 배포하기
바인딩된 전략을 systemd 타이머로 머신에 푸시합니다.
rdc backup schedule -m server-1
rdc backup schedule -m server-1 --dry-run배포는 상태 조정자입니다. 머신 위의 현재 유닛 파일과 systemd 상태를 읽고, 설정이 만들어낼 결과와 비교한 뒤(파일별 SHA-256), 내용이 실제로 바뀐 유닛에만 손을 댑니다. 설정 변경 없이 재실행하면 아무 일도 하지 않습니다. 쓰기 없음, daemon-reload 없음, 타이머 변동 없음입니다.
--dry-run은 머신을 건드리지 않은 채 각 전략의 계획(created, updated (service, timer, env), unchanged, removed)을 출력합니다. --debug와 함께 쓰면 생성된 유닛 본문도 자격 증명을 가린 채로 출력됩니다. 청크 스토어 유닛은 애초에 자격 증명을 담지 않습니다. 머신은 자체 서명된 저장소 라이선스로 인증하고 서버가 짧게 유효한 권한을 돌려주므로, 유닛 파일에 민감한 정보가 기록될 일이 없습니다.
업데이트나 제거하려는 전략의 백업이 지금 실행 중이라면, 배포는 즉시 실패하며 취소하거나 --force를 넘기라는 힌트를 보여줍니다. --force를 쓰면 실행 중인 인스턴스는 메모리 상의 유닛을 그대로 유지한 채, 새 설정은 다음 타이머 틱에서 적용되므로 실행 중인 백업이 강제 종료되는 일은 없습니다.
--reset-failed는 옵트인입니다. 전달하면 배포 성공 후 손댄 서비스들의 systemd failed 상태를 지웁니다. 기본값은 비활성이며, 이는 이전 실패 신호가 알림에서 계속 보이도록 하기 위함입니다.
지금 바로 백업 실행하기
타이머를 기다리지 않고 즉시 백업을 시작합니다. 타이머가 배포되어 있지 않아도 systemd-run을 이용한 즉석 실행이 가능합니다.
rdc backup run -m server-1
rdc backup run weekly-cold -m server-1백업 상태 보기
백업 타이머의 현재 상태와 최근 작업 결과를 표시합니다.
rdc backup status -m server-1
rdc backup status hourly-hot -m server-1실행 중인 백업 취소하기
rdc backup cancel -m server-1
rdc backup cancel weekly-cold -m server-1저장소 마이그레이션
저장소를 한 머신에서 다른 머신으로 이동합니다.
rdc repo migrate my-app@server-1 --to server-2| 옵션 | 설명 |
|---|---|
<ref>(위치 인자) | 마이그레이션할 저장소 참조. @machine 부분이 소스를 지정 |
--to <place> | 대상 머신 또는 클러스터 |
--provision <provider> | 이 클라우드 프로바이더를 통해 대상 머신을 자동 프로비저닝(예: hetzner, linode) |
--checkpoint | 마이그레이션 전에 CRIU 체크포인트를 생성해서 프로세스 메모리도 함께 이동 |
--delta-base <guid> | 전환 시 델타에 사용할 불변 베이스 GUID. 기본값은 첫 단계의 베이스 |
--strategy <strategy> | 전환 시 블록 델타 전략: auto, physical, shared |
--skip-dns | 마이그레이션 후 DNS 레코드 업데이트 건너뛰기 |
--keep-source | 성공적인 이동 이후에도 소스 이미지를 유지 |
--bwlimit <limit> | 전송 대역폭 제한(예: 50M) |
마이그레이션은 rsync를 통해 두 단계에 걸쳐 암호화된 저장소 데이터를 전송합니다. 저장소가 계속 실행되는 동안의 대량 전송과, 그 뒤에 이어지는 델타를 위한 짧은 정지입니다. 마이그레이션은 저장소를 이동시키므로, 이동이 성공하면 소스 이미지는 삭제됩니다. 이를 보존하려면 --keep-source를 넘기세요. 이것이 repo migrate와 repo push의 차이입니다. 푸시는 소스를 실행 중인 상태 그대로 건드리지 않고 남겨둡니다.
폐지 이전에 작성된 아카이브 읽기
rdc storage는 rclone 계열 중 남은 부분이며, 읽기 전용입니다. 더 이상 백업 대상이 될 수는 없지만, 그 방식으로 작성된 아카이브에는 여전히 접근할 수 있습니다.
# 이미 rclone용으로 설정해둔 리모트를 등록한다.
rdc storage import rclone.conf
rdc storage list
# 안에 무엇이 있는지 본다. 이는 여러분의 PATH에 있는 rclone을 실행한다.
rdc storage browse my-storageimport는 rclone 설정 파일을 읽어 그 리모트들을 여러분의 설정에 기록합니다. 지원되는 종류는 S3, B2, Google Drive, OneDrive, Mega, Dropbox, Box, Azure Blob, Swift입니다.
browse는 PATH에 rclone이 있어야 합니다. 이는 여러분이 명령을 입력하는 머신에 설치된 rclone을 실행합니다. 더 이상 번들 사본은 없습니다. 없다면 그렇게 알려주고 그 이상 아무것도 하지 않습니다.
스토리지 백엔드로의 푸시, 풀, 목록 보기, 복원은 폐지되었으며, 각각 거부된 뒤 대체 명령을 알려줍니다.
모범 사례
- 중요한 데이터의 애플리케이션 일관성 사본을 위해 매일 콜드 스냅샷을 예약하세요
- 다운타임이 전혀 없어야 하는 고빈도 실행에는 핫 스냅샷을 사용하세요
- 정기적으로 복원을 테스트하세요.
rdc backup restore --as <new-name>은 아무것도 덮어쓰지 않으므로 운영 중인 머신에서도 드릴은 안전합니다 - 손으로 정리하는 대신 보존 정책을 설정해서, 유지할 기간을 명시적으로 기록해두세요
- 직접 관리하는 하드웨어에 사본을 두고 싶다면 스냅샷과 함께 머신 간 사본도 유지하세요
- 자격 증명을 안전하게 보관하세요. 백업은 암호화되어 있지만 복원하려면 LUKS 자격 증명이 필요합니다