스냅 샷 + RAID는 우수한 온 사이트 백업 솔루션으로 간주됩니까?

btrfs와 함께 스냅 샷과 RAID를 함께 사용할 때 백업을 생각할 수있는 두 가지 주된 이유가 해결 된 것으로 보입니다. (여기서 RAID는 RAID1 또는 10을 의미합니다)

• 실수로 데이터 삭제 :이 사례는 스냅 샷에서 다룹니다.
• 드라이브 고장 및 비트 부패
  • 완전한 실패 : RAID가이 경우를 다룹니다.
  • 잘못된 데이터를 반환하는 드라이브 : RAID + btrfs의 오류 수정 기능이이 경우를 다룹니다.

따라서 현장 백업 솔루션으로서 이것은 잘 작동하는 것처럼 보이며 별도의 데이터 저장 장치가 필요하지 않습니다!

그러나 RAID와 스냅 샷이 모두 올바른 백업으로 간주되지 않는다고 들었으므로 누락 된 부분이 있는지 궁금합니다.

btrfs가 아직 성숙 된 기술이 아니라는 것 외에도 내가 놓친 것을 생각할 수 있습니까? 아니면 내 생각이 맞고 이것이 유효한 현장 백업 솔루션입니까?

아뇨.

파일 시스템 또는 RAID 볼륨이 손상되면 어떻게됩니까? 아니면 서버가 작동합니까? 아니면 누군가 실수로 잘못된 배열을 포맷합니까?

당신 이 생각한 모든 데이터 와 실제 백업이 아닌 것을 잃게됩니다 . 이것이 실제 백업이 백업하는 데이터와 완전히 다른 시스템에있는 이유입니다. 백업은 문제의 시스템에서 발생하는 데이터가 데이터 손실을 유발하지 않도록 보호하기 때문입니다. 백업을 백업 할 때와 동일한 시스템에 보관하십시오. 해당 시스템의 데이터 손실이 "백업"에도 영향을 줄 수 있습니다.

들어 현장 백업, 스냅 샷 수 , 좋은 충분 제공되는 이 수동 데이터로 존재하면 정기적으로 '수출'다른 곳에서 스냅 샷.

또한 '배송 된 스냅 샷'을 복원 할 수 있는지 정기적으로 테스트하십시오.

이렇게하면 일부 서버의 빠른 백업을 구현 한 방법이 있습니다. ZFS에 데이터를 저장하고, ZFS 스냅 샷을 만들고, 델타 를 다른 서버로 전송 하여 전체 파일 시스템을 재 작성합니다 (실제 서비스 실행 제외).

물론 최상의 백업은 항상 오프 사이트에 있습니다. 따라서 스냅 샷을 별도의 시스템으로 '운송'한 후에는 정기적으로 스냅 샷을 '테이프 아웃'하십시오.

따라서 내 시스템에서 스냅 샷 델타를 수신하는 서버는 모든 ZFS 풀 (이전 스냅 샷 포함)을 테이프에 정기적으로 덤프합니다.

물론 테이프 아웃을 복원 할 수 있는지 테스트하십시오.

참고 : 정지 된 디스크 작업 중에 스냅 샷이 발생하고 일관성을 유지하기 위해 데이터베이스 (있는 경우)와 조정하는 것이 좋습니다. 그렇지 않으면 치료가 병보다 나빠질 수 있습니다. NetApp 및 EMC '실시간 스냅 샷'기능이 매우 유용한 이유는 LUN을 사용하는 데이터베이스가 스냅 샷을 수행하는 것이 안전하다고 표시 될 때까지 LUN의 스냅 샷을 연기합니다.

HopelessN00b가 말한 것. 아니.

올바른 백업은 백업중인 장치와 별도의 장치에 있습니다. 두 개 이상의 드라이브를 잃으면 어떻게됩니까? 서버 룸이 소실되면 어떻게됩니까? 누군가 실수로 어레이를 파괴하면 어떻게됩니까?

