Sao lưu SQL khác với sao lưu máy chủ hàng đêm thông thường như thế nào?

Bộ phận CNTT của chúng tôi sao lưu toàn bộ máy chủ mỗi đêm (phiên bản SQL Server được cài đặt trên máy chủ này), sẽ sao lưu máy chủ đó cũng như toàn bộ mạng, trong trường hợp xảy ra sự cố ...

Vì vậy, người quản lý của tôi đã hỏi tầm quan trọng của các bản sao lưu SQL đầy đủ, khác biệt và nhật ký của tôi so với bất cứ thứ gì mà bộ phận CNTT sao lưu? Để tiết kiệm nhiều dung lượng hơn trên máy chủ của chúng tôi thay vì giữ các tệp này trong một vài tuần và xóa chúng, cô ấy nghĩ rằng CNTT sẽ chỉ cung cấp chúng!

Tôi biết điều đó không đúng, vì tôi có thể khôi phục tối đa 30 phút cuối cùng với các bản sao lưu nhật ký của mình, CNTT khôi phục nó vào ngày hôm sau, nhưng đây có phải là sự khác biệt duy nhất?

Vì tôi lưu / gửi các tệp sao lưu cơ sở dữ liệu của mình đến cùng một máy chủ, CNTT sẽ khôi phục chúng nhưng nếu tôi không có các công việc sao lưu này trong kế hoạch bảo trì của mình thì CNTT chỉ có thể khôi phục phiên bản SQL mà không cần bất kỳ bảng, giao dịch nào của chúng tôi ... vv Tôi có nhận được điều này phải không?
Bất kỳ lời khuyên sẽ được thực sự đánh giá cao.

Sao lưu cơ sở dữ liệu cung cấp cho bạn khả năng khôi phục tại thời điểm (miễn là bạn có FULLmô hình khôi phục). Ngay cả khi nhân viên CNTT của bạn thực hiện sao lưu cứ sau vài phút, điều này cực kỳ khó xảy ra, bạn vẫn sẽ có một khoảng cách.

Sao lưu máy chủ không thay thế sao lưu cơ sở dữ liệu, chúng bổ sung cho chúng bằng cách "lưu trữ" các tệp sao lưu cơ sở dữ liệu lâu dài (tức là không chỉ ngày nay).

Cuối cùng, bạn và quản lý của bạn phải quyết định RPO của bạn (mục tiêu điểm khôi phục - bạn cần bao nhiêu để có thể phục hồi trong một vụ tai nạn). Chỉ với các bản sao lưu máy chủ hàng ngày và không có bản sao lưu cơ sở dữ liệu, bạn sẽ mất cả ngày làm việc trong trường hợp xấu nhất.

Chỉnh sửa : @Sting có một điểm hợp lệ trong các bản sao bóng đó (cơ chế được sử dụng nhiều nhất để tạo bản sao lưu máy chủ) không có khả năng sao chép chính xác đồng thời tất cả các tệp cơ sở dữ liệu của bạn (bao gồm các tệp nhật ký), có thể dẫn đến sự không nhất quán khi bạn khôi phục lại bản sao lưu. Chẳng hạn, nếu bản sao bóng đọc nhật ký giao dịch vài mili giây trước khi đọc tệp cơ sở dữ liệu, tệp cơ sở dữ liệu có thể chứa một giao dịch không được cam kết, nhưng vì giao dịch được cam kết một phần nghìn giây sau đó, nhật ký sẽ không có bất kỳ bản ghi nào về nó.

Có khả năng khôi phục các tệp mdf và ldf từ bản sao bóng sẽ không nhất quán trong giao dịch. Điều đó có nghĩa là, các khôi phục bóng này không tuân thủ các thuộc tính ACID cơ sở dữ liệu.

https://msdn.microsoft.com/en-us/l Library / aa480356.aspx

Rất có thể khôi phục có thể sẽ hoạt động, nhưng bạn sẽ tự hỏi những gì bạn thực sự nhận được. (Chưa kể, bạn sẽ được giao nhiệm vụ kiểm tra để đảm bảo các bản sao lưu / bản sao bóng của máy chủ hoạt động tốt trên từng máy chủ) Ngoài ra, không có cách nào để khôi phục nhật ký giao dịch đến một thời điểm như bạn có thể sử dụng SQL Server T -Bài tập tin RESTORE / STOPAT.

Cho đến khi các bản sao lưu / khôi phục Windows Server tuân thủ thử nghiệm ACID của SQL Server, ngành công nghiệp của chúng tôi không thể chấp nhận bất kỳ cơ hội nào.

Nói xong, tôi đã tham gia một số cuộc họp kỳ lạ nhất. Nếu bạn truyền đạt các vấn đề cho CNTT và họ dường như vẫn không quan tâm hoặc họ sẵn sàng chấp nhận rủi ro, điều đó sẽ loại bỏ gánh nặng lớn khỏi vai bạn. Bất cứ điều gì xảy ra, hãy ghi lại biên bản cuộc họp của bất cứ điều gì mọi người quyết định và tại sao mọi người quyết định và gửi nó cho những người tham dự cuộc họp.

Tất cả điều này phụ thuộc vào sản phẩm mà bộ phận CNTT của bạn đang sử dụng để sao lưu cấp máy chủ.

