ZFS가있는 백업 스토리지 서버

저는 소규모 회사의 모든 IT 담당자입니다. 회사 전체 백업 정책이있는 별도의 백업 서버와 새 서버를 포함한 새로운 인프라를 설계하고 싶습니다.

회사에서 가장 중요한 것은 SQL Server 및 해당 데이터베이스입니다. 데이터베이스는 10 개이지만 그중 2 개만 중요합니다. 첫 번째 8GB는 주로 텍스트 데이터와 숫자입니다. PDF와 GIF를 포함하여 16GB / 월의 300GB 정도의 두 번째 크기입니다.

스토리지 현재 백업 정책을 저장하려면 주당 하나의 전체 백업과 6 개의 차이로 구성됩니다. 나는 주당 약 350GB, 매월 1.4TB라고 생각합니다.

자동 데이터 손상에 대한 기사를 읽은 후 Nexenta Community 에디션으로 ZFS를 사용하기로 결정했습니다.

내 질문 : 중복 제거 기능이있는 ZFS는 안정성 측면에서 백업 파일을 저장하는 데 좋습니까? 아니면 테이프 백업이나 다른 것에 대해 생각해야합니까?

편집 : 나는 지금 우리가 성능, 중복 제거 비율 등을 예측할 수 없다는 것을 알고 있지만 그것이 좋은 아이디어인지 알고 싶습니다.

확실히 ZFS는 이러한 종류의 작업을 수행 할 수있을만큼 충분히 안정적이며, ZFS와 Nexenta를 기반으로하는 매우 크고 신뢰할 수있는 생산 플랫폼이 많이 있습니다.

즉, 항상 제안하는 것과 같은 온 사이트 디스크 기반 백업과 화재 / 지진 / 크 툴후 등을 방지하기 위해 매일 오프 사이트로 이동하는 이동식 디스크 또는 테이프 기반 백업을 원합니다.

내 대답은 그렇습니다. 괜찮지 만 가능하다면 두 가지 옵션을 모두 사용하려고합니다.

(ZFS와 백업 소프트웨어 내에서 중복 제거를 사용한다고 가정하면)

나는 할 수 없습니다 ZFS 사용하는 것이 좋습니다 네이티브 당신이 그것을 위해 특별히 스토리지 시스템을 설계하지 않는 한 백업 시스템에 대한 중복 제거를.

ZFS에서 중복 제거 기능을 사용하는 것은 RAM을 많이 사용합니다. 데이터가 스토리지 풀에 스트리밍 / 기록 될 때 중복 제거가 실시간으로 수행되므로 데이터 블록을 추적하는 테이블이 메모리에 유지됩니다. 이것은 DDT 테이블 입니다. ZFS 스토리지 서버에이 테이블을 수용하기에 충분한 RAM이 없으면 성능이 크게 저하됩니다. 테이블이 특정 임계 값을 초과하면 Nexenta가 경고하지만, 너무 늦었을 때 경고합니다. L2ARC 장치 (캐시 읽기)를 사용하면이 기능을 보강 할 수 있지만 ZFS의 많은 초기 채택 자가이 함정에 빠졌습니다.

보다:

ZFS-중복 제거 된 zvol 또는 데이터 세트를 삭제하면 서버가 중단됩니다. 회복하는 방법?

ZFS-L2ARC 캐시 장치 오류의 영향 (Nexenta)

중복 제거를 사용하기 위해 RAM 요구 사항이 높다고 말하면 64GB + RAM 및 200GB + L2ARC에서 설명하는 데이터 세트에 필요한 RAM 및 L2ARC가 필요합니다. 그것은 작은 투자가 아닙니다. 다시 읽지 않을 많은 Windows 시스템 파일과 이미지 문서를 유지하면 DDT가 매우 빨리 채워집니다. 그 대가는 선행 작업에 필요한 엔지니어링 작업에 가치가 없을 수 있습니다.

zpool에서 압축을 사용하여 압축 가능한 데이터 유형에 gzip 기능을 활용하는 것이 좋습니다. 중복 제거 된 데이터를 삭제해야 할 때 적중이 있으므로 중복 제거는 가치가 없습니다 (DDT를 참조해야 함).

또한 백업 소프트웨어에 스토리지를 어떻게 제공합니까? 어떤 백업 소프트웨어를 사용 하시겠습니까? Windows 환경에서는 ZFS를 iSCSI를 통해 Backup Exec에 블록 스토리지로 제공합니다. ZFS CIFS 기능이 견고하고 기본 형식의 장치의 장점을 선호한다는 것을 결코 알지 못했습니다.

또한 디자인 아이디어를위한 훌륭한 ZFS 리소스가 있습니다. 아무도 당신에게 말하지 않은 ZFS에 관한 것들

대안적인 OS는 OpenIndiana인데, 얼마만큼 더 자주 업데이트를받습니다.

다른 옵션은 압축이 가능한 더 작은 (잠재적으로) 스토리지 풀을 사용하여 두 번째 ZFS 서버를 설정하는 것입니다. 이 두 번째 장치를 정적 백업에 사용할 수 있습니다. 따라서 읽기 캐시를 생략 할 수 있으며이를 처리하기 위해 많은 양의 CPU / RAM이 필요하지 않습니다.

우리는 내가 일하는 곳에서 이와 같은 설정을 실행합니다.

• 3 쌍의 미러링 쌍으로 구성된 RaidZ1 풀에 6 개의 2TB 디스크가있는 OpenIndiana 주 스토리지 서버 [ main ]. 이는 사용 가능한 스토리지 공간을 줄이면서 빠르고 여러 개의 중복 스토리지 풀을 만듭니다.
• 보조 스토리지 서버 [ backup ]도 백업 장치로만 사용되는 유사한 디스크 구성으로 OpenIndiana를 실행합니다.
• main 은 cron 작업에서 실행되는 스크립트를 가지고 있으며 하루 동안 정기적으로 / tank / [dataset]를 스냅 샷합니다.
• 매일 저녁 네트워크에서 하루의 스냅 샷을 백업으로 푸시하는 다른 크론 작업이 실행 됩니다. 모든 스냅 샷의 초기 동기화가 완료되면 (한 번만 절차) 스냅 샷의 증분 특성으로 인해 변경 사항이 백업 장치에 매우 빠르게 적용됩니다.

ZFS 보내기 / 받기를 조작하는 방법에 대한 간단한 설명이 있습니다. http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/