스토리지 서버를 어떻게 백업합니까?

다른 여러 서버 (모든 Linux 기반)의 라이브 NAS로 사용될 매우 큰 스토리지 서버를 구현하려고합니다.

매우 큰 의미 에서, 4TB에서 20TB 사이의 사용 가능한 공간을 의미 합니다 (실제로 20TB로 만들 가능성은 낮음).

스토리지 서버는 데이터 보안 및 성능을 위해 RAID 10이되지만 오프 사이트 백업을 포함한 백업 솔루션이 여전히 필요합니다.

내 질문은 : 어떻게 그렇게 많은 데이터를 백업합니까!?

휴대용 하드 드라이브를 연결하고 파일을 전송할 수있는 것은 아닙니다. 현재이 저장 공간이 많은 다른 장치는 없습니다.

두 번째 오프 사이트 스토리지 서버에 대한 예산을 책정해야합니까, 아니면 더 나은 솔루션이 있습니까?

해당 크기의 데이터를 처리하는 방법에는 여러 가지가 있습니다. 그것의 많은 것은 환경과 당신이 기꺼이 쓸 돈에 달려 있습니다. 일반적으로 몇 가지 '서버에서 데이터 가져 오기'전략이 있습니다.

• 이더넷 을 통해 상자에 표시된 것처럼 데이터는 다른 곳으로 스트리밍되어 처리됩니다. 20TB는 1GbE를 복사하는 데 시간이 오래 걸리지 만 수행 할 수 있습니다. 하드웨어가 도움이 될 수 있습니다 (예 : 10GbE 링크 또는 경우에 따라 NIC 본딩).
• 스토리지 하위 시스템을 통해 Fibre Channel을 사용하는 경우 FC 네트워크의 다른 장치로 전송하십시오. SAS가 있으면 SAS 연결 장치로 보내십시오. 일반적으로 이더넷보다 빠릅니다.
• 다른 디스크 어레이로 전송 동일한 서버에 연결된 다른 스토리지 덩어리로 보냅니다.

이것이 100Km입니다. 확대를 시작하면 훨씬 더 조각화됩니다. 이미 언급했듯이 LTO5는 이러한 종류의 고밀도로드를 위해 설계된 특정 테이프 기술입니다. GlusterFS 또는 DRBD와 같은 데이터를 사용하여 데이터를 가져올 수있는 경우에도 동일한 동일한 스토리지 배열을 사용하는 것이 좋습니다. 또한 백업 회전 이 필요 하거나 어레이에 장애가 발생했을 때 계속 작동 할 수있는 기능은 배치에 영향을줍니다.

100Km보기 방법을 결정한 후에는 소프트웨어에 들어가는 것이 다음 큰 과제가 될 것입니다. 이것에 영향을 미치는 요소는 스토리지 서버에 처음 설치할 수있는 것입니다 (NetApp의 경우, 스토리지가 많은 Linux 서버는 스토리지가 많은 Windows 서버와 마찬가지로 완전히 다른 것임) , 어떤 하드웨어를 선택하는지 (예를 들어, 모든 FOSS 백업 패키지가 테이프 라이브러리를 제대로 처리하지는 않음), 어떤 종류의 백업 보존이 필요한지.

실제로 어떤 종류의 재해 복구를 원하는지 파악해야합니다. 간단한 라이브 복제는 더 쉬워 지지만, 지난주 만 복구 할 수는 없습니다. 지난 주부터 복원 할 수있는 능력이 중요하다면, 그런 종류의 것을 설계해야합니다. 법률에 따라 (미국 및 기타 지역에서) 일부 데이터는 7 년 이상 보존해야합니다.

간단한 복제가 가장 쉬운 방법입니다. 이것이 DRBD가하는 일입니다. 초기 복사가 완료되면 변경 사항 만 보냅니다. 두 번째 어레이가 기본 DRBD에 가까이 있지 않은 경우 여기에서 복잡한 요소는 네트워크 위치입니다. 최소한 첫 번째 스토리지 공간만큼 많은 두 번째 스토리지 서버가 필요합니다.

