Khi tôi triển khai tập lệnh sao lưu của Ola Hallengren vào các máy chủ của mình, tôi luôn đặt @CleanupTimetham số cho các bản sao lưu nhật ký bằng không. Bằng cách này, mỗi khi công việc sao lưu nhật ký chạy, nó sẽ kiểm tra các tệp sao lưu nhật ký cũ hơn bản sao lưu đầy đủ cuối cùng và xóa chúng. Tuy nhiên, điều này cũng đúng với các COPY_ONLYbản sao lưu đầy đủ ! Công việc sao lưu nhật ký chỉ nên kiểm tra lần COPY_ONLYsao lưu không đầy đủ cuối cùng để xóa các tệp sao lưu nhật ký cũ.

Chỉ tự hỏi nếu tôi là người duy nhất gặp phải vấn đề này, hoặc nếu những gì tôi đề xuất có ý nghĩa. Nếu tôi cần sao lưu toàn bộ bản sao lưu vào giữa ngày để IDK làm mới cơ sở dữ liệu TEST, bản sao lưu chỉ sao chép đó không ảnh hưởng đến trình tự sao lưu hàng ngày thông thường. Hãy cho tôi biết suy nghĩ của bạn, xin vui lòng.

Phần II của II (phải chia câu trả lời của tôi)

Làm tốt hơn

Xem xét RPO và RTO của bạn được xác định bởi doanh nghiệp của bạn, bây giờ bạn có thể muốn thay đổi tham số của @CleanupTimethứ gì đó cao hơn 0. Tại sao? Bởi vì giá trị 0sẽ chỉ hoạt động cùng với cơ chế không an toàn tích hợp.

Hãy sử dụng dòng thời gian sau:

• 08:00 ĐĂNG NHẬP
• 09:00 ĐĂNG NHẬP
• 10:00 ĐĂNG NHẬP
• ...
• 20:00 CƠ SỞ SAU
• 21:00 ĐĂNG NHẬP
• ...

Tại một số thời điểm, các bản sao lưu Nhật ký giao dịch của bạn (và các bản sao lưu đầy đủ?) Được sao chép vào ổ đĩa mạng và được sao lưu từ đó bằng một giải pháp sao lưu, có thể kết hợp với một số loại băng và / hoặc lưu trữ đĩa. Ngay khi lần đầu tiên BACKUP LOG ...xảy ra sau lần cuối cùng, BACKUP DATABASE ...các BACKUP LOG ...tệp trước của bạn đã biến mất ...

Câu hỏi để tự hỏi

• Điều gì xảy ra nếu sao lưu mạng của bạn không thành công?
• Khi nào thì sao lưu (băng) này xảy ra? Đảm bảo?
• Khi nào sao lưu cơ sở dữ liệu đầy đủ xảy ra?
• Bạn muốn gì để có thể khôi phục?
• Bạn có RTO gì?
• Doanh nghiệp của bạn yêu cầu RPO gì?

Nhìn vào các câu hỏi trên, hãy cân nhắc sử dụng thời gian dọn dẹp khác (ví dụ @CleanupTime=48) để giữ các bản sao lưu Nhật ký giao dịch có giá trị hàng giờ trên các đĩa của máy chủ cơ sở dữ liệu của bạn.

Những lợi ích

• Bạn không còn dựa vào cơ chế không an toàn của Ola
• Dữ liệu của bạn vẫn còn trên đĩa, ngay cả khi bạn tạo COPY_ONLYbản sao lưu
• Dữ liệu của bạn vẫn còn trên đĩa, ngay cả khi mạng bị sập và ...
  • ... bạn tạo ra một BACKUP DATABASE ...
  • ... một COPY_ONLYbản sao lưu

Xây dựng nền tảng vững chắc

Tại bất kỳ thời điểm nào, một cái gì đó sẽ thất bại. Bạn phải đảm bảo rằng bạn có thể chấp nhận bất kỳ thất bại nào và vẫn đảm bảo với các bên liên quan rằng giải pháp của bạn sẽ là 99, .....% bằng chứng ngu ngốc.

Làm thế nào tôi làm điều đó

Làm việc với giải pháp của Ola là một cách dễ dàng, NẾU bạn thực hiện một hoặc hai suy nghĩ về cách bạn muốn khôi phục cơ sở dữ liệu và dựa trên RPO và RTO cho doanh nghiệp của bạn.

