%EB%A7%8C%20%EB%B0%B1%EC%97%85%ED%95%98%EB%8A%94%20%EB%B0%A9%EB%B2%95%EC%9D%80%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F.png)
재해 복구 목적으로 다음을 백업하고 싶습니다.
- GPT 파티션 테이블,
- 디스크 구조(다른 크기의 드라이브로 복구)
- 각 파티션에 해당하는 파일 시스템 유형 및 파일 시스템 설정도 마찬가지입니다.
예를 들어, rsync나머지 파일과 폴더의 일부를 백업하고 복원할 수 있습니다. GPT 파티션 디스크의 5개 파티션과 해당 FAT 및 RAID-1 스타일 BTRFS 파일 시스템도 백업해야 합니다.
Sgdisk파일 시스템 복원 안 함
sgdisk드라이브 백업 및 복원 명령이 있습니다 . 이는 해당 파티션의 파일 시스템이 아닌 파티션 구성만 백업하고 복원합니다.
File많은 파일 시스템 세부 정보를 출력합니다.
# file -sL /dev/sda?
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 32, heads 64, hidden sectors 8192, sectors 2097152 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 2048, reserved 0x1, serial number 0x7181b420, unlabeled
/dev/sda2: BTRFS Filesystem label "root", sectorsize 4096, nodesize 16384, leafsize 16384, UUID=b81e9d42-c0a2-4a1e-8197-f6775419f654, 3018244096/20971520000 bytes used, 1 devices
/dev/sda3: BTRFS Filesystem label "home", sectorsize 4096, nodesize 16384, leafsize 16384, UUID=2cf4e529-b242-4913-b283-fd18df73316a, 194707456/9965666304 bytes used, 1 devices
출력을 백업하는 것이 가능 file -sL하지만 복원 방법에 대한 부분은 여전히 누락되어 있습니다.
온라인 백업
폴더와 파일 자체를 백업하지 않는 온라인(백업을 위해 시스템을 종료할 필요 없이) "복제" 명령이 필요합니다. 즉, 파일 및 폴더의 모든 이전 드라이브 구성을 복원할 수 있습니다(다른 도구를 사용하여).
주문하다?
파일 및 폴더 이전에 드라이브 재해 복구를 담당하는 명령은 무엇입니까?
참고: 여러 명령을 입력하는 것보다 한 줄 문이 더 나은 답을 제공합니다.
답변1
GPT 파티션 테이블만 고려하면 스마트 백업을 활용해야 한다
export DISK=/dev/sda
echo -e "b\n/tmp/gpt-backup-"${DISK##*/}"\nq\n" | gdisk $DISK
하지만 이 백업은 바이너리 형식입니다.
저는 항상 단순 백업을 선호합니다 gdisk -l /dev/sda. 정확히 동일한 장치로 복원해야 하는 경우가 아니라면 어쨌든 조정이 필요하므로 텍스트 백업이 더 나은 선택입니다.
개인적인 경험으로는 항상 콘텐츠를 복원해야 하지만 파일 시스템 유형 자체는 일반적으로 관련이 없습니다. 대상 마운트 지점이 복원하려는 데이터에 적합하고 이전과 동일한 기능(ACL, 확장 속성, 하드 링크)을 제공하는 한 rsync 기반 백업에서 복원할 수 있습니다.
일반적으로 디스크의 정확한 레이아웃보다는 관련 데이터를 백업하는 것이 지침입니다. 이는 프로세스를 간단하고 쉽게 검증할 수 있으며 실제로 필요하지 않은 세부 사항과 무관하게 만듭니다.
답변2
분할된 테이블은 이미 다른 답변에서 다루어졌습니다.
(S)ATA에서 약 128GiB(또는 정확히 2^28 블록)보다 크고 SCSI에서 약 8GiB보다 큰 디스크의 경우 이전 C/H/S 스타일 디스크 구조는 더 이상 사용되지 않으며 관련이 없습니다. 디스크가 실제로 관심을 갖는 유일한 사항입니다. LBA 블록 번호입니다. 디스크의 실제 물리적 기하학적 구조는 C/H/S보다 더 복잡합니다. 예를 들어 필요한 저장 밀도를 달성하려면 외부 트랙이 내부 트랙보다 더 많은 섹터를 갖게 됩니다.
기하학 기반 성능 최적화를 시도하기 위해 매우 오래된 파일 시스템 유형을 사용하지 않는 한, 디스크 기하학은 파일 시스템 내용에 전혀 영향을 미치지 않습니다.
일반적으로 "파일 시스템 백업"은 그 안에 있는 파일과 디렉터리를 백업한다는 의미로 이해됩니다. 하지만 당신은 이미 그렇게 했고 백업을 고려하고 있습니다.파일 시스템 구성 설정및 기타 파일 시스템 수준 메타데이터. 불행하게도 이는 파일 시스템 유형에 따라 다르므로 모든 파일 시스템에 작동하는 하나의 명령을 갖는 것은 불가능합니다. 파일 시스템이 생성된 후 일부 내용을 변경할 수 없는 경우가 있으므로 다음 사항을 고려해야 합니다.다시 만들다대신에다시 덮다파일과 디렉터리를 이전 파일 시스템 구성으로 복원합니다.
명령의 출력은 lsblk -f아마도 blkid파일 시스템 레이블인 UUID(또는 VFAT 파일 시스템 ID가 실제 UUID가 아니기 때문에 "볼륨 일련 번호")를 알려줄 것입니다. 재해 복구 컨텍스트에서 파일 시스템을 다시 생성할 때 이를 기록하고 명시적으로 지정할 수 있습니다.
따라서 최종 답변은 다음과 같습니다.파일 시스템을 생성하는 데 사용되는 로깅 명령, 그리고동일한 명령을 반복적으로 사용(온라인 용량 확장 등을 고려하여 수정될 수 있음)을 복구 시나리오에서 다시 생성합니다. 새로운 시스템 배포를 위한 표준화/자동화된 절차가 있다면 재해 복구에서도 해당 절차(일부)를 재사용할 수 있습니까?
하지만 BTRFS를 사용하고 있으므로 알아야 할 사항은 다음과 같습니다.동일한 UUID를 가진 파일 시스템을 여러 개 마운트하는 것은 위험할 수 있습니다., BTRFS 드라이버는 단순히 동일한 파일 시스템 콘텐츠에 대한 여러 경로에 액세스하여 콘텐츠를 손상시킬 수 있다고 가정할 수 있기 때문입니다. 최근 몇 년 동안 이에 대한 일부 보호 기능이 추가된 것 같지만 아직 완벽하지는 않습니다. BTRFS 파일 시스템의 디스크 복사본(스킨)을 생성하는 모든 프로세스~ 해야 하다원본을 사용하고 있는 동일한 시스템에 복사본을 설치하기 전에 복사본의 UUID를 고유한 UUID로 바꾸십시오. 여기에는 디스크 이미지 백업뿐만 아니라 SAN 기반 파일 시스템 스냅샷도 포함됩니다.
BTRFS 자체 내에서 생성된 모든 스냅샷은 정의에 따라 파일 시스템에서 이를 인식합니다. BTRFS 외부 수단으로 명백한 클론이 생성되면 문제가 발생합니다. RAID1 세트 분할, 디스크 복제 또는 SAN 스토리지 시스템에 특정 LUN의 스냅샷을 지정하고 해당 스냅샷을 새 LUN으로 표시하는 것은 실제 LUN이 없으면 위험할 수 있습니다. 새 스냅샷/복제본을 생성하려면 파일 시스템 UUID를 변경하는 절차를 지웁니다.
직장에는 SAN 수준 스냅샷과 복제 프로세스를 광범위하게 사용하는 클라이언트가 있습니다. 프로덕션 파일 시스템을 복제하여 애플리케이션 업데이트를 테스트한 다음 테스트를 거쳐 양호한 것으로 확인되면 복제본을 프로덕션 시스템에 제공할 수 있습니다. 조만간 그들은 원래 복제 쌍으로 동일한 호스트에 제공되었던 두 개의 파일 시스템을 갖게 될 것입니다(그러나 그 이후로 매우 다른 삶을 살았습니다). 그러다가 다양한 "중복 UUID" 오류가 발생하기 시작했고 저는 이를 해결하는 데 참여했습니다. UUID를 다시 고유하게 만들기 위해 적절한 UUID를 변경하면 모든 것이 정상입니다. 그런 다음 프로세스를 진행하고 복제된 디스크 쌍의 두 절반이 나중에 동일한 시스템에 제공될 경우를 대비하여 디스크 복제 단계 후에 UUID를 변경하는 누락된 단계를 추가했습니다.
운 좋게도 그들은 BTRFS를 사용하지 않지만... 이러한 이벤트에 대해 놀라울 정도로 강력한 보호 기능을 제공하는 LVM을 사용합니다. 동일한 UUID를 가진 여러 LVM PV를 얻을 때마다 LVM 도구는 큰 소리로 불평하고 다른 작업을 수행하기 전에 무슨 일이 일어나고 있는지 파악하고 수정하도록 강요합니다. 새 LVM PV가 핫 플러그된 경우 LVM은 모호함이 없는 경우에만 자동으로 활성화합니다.
device-mapper-multipath(LVM은 LVM이 디스크를 확인하기 전에 모든 다중 경로가 처리되거나 유사해야 한다고 예상합니다. ZFS와 마찬가지로 BTRFS에는 LVM과 유사한 기능이 통합된 것으로 보입니다.)