Máy chủ dự phòng có nên sử dụng RAID?


17

Tôi đã được yêu cầu thiết lập một máy chủ sao lưu mới bằng Symantec Backup Exec lưu trữ vào đĩa cứng thay vì băng, vì kích thước sao lưu vượt quá dung lượng băng.

Tôi đã tự hỏi liệu nó thực sự có ý nghĩa hay có bất kỳ lợi thế nào cho máy chủ sao lưu để chạy RAID dưới bất kỳ hình thức nào vì nó là "bản sao lưu"?

Đối với tôi, lợi ích không phải là tuyệt vời để biện minh cho chi phí gia tăng.

Tôi quan tâm để xem những gì người khác nghĩ.

Cảm ơn!



1
Điều này, theo quan điểm của tôi, không thực sự giống như câu hỏi khi anh ta hỏi "liệu có lý do nào để sử dụng đột kích trên máy chủ dự phòng" không "sử dụng đột kích làm bản sao lưu". Nó gần như là mặt trái của câu hỏi.
bán kính

Tôi đồng ý, chỉ đăng liên kết vì một số câu trả lời có liên quan.
Andrioid

Câu trả lời tuyệt vời từ các áp phích khác. Tôi không có nhiều thứ để thêm, nhưng tôi sẽ lập luận rằng nếu ".. lợi ích không lớn để biện minh cho chi phí gia tăng.", Bạn có thể không nhận ra mình đang mạo hiểm với công việc của mình. Là tiết kiệm vài trăm đô la có giá trị gây nguy hiểm cho công việc của bạn? Không ai nghĩ ít về bạn nếu bạn bỏ ra một số tiền tương đối ít để tránh một thảm họa hoàn toàn cho công ty và sự nghiệp của bạn. Chỉ hai xu của tôi.
osij2is

Câu trả lời:


16

Imo, có một lợi ích to lớn khi sử dụng đột kích.

Nếu máy sao lưu bị lỗi đĩa mà không đột kích thì bạn sẽ mất tất cả các bản sao lưu. Bạn sẽ mất bao lâu để xây dựng lại chúng?

Ngoài ra, điều gì sẽ xảy ra nếu bạn mất tất cả các bản sao lưu do lỗi đĩa, xây dựng lại thành công và sau đó cần tìm một cái gì đó đã được sao lưu trước đó nhưng bị mất do lỗi đĩa này.

Nếu không có gì khác, các đĩa bây giờ rẻ đến mức chi phí cho một đĩa phụ để đưa hệ thống vào đột kích 5 có thể sẽ tốn ít hơn thời gian của bạn trong trường hợp bạn cần phục hồi sau thất bại.


1
Chưa kể những lợi thế to lớn về tốc độ ổ đĩa mà các cấp RAID nhất định mang lại. Nếu bạn đang xây dựng lại bản sao lưu, tốc độ đọc có thể là một vấn đề và RAID5 hoặc RAID10 sẽ giúp ích.
Russ Warren

1
Xin lưu ý rằng dung lượng đĩa thực tế được cung cấp lớn đến mức các cấu hình RAID tương tự trở nên không an toàn như họ hứa. Tôi đang đề cập đến thực tế là việc có một kích thước lớn của một đĩa cũng có xác suất thất bại tăng lên (theo từng lĩnh vực) .. thực tế thống kê đơn giản này có thể xảy ra rằng việc tái tạo RAID sau khi hỏng đĩa cũng khiến đĩa còn sống cũng chết. .. làm cho RAID1 + HS siêu an toàn trở thành một hệ thống hoàn toàn không đáng tin cậy ... Vì vậy, đừng sử dụng các đĩa rất lớn cho hệ thống RAID chịu lỗi của bạn. Xem hds.com/assets/pdf/ từ
drAlberT

11

Các máy tính của máy chủ nên có các đĩa dự phòng ngoại trừ trong các trường hợp rất đặc biệt (nghĩ rằng giá đỡ sau khi "mở rộng" các máy chủ ứng dụng 1U, như Google). Một máy tính máy chủ không có đĩa dự phòng là một quả bom hẹn giờ.

Điều đó đã được nói, sao lưu không phải là sao lưu trừ khi nó tắt trang web và ngoại tuyến. Nếu nó tại chỗ nhưng ngoại tuyến (băng trong ngăn kéo) thì nó sẽ biến mất khi tòa nhà bị cháy (xem Làm sạch bồ hóng ra khỏi máy chủ ). Nếu nó ở ngoài trang web nhưng trực tuyến thì nó dễ bị tấn công và "tham nhũng".