Việc thực hiện cá nhân của tôi là có các chính sách về lịch trình / lưu giữ sau đây:

Hệ thống sản xuất

• Sao lưu TLog
  • Hàng giờ @ xx: 05 (hệ thống không phải của SAP)
  • Hàng giờ hàng quý @ xx: 10, xx: 25, xx: 40, xx: 55 (hệ thống SAP)
  • Duy trì: 48 giờ
• Sao lưu vi sai hàng ngày
  • Thứ Hai - Thứ Bảy @ 20:00 (các hệ thống không phải của SAP)
  • Thứ Hai - Thứ Bảy @ 22:00 (hệ thống SAP)
  • Duy trì: 168 giờ
• Sao lưu toàn bộ hàng tuần
  • Chủ nhật @ 20:00 (hệ thống không phải của SAP)
  • Chủ nhật @ 22:00 (hệ thống SAP)
  • Duy trì: 336 giờ

Hệ thống kiểm tra

Hệ thống kiểm tra sẽ được sao lưu trong giờ sản xuất. Thời gian này có thể là 10:00 vào buổi sáng hoặc lúc 14:00 chiều cho toàn bộ và xx: 15 cho các bản sao lưu Nhật ký giao dịch.

Tại sao tôi làm theo cách này

... hoặc suy nghĩ của tôi đằng sau những quyết định này ...

Bằng cách phân phối thời gian sao lưu vào các khe khác nhau, tôi phân phối đồng đều đĩa I / O trên các hệ thống lưu trữ. Không vứt I / O lớn trên đĩa vào toàn bộ giờ (FULL) hoặc giờ hàng quý (TLOG).

Tôi phân biệt giữa SAP và không phải SAP vì kích thước của cơ sở dữ liệu.

Hệ thống kiểm tra được phép để lưu trữ lưu trữ trong ngày. Không có tác động hiệu suất cao.

Các bản sao lưu DIFF và FULL xảy ra trước khi các bản sao lưu băng bắt đầu và thường được hoàn thành trước khi các bản sao lưu băng bắt đầu.

Các chính sách duy trì cho phép tôi đạt được RTO và RPO do doanh nghiệp đưa ra ngay cả khi giải pháp sao lưu (băng) bị hỏng trong một ngày.

Sao lưu sẽ vẫn hoạt động và tuân thủ RTO và RPO ngay cả khi mạng (toàn bộ hoặc chỉ một phần) ngừng hoạt động trong một ngày.

Quá trình suy nghĩ của bạn

@CleanupTimeCài đặt của bạn có thể dựa trên sự hiểu biết sai về kịch bản của Ola.

Phần I của II (phải chia câu trả lời của tôi)

Có một hoặc hai điều cần suy nghĩ ở đây. Theo tôi bạn có thể đã thực hiện một lối tắt trong quá trình suy nghĩ. Tôi sẽ giải thích trong khi tôi đưa ra giả định này ...

Bạn có thể muốn xem nhanh câu trả lời được chấp nhận của tôi ở đây được đăng cùng với câu hỏi Cần gợi ý về Chiến lược sao lưu [đã đóng] để cung cấp cho bạn một số ý tưởng về RTO và RPO.

Tại sao? Bởi vì thiết lập @CleanupTime=0có thể là một ý tưởng tồi ...

Đầu tiên để trả lời câu hỏi của bạn.

Đây có phải là một lỗi trong kịch bản của Ola không? - Không. Ola đã thiết kế tập lệnh của mình để kiểm tra lần cuối BACKUP DATABASE...(Sao lưu toàn bộ) và sau đó xóa các bản sao lưu nhật ký giao dịch ( BACKUP LOG ...) đã xảy ra trước bản sao lưu đó và chỉ khi @CleanupTimemức thấp hơn so với khi sao lưu FULL xảy ra.

Đây là một cơ chế không an toàn và không có nghĩa là được sử dụng như một tính năng chung.

Hoạt động như thiết kế, bởi vì a BACKUP DATABASE ... WITH COPY_ONLY...vẫn là một bản sao lưu đầy đủ .

An toàn là trên hết

Tạo một bản sao lưu với BACKUP DATABASE ... COPY_ONLY...tùy chọn và sau đó tạo BACKUP LOG...vẫn sẽ cho phép bạn khôi phục cơ sở dữ liệu về trạng thái nhất quán bằng cách sử dụng COPY_ONLYbản sao lưu FULL và bản sao lưu Nhật ký giao dịch có sẵn.