테이프 백업 정보 ...

LTO5는 압축없이 1.5TB의 데이터를 보유 할 수 있습니다. 이러한 몬스터에게 먹이를 주려면 파이버 채널 또는 6Gb SAS 인 매우 빠른 네트워킹이 필요합니다. 한 번에 1.5TB 이상을 백업해야하므로 오토로더를 살펴 봐야합니다 (예 : HP의 24 슬롯 1 드라이브 오토로더 인 link ). 이를 지원하는 소프트웨어를 통해 백업 도중 테이프 변경을 처리 할 수 ​​있습니다. 그들은 대단해. 오프 사이트로 보내려면 여전히 테이프를 꺼내야하지만, 백업이 필요할 때 테이프를 직접 적재하기 위해 밤새도록 매달려있는 것보다 더 나은 광경입니다.

테이프가 ' 레거시, ew'heebiegeebies를 제공하는 경우 가상 테이프 라이브러리가 더 빠른 속도 일 수 있습니다 (예 : Quantum의 링크 : link ). 이들은 강력한 중복 제거 기술을 사용하여 실제로 디스크에 항목을 저장하면서 소프트웨어를 백업하는 테이프 라이브러리 인 것처럼 가장합니다. 더 좋아하는 사람들은 가상 테이프를 실제 테이프로 복사하기도합니다. 이런 종류의 것을 원한다면 오프 사이트 로테이션에 매우 유용 할 수 있습니다.

가상 테이프를 사용하지 않고 디스크로 직접 백업을 수행하려는 경우 20TB를 처리 할 수있을만큼 큰 크기의 스토리지 배열과 원하는 순 변경 데이터가 필요합니다 붙잡기 위해. 다른 백업 패키지는이를 다르게 처리합니다. 일부 중복 제거 기술은 정말 훌륭하고 다른 기술은 해키 kludges입니다. 나는 개인적으로이 영역에서 FOSS 백업 소프트웨어 패키지의 상태를 알지 못하지만 (Bacula에 대해 들어 본 적이 있음) 충분할 수 있습니다. 많은 상용 백업 패키지에는 처리량을 높이기 위해 백업 할 서버에 로컬 에이전트가 설치되어 있으며 이는 많은 장점이 있습니다.

LTO-5 주크 박스? 어레이를 백업하려면 3 개에서 15 개의 테이프가 필요합니다. 이는 엄청나게 큰 숫자가 아닙니다. 주크 박스는 테이프 교체를 담당하며, 우수한 백업 소프트웨어 (예 : bacula)는 어떤 테이프에 어떤 파일이 있는지 추적합니다.

또한 해당 기간 동안 FS가 변경 될 가능성이 높기 때문에 파일 시스템을 크게 백업하는 데 필요한 시간을 고려해야합니다. 최상의 결과를 얻으려면 스냅 샷을 지원하는 파일 시스템이 매우 유용하므로 실시간 파일 시스템이 아닌 즉각적인 스냅 샷을 작성하여 전체 또는 증분 백업을 수행 할 수 있습니다.

테이프에 시간이 오래 걸리고 순차적 액세스이므로 복원에 시간이 오래 걸리므 로 disk 백업을 검토해야합니다 .

차등 또는 증분 백업을 확실히 활용 하십시오. 원하는 빈도로 변경 사항 만 백업하십시오.

아마도 이상적인 솔루션은 다른 위치에 비슷한 크기 의 두 번째 서버 가있을 것입니다 . 증분 백업은 정기적으로 전송되며 주 서버가 사망 한 경우 신속하게 교체 할 수 있습니다. 그러나 다른 옵션은 현장에서 이동식 드라이브 를 사용하는 것 입니다.

많은 양의 데이터를 처리 할 때는 백업 을 더 작은 백업 작업으로 나누고 매일 백업 할 수없는 경우 백업을 엇갈리게 설정하여 A를 하루 동안 백업하십시오. B를 다음으로 설정하십시오.