Và bây giờ, hãy theo dõi các tranh luận tôn giáo về đĩa so với băng, v.v.


Đĩa + Băng. Không cái nào tốt hơn cái kia cho mọi thứ. Đĩa nhanh hơn để nhận các bản sao lưu từ các máy chủ chính và vào các máy chủ phương tiện sao lưu - nó cho phép bạn giữ cho các cửa sổ thời gian chết của bạn ngắn và có thể dự đoán được. Bạn không thể đảm bảo khi robot số 1, ổ đĩa số 0 sẽ có sẵn. Băng là tốt hơn cho ngoại vi. Tôi không đặc biệt quan tâm đến VTL, tôi thích đây là một blob, đây là 1000 bộ dữ liệu trong blob, sắp xếp tất cả chúng một cách hiệu quả trên băng cho tôi. (NetBackup 6.5 làm tốt điều này).
Chris K

1
Đồng ý lại: "không tốt hơn cái kia cho mọi thứ". Tôi với bạn-- đĩa-to-đĩa là tuyệt vời để thu nhỏ các cửa sổ sao lưu và khôi phục nhanh. Tuy nhiên, việc lấy dữ liệu ngoại vi và ngoại tuyến là nơi băng vượt trội. Đĩa-to-đĩa-to-băng là "điểm ngọt" tốt nhất trong sao lưu hiện nay (với một bước lặp lại trong đó, nếu bạn có đủ khả năng).
Evan Anderson

Chúng tôi sử dụng đĩa -> đĩa ngoại vi đĩa -> đĩa tại chỗ. Làm cho tất cả các bản sao lưu tiện dụng để có được tại. Không thể trong nhiều trường hợp, nhờ vào chi phí băng thông không may.
Cian

7

Sử dụng RAID-10.

RAID-5 bị câm cho các máy chủ dự phòng, bởi vì:

  • Máy chủ dành phần lớn thời gian không hoạt động của nó để thực hiện nhiều và rất nhiều lần viết liên tiếp. Vấn đề hiệu suất.
  • Việc sử dụng đĩa có xu hướng tăng theo thời gian, vì vậy nếu các cửa sổ sao lưu không phải là điều bạn lo lắng bây giờ, chúng có thể sẽ có trong tương lai.
  • Hiệu suất mà bạn nhận được từ việc vận hành với một đĩa bị giảm sẽ khiến các bản sao lưu không thành công.
  • Lý do thông thường để sử dụng RAID-5 ("đĩa rất đắt, wah, wah") là 100% tổng số bunk để sao lưu, vì bạn có thể sử dụng đĩa SATA dung lượng cao.
  • SATA so với SAS ít quan trọng hơn để sao lưu, vì khối lượng công việc I / O ngẫu nhiên của bạn tương đối nhỏ.

Không sử dụng RAID hoàn toàn có thể được chấp nhận, tùy thuộc vào việc bạn có đang sử dụng bản sao lưu của mình như một giải pháp lưu trữ thực tế hay không.


Hoàn toàn đồng ý về khía cạnh hiệu suất của các bản sao lưu. Máy chủ dự phòng của tôi hiện là RAID-5, hiệu năng rất tệ và việc chuyển đổi RAID-10 sẽ không vui chút nào.
Dan

4

Giá bao nhiêu? Ổ cứng có giá rẻ và Raid 1 là tiêu chuẩn khá nhiều trên bo mạch chủ.

Theo tôi bạn không thể quá cẩn thận. Tôi đã đột kích vào máy phát triển chính của mình, tôi thường xuyên tạo các bản sao lưu cho máy chủ nhà của mình và máy chủ nhà của tôi tạo một bản sao lưu ngoại vi mỗi đêm. Nếu nó rẻ, dễ dàng và liền mạch tôi nói tại sao không?


3

Ngày nay có nhiều cấp độ sao lưu, gần tuyến và ngoại vi. Đường gần là nơi bạn sao lưu vào đĩa. Tại đây, bạn có thể giữ nhiều bộ sao lưu dữ liệu cực kỳ quan trọng ở gần, trong khi một bản sao được tạo từ các đĩa máy chủ sao lưu thành băng và sau đó băng được gửi bên ngoài. Điều này có một số lợi ích:

  1. sao lưu vào đĩa thường nhanh hơn
  2. Bạn có số lượng thiết bị đĩa không giới hạn một cách hiệu quả, trong đó việc sao lưu vào băng thường bị hạn chế về số lượng đầu bạn phải ghi tại một thời điểm.

