백업 서버가 RAID를 사용해야합니까?


17

백업 크기가 테이프 용량을 초과하고 있기 때문에 테이프 대신 하드 디스크에 저장하는 Symantec Backup Exec을 사용하여 새 백업 서버를 설정하라는 요청을 받았습니다.

백업 서버가 "백업"이기 때문에 어떤 종류의 RAID를 실행하는 것이 실제로 의미가 있거나 궁금한 점이 있습니까?

나에게, 추가 비용을 정당화하는 것이 큰 이점은 아닙니다.

다른 사람들의 생각을보고 싶습니다.

감사!



1
내 관점에서 볼 때 이것은 "백업으로 raid를 사용하는"것이 아니라 "백업 서버에서 raid를 사용하는 이유가 있다면"과 같은 질문이 아닙니다. 그것은 질문의 반대편입니다.
반경

일부 답변이 관련되어 있기 때문에 링크를 게시했습니다.
Andrioid

다른 포스터에서 큰 답변. 추가 할 것이 많지는 않지만 ".. 혜택이 추가 비용을 정당화하는 데 큰 도움이되지 않는 경우"라고 말하면 직업이 위험하다는 사실을 깨닫지 못할 수 있습니다. 직업을 위태롭게 할 가치가있는 수백 달러를 절약하고 있습니까? 회사와 경력에 대한 완전한 재앙을 피하기 위해 상대적으로 적은 금액을 지출했다면 아무도 당신을 덜 생각하지 않을 것입니다. 내 두 센트.
osij2은

답변:


16

이모, 레이드를 사용하면 큰 이점이 있습니다.

백업 시스템에 RAID없이 디스크 오류가 발생하면 모든 백업이 손실됩니다. 재건하는 데 얼마나 걸립니까?

또한 디스크 장애로 인해 모든 백업을 잃어 버렸다가 성공적으로 다시 빌드 한 다음 이전에 백업되었지만이 디스크 오류의 원인이 손실 된 항목을 찾아야하는 경우 어떻게해야합니까?

다른 방법이 없다면 디스크가 너무 저렴하여 시스템을 RAID 5에 배치하기위한 추가 디스크 비용으로 인해 장애 복구에 필요한 경우보다 시간이 덜 소요될 수 있습니다.


1
특정 RAID 레벨이 제공하는 디스크 속도의 큰 장점은 말할 것도 없습니다. 백업을 다시 구축하는 경우 읽기 속도가 문제가 될 수 있으며 RAID5 또는 RAID10이 도움이됩니다.
Russ Warren

1
실제 디스크 용량이 너무 커서 동일한 RAID 구성이 약속 한대로 안전하지 않게되었습니다. 디스크가 큰 차원 일수록 디스크 당 실패 확률도 증가한다는 사실을 언급하고 있습니다.이 간단한 통계 사실은 디스크 장애 후 RAID 재구성이 살아남은 디스크도 죽게 만든다는 사실을 가능하게합니다. .. 완전 안전 RAID1 + HS를 완전히 신뢰할 수없는 시스템으로 만들기 ... 따라서 내결함성 RAID 시스템에 매우 큰 디스크를 사용하지 마십시오. hds.com/assets/pdf/…
drAlberT

11

서버 컴퓨터에는 매우 특별한 상황을 제외하고 중복 디스크가 있어야합니다 (Google과 같은 "스케일 아웃"1U 응용 프로그램 서버 랙 이후의 랙 생각). 중복 디스크가없는 서버 컴퓨터는 시한 폭탄입니다.

즉, 오프 사이트 및 오프라인이 아닌 한 백업은 백업되지 않습니다. 현장에 있지만 오프라인 상태 인 경우 (서랍에서 테이핑 됨) 건물이 타 버리면 사라집니다 ( 서버에서 그을음 청소 참조 ). 오프 사이트이지만 온라인 상태 인 경우 공격 및 "부패"에 취약합니다.

이제 디스크 대 테이프 등에 대한 종교적 주장에 계속 관심을 기울이십시오.


디스크 + 테이프. 둘 다 다른 것보다 낫지는 않습니다. 디스크는 주 서버와 백업 미디어 서버에서 백업을 수행하는 데 더 빠릅니다. 다운 타임 창을 짧고 예측 가능하게 유지할 수 있습니다. 로봇 # 1, 드라이브 # 0을 사용할 수 있다고 보장 할 수 없습니다. 오프 사이트에는 테이프가 더 좋습니다. 나는 특히 VTL을 신경 쓰지 않습니다. 여기 blob이 있습니다. 여기에 blob에 1000 개의 데이터 세트가 있으며 테이프에 효율적으로 정렬합니다. (NetBackup 6.5는 이것을 잘 수행합니다).
Chris K

1
"모든 것이 다른 것보다 낫다"고 동의했다. 디스크 투 디스크는 백업 창을 축소하고 빠른 복원을 수행하는 데 유용합니다. 그러나 오프 사이트 및 오프라인으로 데이터를 가져 오는 것은 테이프가 뛰어난 곳입니다. Disk-to-disk-to-tape는 오늘날 백업에서 가장 일반적인 "스위트 스폿"입니다 (가능한 경우 중복 제거 단계가 수행됨).
Evan Anderson

