Linux에서 tar를 사용하여 증분 백업 문제를 해결할 수 있는 방법을 찾고 있습니다.
테이프에 백업해야 하는 대규모 데이터 세트(약 3TB)가 있습니다. 이를 위해 LTO4 장치에서 linux tar 명령과 mt/mtx를 사용하고 있습니다.
백업은 매우 매우 느리기 때문에(다른 질문에 언급해야 할 것 같습니다) 프로덕션 중에 실행되는 것을 피하기 위해 증분 백업을 사용하는 것 외에는 선택의 여지가 없습니다.
기본적으로 다음과 같이 진행됩니다.
완전한 tar가 생성되었습니다: (레벨 0)
tar --new-volume-script=changetape.sh \ --exclude=.zfs \ --listed-incremental=file.index \ --label=full_DS01 \ -cvf /dev/nst0 \ /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlog일일 증분 tar:
mtx -f /dev/sg1 load X #(load correct tape) mt -f /dev/nst0 eod #(forward to end of data to write a new incremental tar) tar --exclude=.zfs \ --listed-incremental=file.index \ --label=incremental_DS01 \ -czvf /dev/nst0 \ /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlog타르 증가를 반복하십시오. 2와 동일한 프로세스를 사용하므로 항상 레벨 0에 나열된 증분을 사용하고 매번 조정합니다. 이는 마지막 증분 업데이트 이후 변경된 파일을 항상 백업한다는 의미입니다. (diff와 반대로 항상 전체 업데이트와 비교합니다)
질문:
몇 번의 반복 후에 증분이 실패하기 시작합니다. 즉, 백업이 실행되지만 실제로는 전체 백업을 수행하는데 모든 파일이 변경된 것으로 생각하는 것 같습니다.
이는 다른 데이터 세트에서 발생합니다.
이 문제를 어떻게 해결할 수 있나요? 이것이 어떻게 가능한지? 모든 것이 잘 돌아가는 것 같은데 모든 파일이 변경된 것 같나요?
명확하게 하기 위해:
- 데이터 세트는 읽기 전용 마운트 지점입니다.
- 폴더 구조는 전체 백업과 동일합니다.
- 상위 폴더 이름은 변경되지 않았습니다.
이 문제를 어떻게 해결할 수 있나요?
답변1
gtar의 증분 기능에는 개념적 문제가 있으며 모든 경우에 제대로 작동하지 않습니다. 2004년에 star의 증분 기능을 확인하려고 시도했을 때 gtar는 매우 일찍 실패하여 전혀 테스트할 수 없었습니다.
스타의 증분 백업을 시도해 보셨나요?
Freebsd는 zfs 백업에 star를 사용하며 Freebsd는 일부 오래된 커널 버그를 수정했기 때문에 잘 작동합니다.
gtar증분 백업에는 몇 가지 문제가 있습니다.
중요한 더 큰 메타데이터는 백업 아카이브 내부가 아니라
gtar공급업체별 옵션을 사용한 결과로 생성된 별도의 파일 에 있습니다-g. 시스템이 완전히 충돌하면 파일이 손실될 가능성이 높습니다(적어도 최신 버전에서는). 그러나 백업과 별도로 이 파일이 존재하는 것은 실제로 문제가 되지 않습니다. 실제 문제는 파일이 이름 변경을 추적할 수 없다는 것입니다.gtar의 백업 아카이브에는 이름이 바뀐 파일에 대한 정보가 포함되어 있지 않습니다. 하나의 추적에서만 새 아카이브에 언급되지 않았지만 현재 파일 시스템에 있는 파일 이름이 사라져서 삭제되었다는 가정을 허용합니다.
최상위 디렉토리의 이름이 바뀌면 gtar는 모든 내용이 포함된 전체 디렉토리 트리를 보관해야 합니다. 이로 인해 gtar 델타가 거대해지고 복구 작업 중에 대상 파일 시스템이 쉽게 오버플로될 수 있습니다.
gtar에는 증분 간 파일 유형을 변경하는 디렉토리가 아닌 파일에 문제가 있습니다.
gtar는 디렉토리 이름 변경과 이전 이름으로 새 디렉토리 생성을 처리할 수 없습니다.
따라서 2004년 9월에 star용으로 만든 gtar를 사용하여 초기 수동 테스트를 실행할 수 없었습니다.
반면 Star는 1981년 ufsdump/ufsrestore용으로 개발된 이후 35년 동안 정확하다고 평가된 기본 알고리즘을 사용합니다. Star의 증분 백업은 다음과 같이 작동합니다.
각 전체 또는 증분 덤프의 타임스탬프, 레벨 및 파일 시스템을 간단히 기록하는 덤프 날짜 파일이 있습니다.
각 tar 아카이브에는 백업 간 파일 시스템의 모든 변경 사항을 추적하는 데 필요한 모든 메타데이터가 포함되어 있습니다. 변경된 모든 파일 외에도 star는 변경된 모든 디렉터리의 파일 이름 목록과 관련 inode 번호 목록도 보관합니다. 이를 통해 언제든지 증분 백업에 대해 모든 파일 삭제 및 모든 파일 이름 변경을 추적할 수 있습니다.
star는 백업에서 파일 시스템을 복원할 때 파일 이름, 백업된 파일 시스템의 원래 inode 번호 및 추출된 파일 시스템에 사용된 새 inode 번호를 포함하는 추출된 모든 개체에 대한 항목이 포함된 데이터베이스를 생성합니다. 이를 통해 star는 두 증분 사이의 모든 변경 사항을 추적할 수 있습니다.
파일 시스템의 최상위 수준에서 디렉터리 이름을 바꿀 때 star는 해당 디렉터리 내용 내의 개별 파일이 아닌 루트 디렉터리와 이름이 변경된 디렉터리 및 해당 메타데이터만 백업하면 됩니다.
Star는 Berlios 파일 시스템에서 10년 동안 매일 누적 증분 백업 및 복원(일반적으로 하루에 2~10GB의 데이터 변경)을 실행하는 데 사용되었으며 단 한 번도 실패한 적이 없습니다.
gtar를 사용하여 백업을 시작하기 전에 먼저 유사한 복구 테스트를 실행하는 것이 좋습니다.
참고: 증분 복구에서 GNU tar가 어떻게 실패하는지 확인하는 스크립트는 다음과 같습니다.전체 시스템 백업을 위해 tar를 사용할 수 있습니까?