Sao lưu SQL DB thường xuyên hơn


10

Tôi hiện có một tác vụ theo lịch trình sẽ tắt mỗi đêm vào lúc 2 giờ sáng, gọi SQLCMD.exe và chuyển nó thành tập lệnh .sql để chạy sao lưu (hiển thị bên dưới). Chúng tôi là một công ty nhỏ với nhu cầu ngày càng tăng do sự tăng trưởng lớn về phía doanh nghiệp. Mất 1 ngày dữ liệu vào thời điểm này sẽ tiêu tốn hàng chục ngàn đô la so với vài trăm lần này vào năm ngoái. Cho đến khi tôi có thể di chuyển nền tảng DB này sang một giải pháp khác trong đó việc phản chiếu dữ liệu xảy ra với sự dư thừa lớn như SQL Azure, điều tốt nhất tôi có thể làm để có được các bản sao lưu thường xuyên hơn là gì? Liệu đoạn script dưới đây có buộc DB phải ngoại tuyến không? Tôi có thể chạy tập lệnh này với người dùng tương tác với DB không?

USE CompanyCRM;
GO
BACKUP DATABASE CompanyCRM
TO DISK = 'D:\CRMBackups\CompanyCRMCRM.Bak'
   WITH FORMAT,
      MEDIANAME = 'CompanyCRM_Backup',
      NAME = 'Full Backup of CompanyCRM';
GO

Cập nhật

Wow, rõ ràng là một cộng đồng DBA chuyên dụng hơn nhiều so với trên SO. Cảm ơn các phản hồi cho đến nay. Điều duy nhất còn thiếu là "cái đuôi". Tôi đã chỉ ra lệnh SQL ở trên mà tôi đang sử dụng để thực hiện sao lưu hàng ngày, nhưng các ví dụ sao lưu nhật ký gia tăng là MIA. Đây không phải là một DB lớn, nó hiện đang chạy trên SQLE Express. Khi tôi nói HA hoặc SQL Azure, tôi đặc biệt đề cập đến kiến ​​trúc tại chỗ mà chúng tôi không có như một doanh nghiệp nhỏ. Trường hợp này hiện đang chạy trên máy chủ DUY NHẤT của chúng tôi. Nếu máy chủ đó gặp sự cố, thời gian để phục hồi của chúng tôi trở thành một điểm gắn bó. Đây là lý do tại sao SQL Azure trở nên hấp dẫn.


đã chỉnh sửa câu trả lời của tôi cho bản cập nhật của bạn, hy vọng nó có ích

Câu trả lời:


5

EDIT, từ bản cập nhật của bạn

Như bạn đã nói rằng bạn có thể mất dữ liệu trong 1 ngày, sau đó tôi sẽ đặt cơ sở dữ liệu ở chế độ khôi phục SIMPLE. Sau đó, bạn có thể thực hiện ĐẦY ĐỦ mỗi sáng và / hoặc buổi tối. Nếu bạn muốn tự bảo vệ mình trong ngày bạn có thể thông qua một bản sao lưu khác biệt của cơ sở dữ liệu, một trong những trường hợp đó chỉ trong trường hợp. Điều này sẽ nắm bắt bất kỳ thay đổi được thực hiện kể từ khi sao lưu đầy đủ. Nếu tôi biết một khung thời gian có nhiều đầu vào xảy ra, tôi có thể ném loại sao lưu này vào đó sau khi hoàn thành. Nó có thể tiết kiệm thời gian phục hồi của mọi người để họ không phải nhập thêm dữ liệu.

Vì đây là máy chủ duy nhất của bạn nên tôi chắc chắn rằng bạn đang chạy DBCC CHECKDB dựa trên cơ sở dữ liệu. Sao lưu không làm gì tốt khi bạn phát hiện ra chúng bị hỏng (tôi nghĩ ai đó cũng đề cập đến điều này). Bạn có thể tìm một vài tập lệnh ngoài đó để thiết lập một tác vụ theo lịch trình để kiểm tra SQL ERRORLOG cho thông báo DBCC để bắt bất kỳ lỗi nào. SQL Server sẽ không cảnh báo cho bạn về các lỗi được trả về từ các thông báo DBCC, vì vậy trừ khi bạn kiểm tra thủ công mỗi lần một tập lệnh có thể giúp.

Lệnh sao lưu vi sai:


USE CompanyCRM; 
GO 
BACKUP DATABASE CompanyCRM 
   TO DISK = 'D:\CRMBackups\CompanyCRMCRM_diff.Bak'    
WITH FORMAT, DIFFERENTIAL,
MEDIANAME = 'CompanyCRM_Backup',       
NAME = 'Full Backup of CompanyCRM'; 
GO 