디스크-> 오프 사이트 디스크 디스크-> 온 사이트 디스크를 사용합니다. 모든 백업을 편리하게 수행 할 수 있습니다. 불행히도 대역폭 비용으로 인해 많은 경우에 가능하지 않습니다.
Cian

7

RAID-10을 사용하십시오.

RAID-5는 다음과 같은 이유로 백업 서버에 적합하지 않습니다.

  • 서버는 유휴 상태가 아닌 대부분의 수명을 많은 순차적 쓰기 작업에 소비합니다. 성능 문제.
  • 디스크 사용률은 시간이 지남에 따라 증가하는 경향이 있으므로 백업 윈도우가 걱정되는 것이 아니라면 앞으로있을 것입니다.
  • 다운 된 디스크로 작동하면 성능이 저하되어 백업이 실패합니다.
  • 대용량 SATA 디스크를 사용할 수 있기 때문에 RAID-5 ( "디스크가 너무 비싸고, wah, wah")를 사용하는 일반적인 변명은 백업을위한 총 2 %입니다.
  • 임의 I / O 워크로드가 상대적으로 작기 때문에 SATA 대 SAS는 백업에 덜 중요합니다.

백업을 사실상 아카이빙 솔루션으로 사용하는지 여부에 따라 RAID를 전혀 사용하지 않을 수 있습니다.


백업의 성능 측면에 완전히 동의하십시오. 내 백업 서버는 현재 RAID-5이고 성능이 끔찍하며 RAID-10을 전환하는 것은 즐겁지 않습니다.
Dan

4

어떤 비용? 하드 드라이브는 저렴하며 Raid 1은 현재 마더 보드에서 거의 표준입니다.

제 생각에는 너무 조심할 수 없습니다. 나는 주 개발 시스템을 습격하고 정기적으로 홈 서버에 백업을하고 홈 서버는 매일 밤 오프 사이트 백업을합니다. 저렴하고 쉽고 완벽하다면 왜 안되 겠어요?


3

오늘날에는 여러 수준의 백업, 니어 라인 및 오프 사이트가 있습니다. 니어 라인은 디스크를 백업하는 곳입니다. 여기서는 백업 서버 디스크에서 테이프로 복사 한 다음 테이프를 오프 사이트로 보내는 동안 매우 중요한 데이터의 여러 백업 세트를 가까이 둘 수 있습니다. 여기에는 몇 가지 이점이 있습니다.

  1. 디스크 백업이 일반적으로 빠릅니다
  2. 사실상 디스크에 제한이없는 디스크 장치 수는 테이프에 백업하는 것이 일반적으로 한 번에 작성해야하는 헤드 수로 제한됩니다.

즉, 백업 서버 디스크를 데이터베이스 서버와 동일한 종류의 중복으로 처리해야합니다. 정오에 데이터베이스 서버에 장애가 발생했다고 가정하면 지난 밤부터 디스크 사본의 백업 서버로 롤백하고 복원을 수행 할 수 있습니다.이 경우 테이프는 이미 오프 사이트 공급 업체로부터 $ 250의 긴급 반환 일 수 있습니다.

RAID가 아닌 RAID-0 크랩이 아닌 IMHO를 실행하는 모든 서버에 RAID를 배치해야합니다. :-)


Anecodote : 데이터 센터를 이동할 때 일부 드라이브가 데이터베이스 서버에서 실패했습니다. 시스템을 계속 사용하기에 충분한 위험으로 판명되었습니다. 따라서 네트워크를 통해 디스크 공간이있는 다른 서버로, 다른 하나는 외부 디스크로 두 개의 사본을 만들었습니다. 글쎄, 어레이가 나쁘다는 것을 알았으며 네트워크 사본 만 가져 왔습니다 (SCSI-> 이더넷으로가는 것이 SCSI-> SCSI를 이길 것임을 알고 있음). 두 개의 다른 시스템에서 두 개의 디스크를 한 번에 잃어 버릴 염려가 없다고해서 일어날 가능성은 없습니다.
Chris K

2

예, 그냥하세요 하드 드라이브는 다른 컴퓨터 구성 요소보다 여러 번 실패 할 가능성이 높습니다. RAID로 이동하면 발생할 가능성이 가장 높은 하나의 문제로부터 보호 할 수 있습니다. 데이터 가치에 따라 RAID 설정의 한계 비용 (아마도 중간 서버를 가정 할 경우 500 달러 미만)을 측정하십시오.

나는 에반 앤더슨이 말한 것을 두 번째로 말했다. 절대적으로 유일한 백업이되어서는 안됩니다. Evan은 오프 사이트 및 오프라인에 대해 이야기했으며 그 목록에 중복성을 추가하려고합니다. 백업 미디어 장애, 백업 작업, 도난, 손실, 미디어 손실 등의 경우 백업 사본이 여러 개 있어야합니다.


2

백업 서버에서 RAID를 사용해야합니까?

중복성을 위해, 나는하지 않을 것이다

