LVM 블록 장치의 오프사이트 전체 백업을 생성해야 합니다. 이전 ddSSH 방법을 고려하십시오.
일관된 백업을 보장하려면 먼저 LVM 스냅샷을 생성해야 합니까?
그러면 새로 변경된 블록이 스냅샷 논리 볼륨에 기록되지만 dd원래 논리 볼륨에는 기록되지 않습니까? 그런 다음 스냅샷만 사용하여 기본 논리 볼륨에 계속 기록
하겠습니다 .lvremove
나는 또한 dd이것이 가장 느리고 가장 효율성이 떨어지는 방법이라고 모든 사람들이 말하는 것을 봅니다. 대안은 무엇입니까?
압축하지 않고 블록 장치의 전체 백업을 더 빠르게 만드는 방법을 모르겠습니다.
편집: 좋아, 내가 방금 기억한 한 가지는 ddFS 수준의 데이터에 관계없이 블록이 물론 전송된다는 것입니다. 따라서 단일 1K 텍스트 파일이 있는 300GB LV의 경우 dd전체 300GB 블록이 전송됩니다. 그럴 수 있지. 나는 LV를 약 80%로 유지하므로 전송당 추가 20%에 대해 너무 많이 걱정할 필요가 없습니다.
답변1
스냅샷: 백업하려는 파티션이 현재 마운트되어 있으면 먼저 스냅샷을 찍으세요. 하지만, 추가해야 합니다스냅 사진,아니요원본 볼륨. 어쨌든 마운트하면 원래 볼륨의 내용이 변경됩니다.
그러면 원본 논리 볼륨을 추가하면 새로 변경된 블록이 스냅샷 논리 볼륨에 기록됩니까?
습관. 블록이 변경되면 이전 콘텐츠가 먼저 스냅샷에 복사됩니다. 그러면 원본 볼륨의 블록이 새 콘텐츠로 덮어쓰여집니다. 바라보다http://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html또 다른 설명(스냅샷 작동 방식이 그다지 직관적이지 않다는 점은 인정합니다. 이 이중 복사는 스냅샷 볼륨의 쓰기 성능이 저하되는 이유이기도 합니다.)
또한 모든 사람들이 dd가 가장 느리고 효율성이 떨어지는 방법이라고 말하는 것을 봅니다. 대안은 무엇입니까?
말씀하신 것처럼 주요 문제는 파일 시스템이 실제로 블록을 사용하는지 여부에 관계없이 모든 블록을 복사하는 것입니다. 대안은
- 파일 기반 백업(예: 오래된 tar 파일) 물론 여기에는 자체적인 단점이 있습니다. 예를 들어 간단한 dd를 사용하여 손상된 디스크를 복구할 수 없거나 부트로더를 저장하지 않는 등입니다.
- 혼합 솔루션.http://www.partimage.org/디스크 "smart" dd와 유사한 작업을 수행합니다. 실제로 어떤 블록이 사용 중인지 알 수 있을 정도로 ext2/3/xfs에 대해 충분히 알고 있으며, 다른 모든 블록이 0으로 채워져 있다고 가정하고 해당 블록만 복사합니다. 불행하게도 partimage는 ext4 또는 btrfs를 지원하지 않습니다.