Điều đó nói rằng, bạn nên đối xử với các đĩa máy chủ sao lưu của mình với cùng loại dự phòng bạn xử lý máy chủ cơ sở dữ liệu của mình. Giả sử máy chủ cơ sở dữ liệu của bạn bị lỗi vào buổi trưa, bạn có thể quay trở lại bản sao của máy chủ sao lưu từ tối qua và thực hiện khôi phục, trong đó băng của bạn có thể là một khoản hoàn trả khẩn cấp $ 250 từ nhà cung cấp ngoại vi của bạn.

Bạn nên đặt RAID trên mọi máy chủ mà bạn chạy, IMHO, và không phải là crap RAID-0 không phải RAID. :-)


Giai thoại: khi di chuyển một trung tâm dữ liệu, một số ổ đĩa của chúng tôi đã bị lỗi trong máy chủ Cơ sở dữ liệu của chúng tôi. Hóa ra là đủ rủi ro để tiếp tục sử dụng hệ thống. Vì vậy, chúng tôi đã tạo hai bản sao, một bản qua mạng đến một máy chủ khác có không gian đĩa và một bản khác cho một số đĩa bên ngoài. Chà, hóa ra mảng rất tệ và chúng tôi chỉ có được bản sao mạng (ai biết đi SCSI-> Ethernet sẽ đánh bại SCSI-> SCSI). Chỉ vì bạn không có khả năng mất hai đĩa trên hai hệ thống khác nhau cùng một lúc không có nghĩa là điều đó không có khả năng xảy ra.
Chris K

2

Vâng, chỉ cần làm điều đó. Một ổ cứng có khả năng bị lỗi nhiều lần hơn bất kỳ thành phần máy tính nào khác. Bằng cách truy cập RAID, bạn sẽ bảo vệ khỏi một vấn đề rất có thể xảy ra. Đo chi phí cận biên của thiết lập RAID (có thể dưới 500 đô la, giả sử máy chủ cấp thấp đến trung bình) với giá trị dữ liệu của bạn.

Phải nói rằng, tôi thứ hai những gì Evan Anderson đã nói ở trên. Điều này tuyệt đối KHÔNG nên là bản sao lưu duy nhất của bạn. Evan đã nói về việc ở ngoài trang web và ngoại tuyến, và tôi sẽ thêm sự dư thừa vào danh sách đó. Bạn cần có nhiều bản sao lưu dự phòng trong trường hợp không có phương tiện sao lưu, công việc sao lưu, mất cắp, mất phương tiện, bị rơi, v.v.


2

Bạn có nên sử dụng RAID trên một máy chủ sao lưu?

Để dự phòng, tôi sẽ không

Nếu bạn không có thói quen khôi phục các bản sửa đổi cụ thể của các tệp trong hệ thống sao lưu của mình và bạn sợ rằng bạn có thể phải làm điều đó trong trường hợp các đĩa hệ thống sao lưu bị lỗi. Sau đó, tôi sẽ sử dụng RAID 5 hoặc phản chiếu hoặc thậm chí phân loại và phản chiếu.

Lý do duy nhất để làm điều này nếu bạn cho rằng dữ liệu gốc có thể không có sẵn tại thời điểm tồi tệ nhất có thể.

Để mở rộng đĩa thành một ổ đĩa (tước)

Có thể, nhưng lưu ý rằng nếu một đĩa chết thì toàn bộ mảng sẽ chết.

Dòng dưới cùng

Tôi nghĩ rằng đó là một thực hành tốt hơn để sao lưu máy chủ sao lưu. Tôi biết nó nghe có vẻ ngớ ngẩn, nhưng chịu đựng tôi. Sao lưu đĩa hệ thống, tập tin cấu hình và cài đặt sao lưu. Bằng cách đó, nếu máy chủ sao lưu của bạn bị lỗi, bạn có thể lên càng sớm càng tốt.

(Chỉnh sửa: xin lỗi, về câu trả lời khác, tôi đọc sai câu hỏi)


1

Hoàn toàn có ý nghĩa khi sử dụng RAID trên máy chủ trở lại của bạn vì bạn có kế hoạch lưu trữ dữ liệu trên máy chủ chứ không phải băng.

Tôi muốn giới thiệu RAID 5, 1 hoặc 10.