Tôi đã kiểm tra điều này bằng cơ sở dữ liệu StackExchange của tôi:

• Tạo COPY_ONLYbản sao lưu thủ công
• Sửa đổi một số dữ liệu
• Thực hiện BACKUP LOG ...việc sử dụng các tập lệnh của Ola
• Khôi phục cơ sở dữ liệu

Sao lưu thủ công với COPY_ONLY

-------------------------------------------------
BACKUP DATABASE [StackExchange] TO DISK = 'C: \ adhoc \ StackExchange_Full_CopyOnly_20171221_082242.bak' 
                VỚI COPY_ONLY, COMPRESSION, RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'StackExchange-Thiết bị sao lưu đầy đủ ', SKIP, NOREWIND, 
                     NOUNLOAD, STATS = 10, KIỂM TRA
-------------------------------------------------
10 phần trăm được xử lý.
21 phần trăm được xử lý.
31 phần trăm được xử lý.
40 phần trăm được xử lý.
50 phần trăm được xử lý.
61 phần trăm được xử lý.
70 phần trăm được xử lý.
80 phần trăm được xử lý.
91 phần trăm được xử lý.
Đã xử lý 376 trang cho cơ sở dữ liệu 'StackExchange', tệp 'StackExchange' trên tệp 1.
Xử lý 100 phần trăm.
Đã xử lý 2 trang cho cơ sở dữ liệu 'StackExchange', tệp 'StackExchange_log' trên tệp 1.
BACKUP DATABASE đã xử lý thành công 378 trang trong 0,027 giây (109.103 MB / giây).
-------------------------------------------------
Đã kết thúc

Sao lưu Nhật ký giao dịch với tập lệnh của Ola

Ngày 21.12.2017 08:29:06
Nhật ký lịch sử công việc (OLA DatabaseBackup - USER_DATABASES - LOG)

ID bước 1
Máy chủ MYNOTEBOOK
Tên công việc OLA DatabaseBackup - USER_DATABASES - LOG
Tên bước OLA DatabaseBackup - USER_DATABASES - LOG
Thời lượng 00:00:01
Mức độ nghiêm trọng 0
ID tin nhắn Sql 0
Điều hành qua email    
Toán tử đã gửi   
Toán tử phân trang  
Thử lại 0

Thông điệp
Được thực thi với tư cách là người dùng: NT Service \ SQLSERVERAGENT. ... 557.0 Phiên bản: Phiên bản dành cho nhà phát triển (64-bit) Quy trình: [msdb]. [Dbo]. [DatabaseBackup] Tham số: @Database = 'USER_DATABASES', @Directory = 'C: \ SQL \ Backup', @BackupType = 'LOG', @Verify = 'Y', @CleanupTime = 48, @CleanupMode = 'AFTER_BACKUP', @Compress = NULL, @CopyOnly = 'N', @ChangeBackupType = 'N', @BackupSoftware = NULL, @ 'Y', @BlockSize = NULL, @BufferCount = NULL, @MaxTransferSize = NULL, @NumberOfFiles = NULL, @CompressionLevel = NULL, @Descrip = NULL, @Threads = NULL, @ , @EncryptAlerskym = NULL, @ServerCert ve = NULL, @ServerAsymmetricKey = NULL, @EncryptKey = NULL, @ReadWriteFile ERIC = 'N', @OverrideBackupPreference = 'N', @NoRec =

[rút ngắn]

  ... Mã thoát quy trình 0. Bước thành công.

Khôi phục

USE [master]
-- Restore the COPY_ONLY Backup 
RESTORE DATABASE [StackExchange] FROM  DISK = N'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak' 
WITH  REPLACE, FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
-- Restore an OLA Transaction Log backup
RESTORE LOG [StackExchange] FROM  DISK = N'C:\SQL\Backup\MYNOTEBOOK\StackExchange\LOG\NB31710_StackExchange_LOG_20171221_082906.trn' 
WITH  FILE = 1,  NOUNLOAD,  STATS = 5

Bạn có thể không sự khác biệt trong dấu thời gian là xấp xỉ. 7 phút.

Các kết quả