(일화 경고 : PXE가 최신 Fedora를 자동 설치하도록 설정 한 사람에 대해 한 번 들었습니다. UPS에 장애가 발생했습니다. 정전 후 서버가 재부팅되고 PXE 부팅으로 설정되어 데이터에 Fedora가 설치되었습니다. 기발한 일이 일어 났지만 다행히도 적절한 백업이있었습니다.)

데이터 센터가 소진 될 경우를 대비하여 외부에 완전히 저장된 데이터 사본이 3 개 이상있는 것이 좋습니다.

적절한 백업은 백업 작업을 생성하는 첫 단계로 사용하므로 스토리지에서 올바르게 구현 된 스냅 샷을 반드시 지원해야합니다. 그러나 기본 백업에 스냅 샷을 사용하는 것은 좋지 않습니다. 원인:

1) 스냅 샷 및 백엔드 스토리지가 실패 할 수 있습니다. 따라서 실제 백업은 별도의 스핀들 세트를 사용해야합니다. 그렇지 않으면 기본 작업 세트와 백업 데이터를 동시에 잃을 수있는 좋은 기회가 있습니다.

2) 스냅 샷이 사용 가능한 공간을 "씹어냅니다". 현재 핫 데이터 및 오프로드 스냅 샷과 백업을 저렴하고 느린 스토리지에 빙판 데이터로 사용하려면 값 비싸고 빠른 스토리지를 사용하는 것이 좋습니다. 1) BTW와 매우 잘 작동합니다.

3) 스냅 샷은 일반적으로 전체 프로세스를 느리게합니다. 대부분의 시스템은 Copy-on-Write를 사용하며이 방식은 조각화를 만듭니다. Redirect-on-Write는 빠르지 만 많은 공간을 차지합니다. 스냅 샷을 올바르게 구현 한 공급 업체는 거의 없습니다. WAFL이있는 NetApp 및 CASL이있는 Nimble Storage (나는 그중 어떤 것도 필적하지 않습니다). 거의 모든 사람들에게 문제가 있습니다. 예를 들어 Dell Equallogic은 1 바이트마다 15MB의 페이지 업데이트 및 낭비가 발생합니다. 그건 비싸군요.

그렇습니다. 백업을 저장하는 완벽한 방법입니다. 아무것도 점검 할 필요가 없습니다. 심지어 무결점 점검조차도 시간 낭비입니다.

더 많은 조언을하기 전에 ... 당신은 내 경쟁 업체에서 일합니다. 정말 그렇습니까? 아니? 오.

미안, 너트 아뇨, 전혀 아닙니다. 미안, 친구

문제는 (a) 시스템 및 (b) 운영 체제 수준에서 발생하는 모든 오류에 완전히 개방되어 있다는 것입니다. 기본적으로 일부 데이터를 삭제하는 사람 만 보호합니다. 좋은. 그것은 종종 발생하는 오류입니다.

당신이 보호하지 않는 것은 :

• 기계를 닦아내는 전원 스파이크. 거기에 있었어요.
• 디스크에 결함이있는 RAID 컨트롤러 또는 메모리 쓰기 sh **가 있습니다.

그리고 다른 것들의 긴 목록.

이것은 당연히 내 경쟁 업체에서 일하지 않는 한 항상 백업을 수행하십시오.

• 다른 컴퓨터에서
• (USV가있는 경우에도) 최소한의 전력 스파이크로부터 격리해야합니다.

이것이 테이프가 흔들리는 이유입니다. 테이프가 연결되어 있지 않고 화재 나 홍수로 인한 짧은 일이 다 치지 않습니다. 전력 스파이크-테이프 리더와 로봇이 있지만 리더에없는 테이프는 영향을받지 않습니다.

가장 좋은 방법은 오프 사이트 백업 일 것입니다 (화재 및 홍수와 같은 것을 이미 언급 했습니까?). 돈을 저축하십시오).

지금, 당신은 "오, 홍수가 발생하지 않습니다"라고 생각할 수 있습니다. 확실하게 확인하십시오. 여기 보더 폰 데이터 센터에 대한 09.09.09 홍수의 비디오가 있습니다. 온 사이트 / 컴퓨터 백업의 문제가 어디인지 이해할 것입니다.

