Restic으로 데이터 복구

Restic으로 데이터를 복구하는 방법

이 기사 시리즈의 첫 번째 부분에서는 Restic을 사용하여 컨테이너 컨텍스트에서 백업을 생성하는 것이 얼마나 쉽고 빠른지 설명했습니다. 그러나 데이터 백업은 그 자체로 끝이 아니라 백업된 시스템에 장애가 발생할 경우 데이터를 복원하는 역할을 합니다. 이 기사는 Docker의 경우 이전 백업만큼 간단한 이 측면을 정확히 다룹니다. 마지막으로 저장 공간이 부족할 경우 백업 제거도 논의됩니다.

이 부분은 Restic이 이미 설치되었고 스냅샷이 Restic으로 백업되었다고 가정합니다. 추가 설치 지침은 이 시리즈의 첫 번째 부분에서 찾을 수 있습니다.

이 기사의 Restic 명령

다음 명령은 이 문서에서 특히 중요합니다.

• snapshots 기존 백업을 보려면
• restore 파일 및 디렉토리도 복원
• forget 퓨즈를 제거합니다.

참고로 Restic은 모든 명령 수준에서 다음을 사용하여 제공합니다. --help-argument 허용되는 인수에 대한 추가 정보, 예: B. restic --help 또는
restic backup --help. 파일 권한 문제를 방지하기 위해 이 게시물에서는 다음을 사용합니다. root-당 오른쪽 sudo su 일했다.

백업에서 복원

restic 리포지토리에서 백업이 성공적으로 생성되면 이제 백업의 실제 목적인 백업된 데이터 복원이 해결됩니다. 컨테이너가 여전히 작동 중인 경우 콘텐츠를 볼륨에서 정상적으로 복원할 수 있습니다. 그 효과를 보여주기 위해 인위적 중단 이벤트로 Docker 볼륨의 콘텐츠가 지워집니다.

rm /var/lib/docker/volumes/nginxData/_data/

지금 브라우저에서 페이지 아래에 있는 경우 http://localhost:8080 호출되면 오류 메시지가 나타납니다. 이제 복원이 이루어질 수 있습니다. 그러나 복원의 경우 열린 파일과 관련하여 백업과 동일한 규칙이 적용됩니다. 이는 복구를 위해 컨테이너 간의 논리적 또는 기술적 종속성도 따라야 함을 의미합니다.

1. 용기를 멈추다
2. 볼륨을 복원합니다.
3. 컨테이너를 시작합니다.

복원하기 전에 이전에 사용된 Minio 서버도 시작되었는지 확인해야 합니다. 최종적으로 테스트 목적으로 이 시리즈의 첫 번째 부분에서 백업을 유지하기 때문입니다.

docker start minio

복원할 백업을 선택하는 가장 안정적인 방법은 원하는 스냅샷 ID를 전달하는 것입니다. 이건 끝날 수 있어 restic snapshots 또는 출력에서 restic backup 결정하다. 저장된 경로는 절대경로(즉 from / downs)이므로, --target– 옵션을 /로 설정합니다. 여기에 전체 경로를 입력하시겠습니까? /var/lib/docker/volumes/nginxData/_data/index.html 전체 디렉토리 트리를 재귀적으로 _data/디렉토리가 연결되어 있습니다. 먼저 어떤 스냅샷을 사용할 수 있는지 명확히 해야 합니다.

restic snapshots
repository 00d7d2bb opened successfully, password is correct
ID Time Host Tags Paths
--------------------------------------------------------------------------------
----------------------------
aed06d2f 2019-04-05 13:00:01 MY-HOST-1337 Komplettsicherung KW15
/var/lib/docker/volumes/nginxData/_data
d7e6092d 2019-04-12 15:52:32 MY-HOST-1337 Komplettsicherung KW16
/var/lib/docker/volumes/nginxData/_data
--------------------------------------------------------------------------------

이제 목록의 ID d7e6092d가 구체적인 복구에 사용됩니다. 볼륨 내용을 복원하는 명령은 다음과 같습니다.

docker stop prod-nginx
prod-nginx
restic restore d7e6092d --target /
docker start prod-nginx
prod-nginx

또는 명령이 여전히 존재합니다. restic restore latest, 최신 스냅샷을 사용하여 복원합니다. 그러나 이 경우는 “최신” 태그가 있는 컨테이너 이미지와 매우 유사하기 때문에 권장되지 않습니다. 서로 다른 볼륨의 서로 다른 백업이 있는 경우 실제로 가장 최근에 백업된 스냅샷에 어떤 데이터가 있는지 명확하지 않습니다. 원칙적으로 검색 경로를 지정할 가능성이 있지만 이는 단순 사용 원칙에 위배됩니다.

프로덕션 데이터에는 일반적으로 특별한 주의가 필요하므로 복구 시 인수를 사용하는 것이 좋습니다. --verify 주다:

restic restore d7e6092d --target / --verify

이는 추가적인 보안 조치로 이해되어야 합니다. 여기서 Restic은 복원된 데이터를 백업 저장소의 데이터와 비교합니다.

퓨즈 제거