항상 복원 절차에 대해 생각하십시오 . 수백 개의 기가 백업 작업에서 파일을 복원해야 할 때 한 번 멈췄습니다. 백업 인덱스를 다시 작성하고 복원하는 데 많은 메모리와 시간이 걸렸습니다. 결국 하루 만에 완료 할 수 없었고 주 백업 서버가 야간 작업을 계속할 수 있도록 전용 복원 서버를 구축해야했습니다!

-추가-

또한 중복 제거 기술 에 대해 생각하고 싶습니다. 중복 제거 기술은 여러 사용자에 대해 동일한 정보를 여러 번 백업하지 않으면 서도 많은 공간을 절약 할 수 있습니다. 많은 백업 솔루션 또는 파일 시스템은 기능의 일부로 중복 제거를 제공합니다.

먼저, 당신이 보호하는 위험을 열거하십시오. 몇 가지 일반적인 위험 :

• 재난 : 전체 사이트에 매우 불행한 일이 발생합니다.
• 인적 오류 (_all_the_time_에서 발생하는 오류) :
  • 누군가 제조업체에서 의도하지 않은 방식으로 스토리지 서버의 "핫 스왑"기능을 사용하기로 결정했습니다.
  • 누군가 데이터를 자동으로 손상시키는 프로세스를 실행하여 문제가 발견되기 전에 몇 개월 동안 안정적으로 백업됩니다.
  • 누군가 한 시간 안에 제출해야 할 중요한 보고서를 삭제하고 수천 달러의 가치가 있습니다.

그런 다음 다양한 위험 회피 솔루션의 비용을 평가하십시오. 예 :

• 오프 사이트, 온라인 백업 (원격 미러) : 재난으로부터 안전하고 일부 (일부는 아님) 인적 오류 (아직 온라인 상태).
• 오프 사이트 오프라인 스토리지 (테이프) : 재해로부터 안전하고 데이터를 빠르게 복구하기 어렵습니다.
• 현장 온라인 백업 (미러) : 인적 오류, 하드웨어 오류, 재난에 취약한 상황으로부터 안전합니다.
• 온 사이트 오프라인 백업 (테이프 체인저의 테이프) : 대부분의 사람의 실수, 대부분의 하드웨어 오류로부터 안전합니다.

그런 다음 순환 전략을 평가하십시오 (복구 할 수있는 거리, 손실 가능한 데이터 양).

그런 다음 데이터의 가치를 선택하십시오.

1GB로 연결된 두 개의 서로 다른 건물에 두 개의 유사한 12TB 시스템을 보유한 고객이 있습니다. 하나는 생산 시스템입니다. 훌륭한 rdiff-backup 유틸리티 를 사용하여 점진적으로 (매일 스냅 샷과 함께) 다른 백업으로 백업 합니다. rdiff-backup은 표준 배포 저장소에서 사용할 수 있어야합니다.

오프 사이트 온라인 백업 (원격 미러)

ssh를 통해 rsync 사용 (변경 만)-첫 번째 백업은 로컬로 수행해야하지만 그 백업 이후에는 변경에 따라 산들 바람이납니다

변경 -rdiff-backup으로 버전을 유지해야하는 경우

http://www.nongnu.org/rdiff-backup/

Linux의 btrfs 파일 시스템은 유망한 것으로 보이지만 여전히 개발이 심합니다.

실제 "콘텐츠"와 전략을 계획하기 전에 콘텐츠가 얼마나 자주 변경되는지 살펴보십시오. 많은 사람들이 정당한 이유없이 매주 같은 데이터를 반복해서 매주 테이프로 녹화합니다.

일부 공급 업체의 중복 제거 기술을 사용하면 스냅 샷을 통해 개별 파일 복원에서 저장하지 않아도되지만 항상 보호를 위해 오프 사이트가 필요합니다.