http://www.youtube.com/watch?v=ttcQy3bCiiU

레슨은 서로 반 시간 내에 고장 개의 드라이브 RAID-1에서 얻은 : RAID는 없다 되지 않는 임의의 방법, 형상 또는 형태, 백업기구.

RAID는 하드웨어 장애 발생시 가동 중지 시간을 줄이는 가용성 메커니즘이지만 바이러스, 데이터 삭제 / 수정 또는 심각한 치명적인 하드웨어 장애와 같은 경우에는 전혀 도움이되지 않습니다.

많은 숙련 된 관리자가 3-2-1 백업 규칙을 사용합니다.

• 기본 소스를 포함하여 데이터 사본이 3 개 이상 있어야합니다. 즉 단일 백업은 하지 충분하고 동일한 물리적 시스템 내 사본은 포함되지 않습니다.

• 최소한 두 가지 다른 백업 방법을 사용해야합니다.

• 하나 이상의 오프 사이트 데이터 복사본이 있어야합니다.

스냅 샷은 세 부분을 모두 위반합니다.

• 실제 머신은 하나만 사용하십시오. PSU 오류와 같이 전체 시스템에 영향을 미치는 모든 사항은 모든 데이터를 사용할 수 있습니다.

• 백업에는 단일 방법 만 사용하고 있습니다. 경우 아무것도 그것으로 잘못 위기 상황에서 백업을 복원 할 때, 당신은 발견 할 것이다.

• 오프 사이트에 백업이 없습니다. 홍수와 화재는 당신에게 일어날 때까지 다른 사람들에게만 발생합니다 ...

따라서:

• LAN 의 별도 시스템에 백업이 하나 이상 있어야 합니다.

• 스냅 샷을 사용하여 생성 되지 않은 백업이 하나 이상 있어야합니다 . 아마도 오래된 증분 tar아카이브가 순서대로있을 수 있습니까? 아니면 rsync사본?

• 당신은 적어도 하나의 원격 사용자의 현재 위치에서 가능한 한 백업 및 가질 필요가 확실히 같은 건물 없음.

또한 블록 수준 스냅 샷은 시스템의 플러그를 뽑은 다음 디스크를 복사하는 것과 거의 동일한 일관성을 보장합니다. 일반적으로 fsck복원 후에 실행 하거나 저널이 충분하기를 바랍니다.

파일 시스템 수준의 스냅 샷이 더 나아야하지만 파일의 일관성을 보장하지는 않습니다. 많은 인스턴스 (데이터베이스 서버를 염두에 두는 경우)에서 라이브 인스턴스의 파일을 복사하는 것은 일관성이없는 상태 일 수 있으므로 완전히 쓸모가 없습니다. 3-2-1 규칙이 적용되는 클린 사본이 존재하는지 확인하려면 자체 애플리케이션 레벨 백업 메커니즘을 사용해야합니다.

마지막으로 현재 데이터의 사본에 대해서만 이야기하고 있습니다. 일정 시간 동안 발견되지 않은 장애 (또는 해당 문제에 대한 보안 침해)를 방지하려면 꽤 오래 전의 데이터 사본 몇 개가 있어야합니다.

그 자체로는 전혀 백업 솔루션 이 아닙니다 . 특정 장애 시나리오에서 가동 중지 시간을 줄이거 나 제거하지만 많은 다른 사용자로부터 당신 을 전혀 보호하지는 않습니다.

물론 더 둥근 가용성 + 백업 솔루션의 매우 중요한 부분이 될 수 있습니다.

• 동일한 하드웨어에서 RAID plus 스냅 샷
• 다른 하드웨어의 현장 사본
• 반 절연 원격 사본
• 물론 진정한 재해에 대한 적절한 오프라인 + 오프 사이트 사본

또한 정기적으로 백업을 테스트해야합니다. 백업이 작동하지 않는 것을 발견하는 최악의 시간은 백업에서 무언가를 검색해야 할 때입니다.