이 지식을 통해 백업 및 복구 영역에서 작업하는 것이 유용할 수 있습니다. 그러나 자신의 데이터 캐리어에 저장하면 저장 공간이 빠르게 부족해지는 경험이 있습니다. 반면에 클라우드에 백업하는 경우 스토리지 접근 방식과 계약에 따라 무한한 양의 스토리지 공간이 있을 수 있습니다. 그런 다음 스냅샷 목록을 관리 가능한 크기로 줄이는 것이 확실히 바람직합니다.

이러한 경우 Restic은 다음과 같은 기능도 제공합니다. restic forget. 특이점에 대해 앞서 restic forget Restic의 작동 방식을 미리 살펴봅니다. 속도를 제공할 수 있도록 Restic은 암호화 외에도 참조 및 해시를 집중적으로 사용합니다. 확보할 부분의 해시는 각 전송 전에 계산됩니다. 해시가 이 부분이 이미 존재한다고 표시하면 더 이상 전송되지 않고 참조만 됩니다. 이 중복 제거는 시간과 공간을 절약합니다. 호기심 많은 분을 위한 명령: 명령 restic stats --mode raw-data 백업 리포지토리가 차지하는 실제 메모리 사용량을 보여줍니다.

백업 리포지토리에서 스냅샷을 제거하면 개요에서 사라지지만 여전히 하드 디스크 공간을 차지합니다. 참조되지 않은 데이터를 검색하는 데 시간이 걸리기 때문입니다. Restic은 실제로 공간을 확보하기 위한 두 가지 대안을 제공합니다. 자신의 명령으로 restic prune 또는 매개변수로 restic forget --prune.

백업을 제거하는 가장 쉬운 방법은 스냅샷 ID를 사용하는 것입니다. 나중에 논의 될 작업 거부가 없기 때문입니다. 예를 들어 이 명령은 세 개의 명명된 스냅샷을 제거하고 디스크의 데이터를 해제합니다.

restic forget 40dc1520 79766175 590c8fc8 –prune

정책

자동 백업을 설정한 경우 일반적인 절차는 오래된 백업을 자동으로 회전하는 것입니다(예: B. 시간 간격 동안 특정 수의 백업만 유지하려는 경우). 그러면 스냅샷 ID를 사용하는 절차가 다소 비현실적으로 보일 수 있습니다. 스냅샷 ID 사용에 대한 대안은 제거해서는 안 되는 기준 기반 스냅샷 선택을 제공하는 이른바 정책입니다.

실제로는 매개변수를 사용하는 것이 도움이 됩니다. restic forget --dry-run 데이터 손실에 대한 두려움 없이 효과를 보려면 사용해 보십시오. Restic은 우발적인 데이터 손실을 방지하기 위해 많은 노력을 기울입니다. 정책 조합에 모든 스냅샷이 삭제된다고 명시되어 있으면 Restic은 이를 거부하고 다음 예와 같이 스냅샷을 전혀 삭제하지 않습니다.

restic forget --keep-last 0 --prune
repository 8460094c opened successfully, password is correct
no policy was specified, no snapshots will be removed

간단한 정책은 매개변수로 정의됩니다. --keep-last 제공되며 가장 최근에 전송된 백업 수를 유지합니다. 이 예에서는 각 경로의 마지막 3개 스냅샷을 유지합니다. 처럼

restic forget --keep-last 3 –prune

또한 보관할 스냅샷의 선택 범위를 좁힐 수 있는 대안이 많이 있습니다. 있다 --keep-hourly, 동일한 파일 경로의 여러 시간별 스냅샷을 유지합니다. 또한 매일, 매주, 매년 연락이 있습니다.

다른 시간적 매개변수에서 눈에 띄는 다른 두 가지 흥미로운 정책 매개변수가 있습니다. 하는 동안 --keep-tag 주어진 태그로 스냅샷을 유지하는 것은 다음과 같이 가능합니다. --keep-within {duration} 최신 스냅샷까지의 기간을 지정합니다. 예를 들어 이 예에서는 가장 최근 스냅샷 이전의 지난 2년, 5개월, 7일 및 3시간 동안 생성된 모든 스냅샷을 유지합니다.

restic forget --keep-within 2y5m7d3h –forget

정책 구성 요소

모든 Restic 정책을 편리하게 결합할 수 있습니다. 이는 매개변수를 반복하여 수행할 수 있습니다. 예를 들어 Restic이 각 월, 주, 일에 대한 스냅샷을 유지해야 하는 경우 다음 매개변수를 사용하여 매우 우아하게 표현할 수 있습니다.

restic forget --keep-daily 1 --keep-weekly 1 --keep-monthly 1 –prune

특히 여기에서 더 이상 논의할 수 없는 태그 목록으로 정책이 강화된 경우 여기에서 문서를 살펴볼 가치가 있습니다.

요약

Restic은 특히 속도 및 보안과 결합된 사용 용이성 측면에서 백업 및 복원의 많은 관련 측면을 훌륭하게 해결하는 강력한 도구입니다. 정책을 사용하여 스냅샷을 제거하는 것은 더 복잡한 경우 골칫거리가 될 수 있지만 항상 스냅샷 ID를 사용하는 방법이 있습니다. 말하자면 백업입니다.