백업에서 파티션 내용을 복원할 때 백업과 현재 파티션 내용이 다른 블록만 덮어쓰려면 어떻게 해야 합니까? [복사]

백업에서 파티션 내용을 복원할 때 백업과 현재 파티션 내용이 다른 블록만 덮어쓰려면 어떻게 해야 합니까? [복사]

dd of=/dev/where/to/restore일반적으로 백업에서 파티션 내용을 복원하기 위해 with를 사용합니다.입력 스트림어딘가에서(Ssh 연결과 같은).

그러나 쓰기 내구성이 심각하게 제한되어 있는 것으로 알려진 SSD 드라이브를 복원하는 경우 이는 전체 드라이브를 덮어쓰는 것을 의미합니다(일반적으로 파티션은 전체 드라이브 크기에 걸쳐 배치됩니다). 희소 파티션(예: 0이 많이 포함됨)을 복구하는 동안 드라이브의 스마트 속성(또는 동등한 속성)을 살펴본 결과 total_LBA_written완전히 0이 된 블록도 속성에 포함되는 것으로 나타났습니다. 플래시 쓰기 주기를 소비합니다.

그래서 백업 스트림 원본과 대상 드라이브가 다른 블록만 덮어쓰는 방법을 찾고 있습니다. 일반적인 사용 사례는 다음과 같습니다.

  1. 백업을 만든 다음 짧은 시간 동안 드라이브를 약간 변경한 후 복원하십시오. 소수의 다른 블록만 덮어쓰게 됩니다.

  2. 드라이브를 생성한 blkdiscard다음 그 드라이브에 스파스 백업을 복원합니다. 0이 아닌 소수의 블록만 덮어쓰게 됩니다.

내 파티션에 FS가 있는지(또는 FS가 없는지) 걱정하고 싶지 않습니다.

목표를 달성하는 데 사용할 수 있는 도구와 방법은 무엇입니까?

UPD: 댓글의 제안을 바탕으로 다음을 시도해 볼 수 있습니다.

  1. rsync블록 장치 그 이상
  2. bscp기능이 거의 동일한 유틸리티rsync
  3. blkdiscard'ed 드라이브(즉, 모두 0을 포함하는) 의 경우 dd conv=sparse이를 사용할 수 있습니다.

이것들은 모두 좋은 도구이므로 시도해 보겠지만, 다음과 같은 나의 완전한 목표를 달성하지는 못합니다.개울( rsyncbscp)는 이전에 0으로 설정된 대상 드라이브( ) 대신에 사용됩니다 dd conv=sparse.

답변1

이는 의미가 없습니다. 어쨌든 플래시 추상화 계층은 데이터를 덮어쓰기 전에 읽어야 하므로(사용자가 작성하는 블록은 일반적으로 오류 수정 코드 블록과 크기가 다르기 때문에) 처음부터 동일한 데이터를 덮어쓰지 않습니다. 또한 플래시는 생각과 완전히 다를 수 있습니다. 표시되는 LBA 블록은 실제로 웨어 레벨링 알고리즘(내부 블록 크기에서 작동하고 상당히 복잡한 오류의 경우 병합되어야 함) 저장소에 의미가 없습니다. 수정 데이터가 필요함) 및 실제 물리적 매체가 필요합니다.

따라서 솔직히 말해서 셀 수 있는 것보다 일주일에 더 많은 전체 백업 복원을 수행하기 시작하면 쓰기 주기가 걱정됩니다. 당신은 그렇게 생각하지 않는 것 같습니다.

FS(또는 FS 부족)에 대해 걱정하고 싶지 않습니다.

스냅샷이 내장된 쓰기 중 복사(Copy-On-Write) 파일 시스템이 문제를 완전히 해결해 줄 것입니다. (다시 말하지만, 플래시의 내부 작동에 대해 더 많이 알고 있지만 전부는 아닙니다. 따라서 여기에서 생각해낸 영리한 계획이 데이터를 덮어쓰지 않기 때문에 CoW/스냅샷보다 나을지 의심스럽습니다.)

Linux에는 기본적으로 이러한 파일 시스템이 제공됩니다.

내 파티션에 있습니다.

글쎄요, 파티션 대신 스냅샷이 있는 LVM 씬 볼륨을 사용하면 "변경된 부분만 덮어쓰기"는 의미를 잃습니다. 왜냐하면 백업을 복원할 때 변경된 부분을 덮어쓰지 않고 복사본에서 복사-수정-쓰기를 잊어버리기 때문입니다. 변화. 원시 데이터. 외부 백업 스토리지를 이 시나리오와 결합할 수도 있지만 그렇게 하면 과잉이 됩니다.

관련 정보