Lập kế hoạch cho thảm họa


18

Tôi làm việc cho một công ty tiếp thị nhỏ cũng chuyên thiết kế và phát triển web. Chúng tôi lưu trữ tất cả các khách hàng thiết kế và phát triển web của chúng tôi trên một máy chủ chuyên dụng tại Hostgator. Chúng tôi có một máy chủ chuyên dụng với các ổ cứng được cấu hình RAID 1. Chúng tôi cũng thực hiện sao lưu hàng tuần được tự động hóa thông qua cPanel và được tải xuống bằng phần mềm FTP tự động cục bộ.

Hôm nay chúng tôi đã thảo luận về những gì chúng tôi sẽ làm nếu Hostgator có một thất bại thảm hại của một số loại. Đó có thể là máy chủ phát nổ, Hostgator gặp sự cố nghiêm trọng về mạng, FBI đã thực hiện một trong những cuộc tấn công "lấy mọi máy chủ" nổi tiếng của họ, v.v. Về cơ bản, mọi tình huống đều xảy ra khi mất điện kéo dài. Sau đó, chúng tôi đã đưa nó lên cấp độ tiếp theo và tự hỏi chúng tôi sẽ làm gì nếu Hostgator bị mất điện kéo dài và chúng tôi không thể truy cập vào các bản sao lưu cục bộ của mình. Điều này có thể là do hỏa hoạn, lũ lụt, v.v. Tôi biết rằng tỷ lệ máy chủ của chúng tôi bị ngừng hoạt động trong thời gian dài các tệp cục bộ của chúng tôi không thể truy cập được từ xa nhưng tất cả chỉ mất hainhững điều tồi tệ sẽ xảy ra và đó là nơi chúng ta sẽ đứng. (Nếu bạn đã từng bị xẹp lốp và phát hiện ra phụ tùng của bạn bị xẹp hoặc thiếu, bạn biết việc hai điều xấu xảy ra đồng thời thực sự dễ dàng như thế nào).

Không cần phải nói rằng chúng tôi muốn chuẩn bị cho các sự kiện loại "trường hợp xấu nhất" vì điều này gần như chắc chắn sẽ khiến chúng tôi không hoạt động. Vì vậy, hai câu hỏi của tôi là:

  1. Chúng ta có thể làm gì để chuẩn bị cho sự cố mất điện kéo dài bởi Hostgator? Một kịch bản lý tưởng sẽ có các trang web của khách hàng của chúng tôi và hy vọng email, sẽ được chạy lại nhanh chóng.

  2. Điều gì sẽ là một kế hoạch sao lưu mạnh mẽ bao gồm dữ liệu quan trọng không bao giờ bị mất? Một giải pháp lý tưởng sẽ được tự động hóa.

Bạn có thể cho rằng chi phí không phải là một vấn đề trong câu trả lời của bạn nhưng giải pháp càng hợp lý thì càng tốt.


Có vẻ như các câu trả lời ở đây đã bao gồm rất nhiều nền tảng tốt. Tôi có thể xác nhận rằng Amazon đám mây đã rất kinh tế như là một giải pháp sao lưu cho đến thời điểm này. Không cần biết tương lai sẽ ra sao, nhưng nếu không có gì khác, đó là một cách tốt để tìm hiểu cách thức hoạt động của đám mây.
JMC

Dưới đây là chi phí ước tính cho máy tính AWS nếu bạn đã không chạy qua được chưa: calculator.s3.amazonaws.com/calc5.html
JMC

@ John Conde: kinh nghiệm của bạn với HostGator là gì, có thời gian chết lớn nào không? Nếu có thì thời gian chết lớn mà bạn nhớ là bao lâu?
Marco Demaio

@Marco Demaio, chúng tôi không có thời gian chết nào với Hostgator. Họ đã cực kỳ đáng tin cậy và sự hỗ trợ của họ thật tuyệt vời.
John Conde

Câu trả lời:


15

Tôi muốn đề nghị bạn:

  1. Tự động phản chiếu toàn bộ nội dung và cấu hình của máy chủ chính của bạn sang máy chủ dự phòng thứ cấp trên một mạng hoàn toàn riêng biệt trong một trung tâm dữ liệu khác. Sử dụng RSync, FXP, cPanel voodoo hoặc bất kỳ phương pháp nào bạn muốn để tự động đồng bộ hóa.

  2. Sử dụng chuyển đổi dự phòng DNS để tự động định tuyến lưu lượng đến máy chủ dự phòng nếu máy chủ Hostgator chứng minh không phản hồi.