1
@Shawn: OP nói rằng "Mất 1 ngày dữ liệu vào thời điểm này sẽ tiêu tốn hàng chục ngàn đô la so với vài trăm lần này vào năm ngoái", ông đã nói rằng mình có thể mất dữ liệu trong 1 ngày?!
Mary

8
  • Sao lưu trong SQL Server không bị gián đoạn. Tức là cơ sở dữ liệu vẫn hoạt động. Đọc tài liệu.
  • Thực hiện sao lưu đầy đủ mỗi ngày, sau đó được gửi (sao chép) sao lưu LOG ​​(một lần nữa, tài liệu có ... tài liệu) thường xuyên hơn - như cứ sau 15 phút hoặc lâu hơn.

4
Tôi nghĩ rằng sao lưu là thứ bạn không cần làm thế nào, nhưng đọc toàn bộ tài liệu - nó rất quan trọng VÀ nó - nghiêm túc - quan trọng. Không nấu trứng kiểu. Thuê một pro.
TomTom

2
Thật tệ là tôi không thể bỏ phiếu trả lời trên trang web này ...
RSolberg

1
@RSolberg: Câu trả lời của TomTom là hợp lệ, cùng với những lời khuyên khác mà bạn đã có. Tôi sẽ đề nghị bạn không mong đợi bất kỳ người trả lời nào cho bạn thấy thực sự cú pháp sao lưu cơ bản. Mặc dù tôi thấy Shawn rất tốt bụng khi làm điều đó. Để thiết kế một chiến lược BACKUP là không đủ. Bạn cần kết hợp nó với chiến lược RESTORE để mọi thứ sẽ hợp lệ khi bạn cần.
Mary

2
@RSolberg: xin lỗi vì đã chọc tức bạn. Điều này không có ý định. Nhưng làm thế nào mà cộng đồng này không giúp đỡ? Bạn có câu trả lời tốt và hợp lệ (và ý kiến). Thông điệp của riêng bạn là: "Mất 1 ngày dữ liệu vào thời điểm này sẽ tiêu tốn hàng chục ngàn đô la so với vài trăm lần này vào năm ngoái." Vì vậy, bạn cần một chiến lược sao lưu và khôi phục vững chắc để bạn không đến đó. Một chiến lược vững chắc đến từ việc biết rất rõ những điều cơ bản. Mà đến từ việc đọc và hiểu hướng dẫn. Xin lỗi nếu bạn hiểu bất cứ điều gì khác!
Mary

2
Tôi đồng ý với @RSolberg rằng hầu hết các câu trả lời ở đây không chỉ ra "làm thế nào" để làm điều đó, nhưng đó cũng là vì câu hỏi thiếu một số chi tiết "những gì" bạn không hiểu Russell. Bạn phải cho chúng tôi biết thêm một chút về những gì bạn cần, nhưng tôi đồng ý với bạn rằng trang web ở đây không phải là về "RTFM n00b". Ngoài ra, như bạn đã chỉ ra, bạn có 10k trên Stack Overflow , vì vậy bạn chắc chắn hiểu các bình luận gắn cờ là thô lỗ hoặc gây rối. Trong tương lai, bạn nên làm điều đó sớm hơn, thay vì sôi sục trong thất vọng.
jcolebrand

6

Điều đầu tiên bạn cần làm là tìm hiểu xem bạn có thể mất bao nhiêu dữ liệu. Cho đến lúc đó bạn sẽ không biết tần suất sao lưu cơ sở dữ liệu. Đây không phải là một con số mà bạn nên nghĩ ra. Đây là điều mà doanh nghiệp (hoặc CEO trong một công ty nhỏ hơn) sẽ cần phải quyết định. Số đầu tiên họ sẽ quay lại là 0 phút. Điều này có thể được thực hiện, nhưng nó sẽ rất tốn kém để làm. Trong thực tế, lượng dữ liệu nhỏ nhất mà bạn có thể sao lưu là khoảng 2 phút một lần. Nếu lượng dữ liệu thay đổi trong hệ thống đủ nhỏ, bạn có thể thực hiện sao lưu mỗi phút.

Để thực hiện sao lưu nhật ký giao dịch, đó là những gì bạn cần làm, bạn cần đưa cơ sở dữ liệu vào chế độ phục hồi ĐẦY ĐỦ.

Nếu bạn có thể đủ khả năng để mất dữ liệu trị giá 5 phút thì có lẽ bạn sẽ muốn thực hiện sao lưu toàn bộ hàng ngày và sao lưu nhật ký giao dịch cứ sau 5 phút. Nếu bạn có thể mất 15 phút dữ liệu thì bạn sẽ muốn thực hiện sao lưu toàn bộ và sao lưu nhật ký giao dịch cứ sau 15 phút.