백업 시스템 파일의 특정 개정 버전을 복원하지 않으려는 경우 백업 시스템 디스크에 장애가 발생한 경우이를 수정해야 할 수도 있습니다. 그런 다음 RAID 5 또는 미러링 또는 스트라이핑 및 미러링을 사용합니다.

최악의 시간에 원본 데이터를 사용할 수 없을 것으로 예상되는 경우이를 수행하는 유일한 이유입니다.

디스크를 하나의 볼륨으로 확장 (스트라이핑)

하나의 디스크가 죽으면 전체 어레이가 죽을 수도 있습니다.

결론

백업 서버를 백업하는 것이 더 나은 방법이라고 생각합니다. 나는 그것이 어리석게 들린다는 것을 안다. 시스템 디스크, 구성 파일 및 백업 설정을 백업하십시오. 이렇게하면 백업 서버에 장애가 발생하면 최대한 빨리 가동 할 수 있습니다.

(편집 : 미안, 다른 답변에 대해서는 질문을 잘못 읽었습니다)


1

테이프가 아닌 서버에 데이터를 저장할 계획이므로 백 서버에서 RAID를 사용하는 것이 좋습니다.

RAID 5, 1 또는 10을 권장합니다.

이런 식으로 생각하면 하드 드라이브가 실패합니다. 올바른 RAID 설정을 사용하면 이러한 상황이 발생했을 때 데이터가 손실되지 않습니다. 고장난 하드 드라이브를 교체하고 RAID를 재 구축하십시오.

하드 드라이브가 죽을 때 (어느 시점에서 죽을 때) RAID 보호 기능이 없으면 백업이 손실됩니다.


1

이것은 '백업'에 대해 어떻게 생각 하느냐에 달려 있습니다.

"라이브"데이터가있는 서버를이 서버의 다른 서버에서 복제하는 것이 목표라면이 백업 서버에서 레이드를 사용하는 것은 거의 쓸모가 없습니다. 데이터를 잃어 버리더라도 서버에서 데이터를 계속 사용할 수 있습니다. 이 경우 디스크에 장애가 발생하면 짧은 시간 내에 백업 서버를 온라인으로 되돌릴 수 있도록 여분의 디스크가 필요합니다.

목표는 시간에 백업을 아카이브하는 것입니다. 매일 백업하는 것을 의미하며 한 달, 1 년 정도 보관하십시오. 그렇다면 디스크를 잃어 버리면 아카이브를 잃어 버리기 때문에 레이드를 사용하려고합니다. X 주 전 백업에서 데이터를 복원 할 수 있어야하는 경우이 '백업 / 아카이브'를 다른 서버 나 테이프에 백업 할 수도 있습니다 (테이프는 오랜 시간 동안 보관하는 것이 좋습니다). )


0

프로덕션 서버와 백업 서버 하드 디스크가 동시에 실패 할 가능성은 무엇입니까? 그들이 정신적으로 분리되어 있다면 (즉, 같은 전력망에 있지 않은 등)이 기회는 실제로 매우 낮습니다. 그래서 나는 RAID에 투표하지 않습니다.

물론 백업 서버에 장애가 발생했을 때 경고가 표시되는지 확인하십시오.


1
프로덕션 서버와 백업 서버의 드라이브가 동일한 배치에있는 경우 어떻게합니까? 기회가 크게 증가합니다.
Lazlow

0

이미 언급 한 내용에 동의하지만 패리티가있는 RAID를 사용하는 경우 드라이브 및 백업 데이터의 상태를 모니터링하는 방법이 있습니다. 대부분의 어댑터 또는 온보드 컨트롤러는 syslog, Windows 이벤트 또는 이메일을 통해 경고를 보냅니다.

SMART가 고장난 드라이브를보고 할 때이 상자가 단순히 Windows 이벤트를 발생 시키면 너무 늦습니다.

백업을 다시 실행하는 것은 RAID 컨트롤러와 몇 개의 추가 SATA 드라이브보다 시간이 많이 걸립니다 (시간당 비용).

미디엄.


0

디스크 백업은 가치가 있습니다. 나는 논쟁의 테이프쪽에 단단히 있습니다. 그러나 백업 볼륨이 중복성이없는 단일 디스크 인 경우 결국 모든 데이터를 잃게됩니다. 디스크가 결국 실패하기 때문입니다.

디스크 백업이 실제로 적합한 솔루션인지 여부에 대한 백업 요구의 특성에 달려 있다고 생각합니다. 오프 사이트에서 데이터를 필요로하지 않고 재해 복구 또는 오랜 시간 동안 데이터의 생존 가능성을 신경 쓰지 않는다면 테이프가 필요하지 않습니다. 디스크에서 절대 떨어지지 않고 데이터 센터를 떠나지 않는 백업이 확실히 있지만 사용자 삭제 오류를 수정하기 위해 있습니다.

또한 테이프 용량을 어떻게 능가합니까? 그것이 테이프의 아름다움입니다. 항상 다른 테이프를 얻을 수 있습니다. 그래도 일종의 테이프 체인저가 필요합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.