Ví dụ: trong môi trường ảo VMWare sẽ chụp ảnh nhanh của máy chủ. Nếu SQL Server có liên quan VMWare có một tùy chọn mà hầu hết Quản trị viên kích hoạt (hoặc có thể theo mặc định tôi không biết) sẽ đóng băng IO cho cơ sở dữ liệu trong ảnh chụp nhanh. Bây giờ, trong khi điều này chỉ mất vài giây, bạn có khả năng gây ra sự cố trên ứng dụng của mình và không thực sự là một phương pháp đáng tin cậy để sử dụng để khôi phục cơ sở dữ liệu.

Nếu bạn đang sử dụng sản phẩm của bên thứ 3 để thực hiện sao lưu cấp máy chủ thì có khả năng đây chỉ là sao lưu cấp tệp của cơ sở dữ liệu của bạn. Ngoài ra, nó cũng phải có khả năng sao lưu các tệp bị khóa, bởi vì SQL Server có bất kỳ tệp mdf và ldf đính kèm nào bị khóa từ phối cảnh Windows. Ví dụ, BackupExec của Symantec sử dụng Tùy chọn tệp mở nâng cao để thực hiện việc này, vì vậy về cơ bản nó có thể chụp ảnh tệp bị khóa đó. Chỉ là cách âm thanh sẽ làm cho hầu hết các DBA co rúm lại nếu phải khôi phục cơ sở dữ liệu bằng bản sao lưu như vậy, hãy nghĩ về sự thống nhất của cơ sở dữ liệu khi có bản sao lưu đó. Không có sự bảo đảm nếu sao lưu được kích hoạt trong khi quá trình tải dữ liệu được thực hiện, phần nào của tải dữ liệu mà bản sao lưu đó nhận được?

Các bản sao lưu riêng của SQL Server đáng tin cậy đối với sự tôn trọng mà chúng được xác minh là các bản sao lưu tốt. Bạn biết chính xác trạng thái của chúng khi bạn thực hiện sao lưu cho FULL, cho dù bạn có lịch trình này xung quanh tải dữ liệu hay không. Một bản sao lưu nhật ký cho các mô hình phục hồi FULL bạn có thể khôi phục cơ sở dữ liệu đó xuống lần thứ hai.

Nếu người quản lý của bạn đã chết khi sử dụng sao lưu cấp máy chủ, tôi sẽ nghiên cứu kỹ về sản phẩm họ đang sử dụng. Tôi sẽ tìm hiểu xem có bất kỳ "tiện ích bổ sung" hoặc tác nhân dự phòng SQL Server nào có thể được mua để cho phép nó thực hiện sao lưu VDI của cơ sở dữ liệu hay không.

Một cái gì đó cũng cần xem xét và thảo luận với người quản lý của bạn là những gì bạn cần có để xác minh và khắc phục sự cố nếu sao lưu SQL Server không thành công. Tôi đã sử dụng Netbackup rất nhiều trong các công việc trước đây và có một khách hàng vài năm trước muốn tôi trải qua thử nghiệm sử dụng tác nhân SQL Server của Netbackup cho môi trường của họ. Điều này bao gồm các DBA khác cũng phải cung cấp hỗ trợ. Tôi đã nói trước với họ rằng việc khắc phục các lỗi sao lưu cho SQL Server yêu cầu bạn phải biết một chút về Netbackup. Các máy chủ chính của Netbackup thường chạy trên các máy chủ Unix, vì vậy bây giờ bạn phải biết một số Unix .... có thể thú vị nhưng sẽ đau hơn nếu bạn đang bận rộn. Chỉ cần một cái gì đó để xem xét và có thể là một điểm thảo luận tốt với người quản lý của bạn và tìm ra ai chịu trách nhiệm khắc phục các lỗi.

Chỉ có ít hơn một triệu biến trong câu hỏi của bạn. Bạn sẽ cần nói chuyện với bộ phận CNTT của bạn về những bản sao lưu mà họ thực hiện. Trong tất cả khả năng họ có hoặc có thể có các bản sao lưu tối thiểu có sẵn. Mất bao lâu để tải chúng phụ thuộc vào nhiều biến hơn.

Trong một kịch bản hoàn hảo, bộ phận CNTT của bạn đang giữ các bản sao lưu của bạn trên một hoặc nhiều máy chủ khác nhau ở các vị trí khác nhau. Bạn có thể đang giữ bản sao lưu của mình trên cùng một máy chủ mà cơ sở dữ liệu của bạn đang sử dụng. Vì vậy, nếu máy chủ chết hoặc tòa nhà của bạn bị hỏng, bộ phận CNTT của bạn có thể khôi phục các tệp của bạn, nhưng các bản sao lưu bạn đã lấy sẽ bị mất cùng với máy chủ.

NHƯNG bạn có thể khôi phục lại bản sao lưu của mình, với tốc độ của bạn, bất cứ khi nào bạn muốn, miễn là máy chủ của bạn vẫn còn sống.

Như những người khác đã nói, nó phụ thuộc vào nhu cầu của bạn là gì, khả năng chịu rủi ro của bạn và kiểm soát thời gian phục hồi quan trọng như thế nào. Nếu bạn muốn phục hồi từ một cái gì đó ngu ngốc bạn đã làm, bản sao lưu của bạn sẽ nhanh hơn và tốt hơn. Nếu bạn muốn phục hồi sau thảm họa ngoài tầm kiểm soát của mình, bản sao lưu CNTT (nên là) sự lựa chọn tốt hơn.