Một lựa chọn khác là thực hiện sao lưu toàn bộ hàng tuần, sao lưu chênh lệch hàng ngày và sao lưu nhật ký giao dịch mỗi x phút như tôi đã nói ở trên.

Hãy nhớ rằng bạn càng thường xuyên phải sao lưu thì càng cần nhiều tệp để khôi phục trong trường hợp cơ sở dữ liệu bị lỗi hoặc xóa dữ liệu. Có thể có ý nghĩa để thực hiện sao lưu vi sai trong suốt cả ngày để rút ngắn thời gian cần thiết để khôi phục cơ sở dữ liệu.

Tất cả các bản sao lưu sử dụng cơ sở dữ liệu BACKUP và câu lệnh BACKUP LOG đều được thực hiện trực tuyến và không ngăn người dùng truy cập cơ sở dữ liệu.


Tôi thực sự hoàn toàn có thể đánh giá chúng ta có thể mất bao nhiêu dữ liệu. Các doanh nghiệp nhỏ yêu cầu mọi người phải đội nhiều mũ, vì CIO tôi có xu hướng tham gia vào các quyết định kinh doanh hàng ngày.
RSolberg

1
Điều đó sẽ làm cho cuộc thảo luận ngắn hơn nhiều.
mrdenny

3

Hãy nói rằng bạn có một kịch bản kinh doanh chung với thời gian bận rộn nhất của bạn là: 9 giờ sáng đến 5 giờ chiều Thứ Hai-Thứ Sáu. Sau đó, tôi sẽ đề nghị: Sao lưu đầy đủ vào tối chủ nhật. Sao lưu chênh lệch lúc 8 giờ sáng, 6 giờ chiều và 1 giờ sáng (để giảm thời gian phục hồi). Đăng nhập sao lưu mỗi giờ hoặc tùy thuộc vào những gì doanh nghiệp của bạn yêu cầu.

Tùy thuộc vào thời gian lưu giữ của bạn, bạn nên có một công việc dọn dẹp tự động để xóa các tệp sao lưu cũ. Tất cả những thứ này có thể được tạo bằng các kế hoạch bảo trì SQL. Kiểm tra liên kết này cho SQL 2005 .

Bạn nên lưu trữ bản sao lưu của mình trên một số dạng đĩa dự phòng (được nhân đôi) hoặc bạn có thể sử dụng băng để lưu trữ ngoại vi. Người dùng có thể tiếp tục làm việc trên hệ thống trong khi các bản sao lưu chạy.


2

Tôi sẽ không làm một bản sao lưu đầy đủ mỗi đêm. Nếu đó là một cơ sở dữ liệu lớn thì có thể mất một thời gian rất dài, chưa kể chiếm nhiều không gian trên phương tiện truyền thông. Làm một bản sao lưu đầy đủ mỗi cuối tuần và một bản sao lưu khác biệt mỗi đêm. Sau đó thực hiện sao lưu nhật ký giao dịch (giả sử cơ sở dữ liệu của bạn đang khôi phục hoàn toàn) mỗi giờ hoặc mỗi nửa giờ, nhưng đảm bảo các tệp .bak và .trn này nằm trên một đĩa riêng trong trường hợp hỏng đĩa.


Thẻ đã bị mất, đây không phải là một cơ sở dữ liệu lớn. Nó hiện đang chạy trên một ví dụ SQLE े.
RSolberg

1
Hàng chục ngàn đô la, chạy trên Express? Hấp dẫn!
Andrei Rînea

Không hẳn vậy. Tùy thuộc vào những gì bạn lưu trữ (không có văn bản, không có nhị phân) - đó là 10 gigabyte dữ liệu. Bạn có thể điều hành một hệ thống kế toán cho một công ty lớn - công ty lớn NGHIÊM TRỌNG - trong 10 gigabyte. Một cửa hàng trực tuyến với 100.000 đơn đặt hàng mỗi ngày có thể dễ dàng thực hiện phía cửa hàng trong 10 gigabyte.
TomTom

1

Bạn có thể đồng bộ đám mây thư mục sao lưu của mình vào ban đêm để có được bộ nhớ ngoài trang web không? Vì tôi khá chắc chắn rằng đây là một công ty chăm sóc sức khỏe, có điều gì đủ an toàn để tuân thủ HiPA không? Hoặc có thể chỉ siêu mã hóa chúng?

Tập lệnh ít nhất có đặt một bản sao lưu trên mạng chia sẻ không? Theo cách đó, nếu hộp vật lý nổ tung ...


Có cho tất cả các bên trên. Chúng tôi thực sự sao lưu vào một ổ đĩa mạng được nhân đôi và chúng tôi sao chép dữ liệu ra khỏi môi trường đó vào một trung tâm dữ liệu an toàn.
RSolberg
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.