開いたままで、他のプロセスによって継続的に変更されるファイルがあります。このプロセスは、常にファイルの他の部分を探し、新しいブロックを作成します。ファイルのコピーを作成できますが、時間に合わせてファイルの単一インスタンスのスナップショットを作成したいと思います。
私が望んでいないのは、最初のバイトブロックをコピーし、ファイルが変更された後に新しく変更されたバイトを含む2番目のブロックをコピーすることです。
Linuxは私に役立つことができますか？
答え1
コピーする前に書き込みプロセスを一時停止する必要があります。
ほとんどの場合、書き込みプロセスにはバックアップ機能があります。ファイル更新プロセスのドキュメントを慎重に確認してください。
さらに詳しい情報を得るには、どのプロセスがファイルに書き込んでいるかを知る必要があります。誰かがアプリケーションを知り、正しい方法でバックアップを実行する方法を知っているかもしれません。
kill内蔵バックアップ機能がない場合は、SIGSTOP / SIGCONT信号を使用して書き込みプロセスを一時停止できます。すべての論理更新が単一の操作であれば問題ありません。ただし、ライタープロセスが論理更新（データ更新やファイルのインデックス部分更新）などの2つの書き込みを実行できる場合、これらの書き込みの間にプロセスが一時停止される危険性があります。
答え2
Linuxは私に役立つことができますか？
はい。しかし、あなたが望む方法ではありません。
따라서 Linux의 파일 시스템은 일반적으로 다음과 같은 의미를 따릅니다. 즉, 읽고 있는 파일에 대한 변경 사항은 (어떤 방식으로든) 가능하면 해당 파일을 읽는 모든 리더에 즉시 반영되어야 합니다. 이것이 당신이 원하는 것과 얼마나 일치하지 않는지 주목하십시오.
파일 시스템이나 블록 장치 계층에 스냅샷을 찍도록 지시할 수 있습니다. 여기서 의미는 다릅니다. 즉, 스냅샷 시점에 일관성이 필요합니다.
그래서, 당신은 가지고 있어야합니다
- 스냅샷을 지원하는 파일 시스템 또는
- 스냅샷을 지원하는 블록 장치 하위 계층입니다.
일관성
Donal이 올바르게 지적했듯이: 스냅샷을 찍는다면 이 중 어느 것도 도움이 되지 않습니다.하지만단일 "일관성 단위"(즉, 애플리케이션 보기에서 "데이터 변경"으로 생각할 수 있는 또 다른 일관된 파일 상태를 초래하는 검색 및 쓰기)가 진행 중입니다.
아래 내용은 모두 현재 쓰기가 없는 순간에 스냅샷을 찍었다고 가정합니다. 파일과 정확히 동일하지 않은 복사본은 피합니다.복사가 시작되는 순간. 8kB의 데이터를 쓰는 동안 스냅샷을 생성하는 경우 스냅샷에는 덮어쓰는 8kB 데이터 블록에 4kB의 새 데이터와 4kB의 이전 데이터가 포함됩니다. 이것이 바로 "데이터 불일치"라고 부르는 것입니다.
이것이 실제로 의미하는 바는 도움이 되지 않는다는 것입니다. 파일 일관성을 보장하는 논리적인 방법이 없으면 운영 체제는 파일을 일관된 상태로 가져올 수 없습니다.
이를 수행해야 하는 경우 "올바른" 데이터베이스 시스템이 저장 장치가 갑자기 시스템에서 제거될 때 데이터베이스가 복구할 수 없는 손상된 상태로 남아 있지 않도록 보장하는 방법을 조사해야 합니다.
귀하의 파일은 그렇게 할 수 없습니다. 미해결 쓰기가 없을 때만 스냅샷 시점이 발생하도록 제한하지 않으면 일관성을 스스로 보장할 수 없습니다! 이를 달성하려면 저장 매체나 운영 체제에서 파일 스키마를 변경해야 합니다.
가장 일반적인 접근 방식은 엄격하게 순서가 지정된 메커니즘을 구현하는 것입니다. 1. 변경 사항(기본 파일에서 수행할 위치, 길이 및 데이터 포함)을 파일(또는 다른 파일) 끝에 있는 로그에 기록하고 후행을 사용합니다. 패리티를 사용하여 해당 일이 발생했는지 확인할 수 있습니다. 그리고 완전히 완료된 후에만 변경 사항이 기본 파일에 기록됩니다. 3. 경우에 따라 성공적으로 커밋된 로그 항목을 정리하고 정리해야 하는 경우가 있습니다.
이제 마스터 데이터 파일에 쓰는 동안 스냅샷을 찍으면 로그의 데이터가 마스터 데이터의 데이터와 일치하지 않습니다. 로그의 쓰기를 재생하고 일관된 상태로 돌아갈 수 있습니다. 로그에 기록하는 동안 스냅샷을 찍으면 잠금을 읽을 때 로그 항목의 체크섬이 잘못되어 로그 항목을 완료할 수 없으므로 기본 데이터는 로그 항목이 설명하는 내용에 영향을 받지 않는다는 것을 알 수 있습니다. . 스냅샷 로그에서 손상된 로그 항목을 삭제합니다.
파일 시스템 스냅샷
내가 아는 한, Linux에서는 btrfs 및 openZFS 파일 시스템만 스냅샷을 지원합니다. Btrfs는 Linux 커널의 일부이므로 아마도 사용하기 가장 쉽습니다.
btrfs에서 파일 시스템(예: /srv/data에 마운트된 시스템)은 다음을 가질 수 있습니다.하위 볼륨. 하위 디렉터리로 액세스하거나 개별적으로 설치할 수 있습니다.
btrfs스냅 사진현재 볼륨과 동일한 하위 볼륨입니다. 이는 btrfs로 구현하기가 "쉽습니다".쓰기 중 복사파일 시스템: 일반적으로 파일을 수정할 때마다 수정된 데이터를 포함하는 영향을 받는 저장소 블록의 복사본이 생성됩니다. 그런 다음 파일 메타데이터가 업데이트됩니다. 파일의 내용은 차단 목록의 데이터일 뿐이며, 4. 블록에서 무언가를 변경하면 목록의 네 번째 항목이 새 복사본에 대한 참조로 대체되고 수정됩니다. " 블록. 그럼에도 불구하고 저장 장치가 블록 단위로 작동하기 때문에 이로 인해 발생하는 오버헤드는 매우 낮습니다. 단일 바이트를 읽을 수 없으며 블록을 읽고 바이트와 블록을 쓰는 데 동일한 시간이 걸립니다. 따라서 읽기, 수정하고 다른 위치에 쓰는 것은 제자리에서 수정하는 것만큼 비용이 많이 듭니다.
이제 스냅샷이 생성되면 스냅샷 이후 파일 메타데이터에 대한 모든 수정 사항이 별도의 데이터 구조로 들어가게 됩니다. 따라서 기본적으로 파일 시스템의 스냅샷과 현재 "활성" 작업 보기는 변경되지 않은 모든 데이터를 100% 공유하지만 변경된 내용은 두 번 존재합니다. 한 번은 수정된 버전에, 한 번은 스냅샷 당시의 그대로입니다.
따라서 파일을 btrfs 하위 볼륨에 넣고, 스냅샷을 찍고, 해당 스냅샷을 마운트하세요. 파일은 제 시간에 "동결"됩니다.
블록 장치 매퍼 스냅샷
이는 기본적으로 모든 최신 Linux 파일 시스템에 적용됩니다. 이러한 매우 일반적인 세계에서는 XFS가 널리 사용되는 파일 시스템입니다(그러나 모든 파일 시스템이 그래야 함).
LVM은 Linux 볼륨 관리자입니다. 이는 기본적으로 하나 이상의 블록 장치("물리적 볼륨")를 제공하고 해당 장치를 "볼륨 그룹"으로 조립한 다음 "논리적 롤"을 생성하도록 지시하는 커널의 일부임을 의미합니다.
특별한 경우 중 하나는 "씬 볼륨"입니다. 이는 기본적으로 "알겠습니다. 볼륨 그룹에 512GB의 스토리지가 있습니다. 파일 시스템으로 포맷할 수 있는 논리 볼륨을 생성하고 싶습니다. 결국에는 테라바이트 단위가 되지만(예: 내 고객이 실제로 이것을 사용하는 경우) 지금은 그렇게 많은 공간도 없습니다(새 SSD는 아직 주문되지 않았지만 1테라바이트가 모두 필요하지도 않습니다). 아직)". 그러면 LVM이 볼륨을 생성합니다.것 같다