Hãy nghĩ về nó theo cách này, ổ cứng sẽ thất bại. Với thiết lập RAID phù hợp, bạn được bảo vệ chống mất dữ liệu khi điều này xảy ra. Bạn thay thế ổ cứng bị lỗi và xây dựng lại RAID.

Nếu không có bảo vệ RAID khi ổ cứng của bạn chết (tại một thời điểm nào đó nó sẽ chết) thì bạn đã mất bản sao lưu của mình.


1

Điều này phụ thuộc nhiều vào những gì bạn nghĩ về 'sao lưu'.

Nếu mục tiêu chỉ là có một máy chủ có dữ liệu "sống" trùng lặp với các máy chủ khác trên máy chủ này, thì việc sử dụng đột kích trên máy chủ sao lưu này gần như vô dụng, nếu bạn mất nó, dữ liệu vẫn có sẵn trên các máy chủ. Trong trường hợp này, bạn chỉ cần có một số đĩa dự phòng để có thể làm cho máy chủ sao lưu trực tuyến trở lại trong một thời gian ngắn nếu một đĩa bị lỗi.

Nếu mục tiêu là lưu trữ sao lưu trong thời gian. Tôi có nghĩa là thực hiện sao lưu hàng ngày, và giữ nó trong một tháng, một năm hoặc lâu hơn. Sau đó, có, bạn muốn sử dụng đột kích vì nếu bạn mất đĩa, bạn sẽ mất lưu trữ. Nếu điều quan trọng đối với bạn là có thể khôi phục dữ liệu từ bản sao lưu X tuần trước, bạn cũng có thể sao lưu 'bản sao lưu / lưu trữ' này sang máy chủ khác hoặc băng (lưu trữ băng rất tốt trong thời gian dài lưu trữ) (và tất nhiên là rất xa )


0

Tỷ lệ cược của máy chủ sản xuất và máy chủ sao lưu đĩa cứng bị lỗi cùng một lúc là gì? Nếu chúng bị tách biệt về mặt tâm lý (tức là không nằm trên cùng một lưới điện, v.v.) thì cơ hội này thực sự rất thấp. Vì vậy, tôi bỏ phiếu cho không có RAID.

Tất nhiên, đảm bảo bạn có thông báo khi máy chủ dự phòng bị lỗi.


1
Điều gì nếu các ổ đĩa trong cả máy chủ sản xuất và sao lưu là từ cùng một đợt? Cơ hội được tăng lên rất nhiều.
Lazlow

0

Tôi đồng ý với những gì đã được nói, nhưng nếu bạn đang sử dụng một cuộc đột kích ngang bằng thì sẽ có cách theo dõi sức khỏe của các ổ đĩa và dữ liệu sao lưu của bạn. Hầu hết các bộ điều hợp hoặc bộ điều khiển trên tàu sẽ gửi cảnh báo qua syslog, sự kiện windows hoặc email.

Nếu hộp này chỉ đơn giản là sẽ ném một sự kiện windows khi SMART báo lỗi ổ đĩa bị lỗi thì đã quá muộn.

Việc làm lại các bản sao lưu phải mất nhiều thời gian hơn (chi phí nhân công) so với bộ điều khiển đột kích và một vài ổ đĩa SATA bổ sung.

M ..


0

Sao lưu vào đĩa có giá trị. Trong khi tôi chắc chắn về phía băng của cuộc tranh luận. Tôi sẽ nói điều này tuy nhiên, nếu khối lượng sao lưu của bạn là các đĩa đơn không có dự phòng, cuối cùng bạn sẽ mất tất cả dữ liệu của mình. Bởi vì đĩa của bạn cuối cùng sẽ thất bại.

Tôi cho rằng nó phụ thuộc vào bản chất của nhu cầu sao lưu của bạn là liệu sao lưu vào đĩa có thực sự là một giải pháp phù hợp hay không. Nếu bạn không cần dữ liệu ngoài trang web và bạn không quan tâm đến việc khắc phục thảm họa hoặc khả năng tồn tại của dữ liệu trong một thời gian dài thì băng không cần thiết. Tôi chắc chắn có các bản sao lưu không bao giờ thoát khỏi đĩa và không bao giờ rời khỏi trung tâm dữ liệu, nhưng chúng ở đó để sửa lỗi xóa người dùng.

Ngoài ra làm thế nào để bạn vượt quá khả năng băng? Đó là vẻ đẹp của băng, bạn luôn có thể lấy một cuộn băng khác. Điều đó không yêu cầu bạn phải có một bộ thay đổi băng nào đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.