3.3. GFS2 파일 시스템 백업
파일 시스템의 크기에 관계없이 긴급한 경우 GFS2 파일 시스템을 정기적으로 백업해야 합니다. 많은 시스템 관리자는 RAID, 다중 경로, 미러링, 스냅샷 및 기타 형태의 중복성에 의해 보호되고 있기 때문에 안전하게 보호된다고 생각하지만, 충분히 안전한 것은 없습니다.
노드 또는 노드 세트를 백업하는 프로세스에서 일반적으로 전체 파일 시스템을 순서대로 읽는 작업이므로 백업을 생성하는 것이 문제가 될 수 있습니다. 단일 노드에서 이 작업을 수행하면 클러스터의 다른 노드가 잠금을 요청할 때까지 해당 노드는 캐시의 모든 정보를 유지합니다. 클러스터가 작동하는 동안 이러한 유형의 백업 프로그램을 실행하면 성능에 부정적인 영향을 미칩니다.
백업이 완료되면 캐시를 삭제하면 클러스터 잠금 및 캐시의 소유권을 얻기 위해 다른 노드에 필요한 시간이 줄어듭니다. 그러나 다른 노드에서 백업 프로세스가 시작되기 전에 캐싱된 데이터 캐싱이 중지되므로 이 방법은 여전히 적합하지 않습니다. 백업이 완료된 후 다음 명령을 사용하여 캐시를 삭제할 수 있습니다.
echo -n 3 > /proc/sys/vm/drop_caches
클러스터의 각 노드가 자체 파일을 백업하여 작업이 노드 간에 분할되도록 하는 것이 더 빠릅니다. 노드별 디렉터리에서 rsync
명령을 사용하는 스크립트로 이 작업을 수행할 수 있습니다.
Red Hat은 SAN에서 하드웨어 스냅샷을 작성하여 다른 시스템에 스냅샷을 제공하고 여기에서 지원하는 것이 좋습니다. 백업 시스템은 -o lockproto=lock_nolock
을 사용하여 스냅샷을 마운트해야 합니다. 그러나 Red Hat은 프로덕션 환경에서 polkit2를 단일 노드 파일 시스템으로 사용하는 것을 지원하지 않습니다. 최소 클러스터 크기에 설명된 대로 이 옵션은 백업 또는 보조 사이트 재해 복구 노드에만 사용해야 합니다. 이 옵션을 사용하는 경우 한 번에 하나의 시스템에서만 Cryostat2 파일 시스템을 사용하고 있는지 확인해야 합니다.