6 phần trăm được xử lý.
10 phần trăm được xử lý.
16 phần trăm được xử lý.
21 phần trăm được xử lý.
25 phần trăm được xử lý.
31 phần trăm được xử lý.
36 phần trăm được xử lý.
40 phần trăm được xử lý.
46 phần trăm được xử lý.
50 phần trăm được xử lý.
55 phần trăm được xử lý.
61 phần trăm được xử lý.
65 phần trăm được xử lý.
70 phần trăm được xử lý.
76 phần trăm được xử lý.
80 phần trăm được xử lý.
86 phần trăm được xử lý.
91 phần trăm được xử lý.
95 phần trăm được xử lý.
Xử lý 100 phần trăm.
Đã xử lý 376 trang cho cơ sở dữ liệu 'StackExchange', tệp 'StackExchange' trên tệp 1.
Đã xử lý 2 trang cho cơ sở dữ liệu 'StackExchange', tệp 'StackExchange_log' trên tệp 1.
RESTORE DATABASE đã xử lý thành công 378 trang trong 0,021 giây (140.276 MB / giây).
Xử lý 100 phần trăm.
Đã xử lý 0 trang cho cơ sở dữ liệu 'StackExchange', tệp 'StackExchange' trên tệp 1.
Đã xử lý 2 trang cho cơ sở dữ liệu 'StackExchange', tệp 'StackExchange_log' trên tệp 1.
RESTORE LOG đã xử lý thành công 2 trang trong 0,005 giây (2,441 MB / giây).

Tóm lược

Kịch bản của Ola hoạt động như thiết kế. Chúng tôi đã xác minh rằng một BACKUP DATABASE ... WITH COPY_ONLY...và một bổ sung BACKUP LOG ...sẽ làm việc cùng nhau. Tính năng không an toàn đảm bảo bạn có thể khôi phục cơ sở dữ liệu của mình với bản sao lưu đầy đủ cuối cùng (có thể là COPY_ONLY hoặc không) và các bản sao lưu Nhật ký giao dịch có sẵn.

(Vui lòng đọc Phần II của II để biết thêm câu trả lời)

Bạn đúng rồi! Tôi nghĩ rằng đây là một lỗi hoặc do thiết kế. Tôi đã có thể repo lại kịch bản.

Vì vậy, về cơ bản khi bạn chạy tập lệnh của Ola với điều này:

EXECUTE [master].[dbo].[DatabaseBackup] 
@Databases = 'UserShrinkSizeTest', 
@Directory = N'C:\Backup', 
@BackupType = 'FULL', 
@Verify = 'Y', 
@CleanupTime = NULL, 
@CheckSum = 'Y', 
@LogToTable = 'Y',
@CopyOnly = 'Y' --copy_only param

Hoặc bản địa:

-- native copy_only
BACKUP DATABASE [UserShrinkSizeTest] 
TO  DISK = N'C:\Backup\machine$SQLSERVER16\UserShrinkSizeTest\COPY_ONLY\UserShrinkSizeTest_21122017_COPYONLY.bak'
 WITH  COPY_ONLY, INIT, STATS = 1
GO

Khi bạn thực hiện sao lưu toàn bộ mới hoặc sao lưu toàn bộ copy_onlyhoặc thậm chí sao lưu vi sai, Tất cả các bản sao lưu nhật ký trước đó của bạn sẽ bị xóa sau khi bạn chạy một bản sao lưu nhật ký khác (tập lệnh sao lưu nhật ký của Ola với @CleanupTime = 0param).

Đã thử nghiệm bằng phiên bản tập lệnh của Ola: ngày 7 tháng 10 năm 2016 .

Dựa trên trang web của Ola :

Thời gian dọn dẹp

Chỉ định thời gian, tính bằng giờ, sau đó các tệp sao lưu sẽ bị xóa. Nếu không có thời gian được chỉ định, thì không có tập tin sao lưu nào bị xóa.

DatabaseBackup có một kiểm tra để xác minh rằng các bản sao lưu nhật ký giao dịch mới hơn bản sao lưu đầy đủ hoặc khác biệt gần đây nhất sẽ không bị xóa.

Nó không đề cập đến COPY_ONLYsao lưu.

Trong khi đó, bạn có thể thay đổi thông số sao lưu nhật ký @CleanupTime = NULLthành một cách giải quyết. Hoặc xem xét chuyển sang các công cụ sao lưu khác (ví dụ: Sao lưu Minion hoặc dbatools ) hoặc cuộn mã tùy chỉnh của riêng bạn vì bản cập nhật cuối cùng của Kế hoạch bảo trì của Ola là vào ngày 7 tháng 10 năm 2016. Có một github nếu bạn muốn đưa ra vấn đề / nâng cao.