Điều này có nghĩa là bạn liên tục có một bản sao lưu 'nóng' đang chờ để xảy ra nếu điều tồi tệ nhất xảy ra, thay vì một bản sao lưu 'lạnh' đòi hỏi phải can thiệp thủ công và nhiều tranh giành xung quanh và hoảng loạn. Điều đó cũng có nghĩa là khách hàng của bạn sẽ không bao giờ biết rằng trang web của họ bị sập trước khi bạn làm điều đó có thể gây phiền toái cho mọi người.

Bạn có thể thiết lập DNS failover bằng cách sử dụng nhà cung cấp như DNS Made Easy . Đối với mỗi tên miền bạn đang lưu trữ, bạn sẽ thiết lập tối đa năm địa chỉ IP dự phòng, một địa chỉ cho mỗi máy chủ dự phòng của bạn. Khi đã xong ...

  1. DNS Made Easy kiểm tra máy chủ chính của bạn từ hai đến bốn phút và nếu không phát hiện ra phản hồi, nó sẽ định tuyến lưu lượng đến địa chỉ IP phụ.

  2. DNS Made Easy tiếp tục kiểm tra máy chủ chính. Khi nó xuất hiện, nó sẽ định tuyến lại lưu lượng truy cập đến máy chủ đầu tiên, hoặc nếu bạn muốn giữ nó ở bản sao lưu trong khi bạn chẩn đoán lỗi và sửa máy chủ chính.

Tất nhiên, giải pháp này sẽ tăng chi phí hoạt động của bạn, bằng cách nào đó bạn sẽ phải chuyển cho khách hàng, nhưng nếu bạn ở trong một ngành công nghiệp mà thời gian chết sẽ đưa bạn ra khỏi doanh nghiệp thì việc trả tiền cho một máy chủ dư thừa có lẽ đáng giá nó cho một lần nó tiết kiệm công ty.

Ngoài ra:

Nhân đôi, trùng lặp, trùng lặp

Bạn càng có nhiều bản sao lưu độc lập thì càng tốt. Tôi lưu trữ các bản sao lưu từ xa trên một ổ cứng cục bộ, được nhân đôi với một ổ cứng ngoài, vào Dropbox, một kho lưu trữ git và một tài khoản FTP từ xa. Không có cơ hội. Nhân đôi càng nhiều càng tốt. Nếu bạn phải khôi phục từ bản sao lưu thủ công, tốt hơn là nên có năm lựa chọn hơn là lựa chọn một. Chứng hoang tưởng bị đánh giá thấp.

Thực hành khôi phục lại các bản sao lưu bằng tay

Nếu bạn chưa bao giờ thử khôi phục từ một trong các bản sao lưu của mình, làm sao bạn biết rằng chúng hoạt động? Thật đáng để thực hiện các cuộc tập trận khẩn cấp để xem điều gì sẽ xảy ra nếu quy trình tự động của bạn thất bại.


CẬP NHẬT: Một vài dịch vụ khác mà tôi phát hiện ra gần đây đáng được đề cập liên quan đến sao lưu trang web, khắc phục thảm họa và duy trì thời gian hoạt động:

  • Cloudflare, người cung cấp các tính năng bảo mật và lưu trữ để duy trì trang web khi máy chủ của bạn gặp sự cố. (Họ phản chiếu trang web của bạn và phục vụ nó từ bộ đệm được phân phối toàn cầu thay vì từ máy chủ của bạn trực tiếp.)
  • Codeguard, người cung cấp sao lưu tự động và khôi phục mã trang web (chỉ FTP).
  • Site Auto Backup, người cung cấp sao lưu tự động và khôi phục mã trang web, dữ liệu email và thông tin MySQL thông qua các bản sao lưu cPanel. Lưu ý rằng điều này được điều hành bởi Hostgator, vì vậy nó không nhất thiết phải phù hợp nếu bạn cũng lưu trữ trang web của mình với họ, nhưng có thể giúp đỡ người khác.

Cloudflare nói riêng có vẻ hữu ích để tránh thời gian chết và nói chung là cải thiện khả năng phản hồi của trang web.


Tôi không biết cái gì đó như DNS dễ dàng tồn tại. Đó sẽ là một cách tuyệt vời để các trang web nhanh chóng được định tuyến lại trong trường hợp máy chủ chính bị sập.
John Conde

Chúng cũng tuyệt vời cho lưu trữ DNS nói chung. Tôi mua tên miền từ nhà đăng ký yêu thích của mình nhưng sử dụng DNS Made Easy để lưu trữ các bản ghi DNS. Họ có nhiều máy chủ tên trên toàn thế giới, vì vậy các trang web giải quyết nhanh, tải nhanh hơn lần đầu tiên và không bị hỏng khi máy chủ tên của nhà đăng ký của bạn bị sặc. Nó cũng không đắt lắm.
Nick

@Nick: ở đây họ nói chuyển đổi dự phòng DNS (Tôi nghĩ rằng dịch vụ mà bạn cung cấp trong DNS Made Easy) không được đề xuất: serverfault.com/questions/60553/ trộm Bạn nghĩ gì?
Marco Demaio

@Marco Họ có quyền chỉ ra rằng nó không phải là hoàn hảo, nhưng nó hoạt động rất tốt đối với tôi đối với một vài ứng dụng web nhỏ mà tôi quản lý.
Nick

1
Nhân tiện, Stack Exchange cũng sử dụng chuyển đổi dự phòng DNS. Trung tâm dữ liệu chính ở New Yourk, thứ cấp ở Oregon. meta.stackexchange.com/a/231138/238706 meta.stackexchange.com/q/207653/238706
Palec

6

Phục hồi thảm họa có thể là một nhiệm vụ lớn, đặc biệt là khi xử lý nhiều máy chủ, trang web và cơ sở dữ liệu. Hai mục chính cần tính đến với giải pháp bạn chọn là mục tiêu thời gian phục hồi (RTO) và mục tiêu điểm khôi phục (RPO).

RTO về cơ bản là kỳ vọng sẽ mất bao lâu cho đến khi các trang web được sao lưu. Nếu bạn có RTO một hoặc hai phút (hoặc ít hơn), thì bạn nên xem xét một giải pháp phù hợp với những gì Nick đề xuất liên quan đến việc sao chép các tệp và dữ liệu của bạn sang trung tâm dữ liệu thứ cấp và tự động chuyển đổi dự phòng DNS có thể được thực hiện với dịch vụ trả phí hoặc với phần cứng tại cả hai trung tâm dữ liệu (chẳng hạn như Trình quản lý lưu lượng toàn cầu BIG-IPtừ F5 Networks. Điều này có thể tốn kém, nhưng phần lớn phụ thuộc vào việc trả lời câu hỏi "Chi phí của thời gian chết là gì?" Nếu RTO của bạn là một vài giờ hoặc thậm chí vài ngày, thì bạn có thể xem xét các quy trình khắc phục thảm họa có thể liên quan đến thủ công nhiều hơn như đưa máy chủ trực tuyến, chuyển DNS, v.v. Tedious, nhưng chắc chắn có hiệu quả về chi phí nếu RTO của bạn cho phép điều đó.

RPO về cơ bản là tần suất sao lưu được thực hiện và số lượng dữ liệu bạn sẵn sàng mất trong trường hợp xảy ra thảm họa. Nếu thay đổi nội dung và / hoặc dữ liệu xảy ra thường xuyên, thì bạn có thể có RPO có thể là vài phút hoặc vài giờ và có thể xử lý sao chép thời gian thực hoặc sao lưu tần số cao. Nếu nội dung không thay đổi thường xuyên hoặc bạn có khách hàng không nhất thiết phải quan tâm rằng họ mất dữ liệu trong vài ngày, thì việc sao lưu của bạn có thể xảy ra ít thường xuyên hơn.

Như tôi đã đề cập, tôi đồng ý với hầu hết những gì Nick đã nói. Một lựa chọn khác bạn có thể muốn xem xét là sử dụng các dịch vụ dựa trên đám mây từ một trong những nhà cung cấp dựa trên đám mây lớn hơn như Rackspace hoặc Amazon. Cả hai nhà cung cấp này đặc biệt có cơ sở hạ tầng lớn để có thể xử lý bất kỳ thảm họa nào ném vào họ. Với một cái gì đó như trang web trên đám mây hoặc máy chủ đám mây (thuật ngữ được sử dụng bởi Rackspace), bạn có lợi thế là có thể mở rộng quy mô và không nhất thiết phải lo lắng về khía cạnh phần cứng vật lý của nó.

Rackspace cũng có các tùy chọn tùy chỉnh có sẵn, nơi bạn có thể kết hợp cơ sở hạ tầng của mình, có sự kết hợp của máy chủ đám mây, máy chủ vật lý và tệp đám mây như một phần của giải pháp. Một cách tiếp cận hỗn hợp có thể là một cái gì đó để xem xét tùy thuộc vào nhu cầu của khách hàng của bạn nếu bạn không muốn có một kích thước phù hợp với tất cả các phương pháp tiếp cận.

Nếu nó giúp, có một trang dành riêng cho việc khắc phục thảm họa trên trang Rackspace cũng có thể tìm thấy ở đây . (Cũng để ghi lại, tôi không liên kết với Rackspace, nhưng đã sử dụng dịch vụ của họ trong quá khứ).

Hy vọng điều này đã giúp.

EDIT : Nghĩ rằng điều này có thể giúp đỡ nếu bạn đang đánh giá các giải pháp đám mây. Các Báo cáo Magic Quadrant Gartner cho cơ sở hạ tầng và as a Service và Web Hosting có thể cung cấp cho bạn một số cái nhìn sâu sắc vào các nhà cung cấp giải pháp khác.


Tôi thậm chí không bao giờ xem xét việc sử dụng lưu trữ đám mây như một "máy chủ" sao lưu. Đó sẽ là một cách rất kinh tế để có một bản sao lưu sẵn sàng để đi nhanh chóng.
John Conde

2

Hoàn thành sao chép máy chủ tại một cơ sở khác của một công ty lưu trữ khác dường như là giải pháp rõ ràng nhất.

Các tập tin có thể được giữ đồng bộ với các công cụ như rsync và unison. Các bản sao lưu SQL cũng có thể được đồng bộ hóa và sau đó được tải lên db db bằng các tập lệnh.


1

Đảm bảo rằng bạn đang chạy kiểm soát phiên bản của tất cả mã của mình bằng kho lưu trữ mã nguồn (SVN hoặc GIT). Bạn đang sử dụng SVN hay GIT?

Bạn có thể nhận tài khoản (miễn phí hoặc trả phí) tại kho lưu trữ của bên thứ ba, như Project Locker và nếu bạn phiên bản tất cả mã của mình trong khi bạn đang làm việc, về cơ bản, bạn đã sao lưu tất cả vào kho lưu trữ của mình ở vị trí thứ ba . Do đó làm giảm thêm cơ hội của bạn (gần như không) mất tất cả công việc cùng một lúc.

Bạn có thể thực hiện các cam kết / kiểm tra SVN của mình thông qua dòng lệnh hoặc thông qua ứng dụng khách như Phiên bản (cho Mac) hoặc TortoiseSVN (cho Windows).


Chỉ có vấn đề với kho lưu trữ mã nguồn, nó không sao lưu cơ sở dữ liệu hoặc bất kỳ người dùng nào đã tải lên các tệp, v.v.
Daveo

Thật. Nhưng bạn có thể tạo một tệp kết xuất cơ sở dữ liệu của bạn và thêm nó vào kho lưu trữ. Bạn thậm chí có thể viết một kịch bản để biến nó thành một quá trình tự động. Với cơ sở dữ liệu hoặc không có, ít nhất một nơi nữa sẽ có mã và tài sản của bạn được sao lưu, với lợi ích chính là kiểm soát phiên bản trên tất cả những thứ đó.
Joel Glovier

Thật không may, chúng tôi không sử dụng kiểm soát phiên bản. Trong thực tế, trước khi tôi bắt đầu ở đây, tất cả các công việc đã được thực hiện trên trang web trực tiếp! Tôi đã có thể có được một môi trường phát triển được thiết lập tại địa phương để ít nhất thực tế đó chính thức bị khai tử.
John Conde
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.