Sao lưu nhỏ nhất có thể với máy chủ SQL

Hàng ngày chúng tôi gửi các bản sao lưu SQL Server của chúng tôi trên mạng WAN. Chúng ta cần giảm thiểu kích thước của các bản sao lưu này để không mất thời gian.

Chúng tôi không phiền nếu quá trình sao lưu của chúng tôi mất nhiều thời gian hơn; vì hiện tại chúng ta cần di chuyển 30gigs sao lưu nén trên mạng LAN mất hơn 10 giờ.

Có 2 tùy chọn chúng ta phải có bản sao lưu hàng ngày nhỏ hơn.

1. Đăng nhập vận chuyển, có nghĩa là chúng tôi sẽ phải cơ cấu lại quy trình DR.
2. Loại bỏ thông tin ra khỏi db và xây dựng lại ở phía bên kia (bỏ các chỉ mục không được nhóm, đóng gói các chỉ mục được phân cụm ở mức 100% - xây dựng lại ở phía bên kia)

Cả hai sẽ liên quan đến một lượng công việc khá lớn từ phần của chúng tôi. Chúng tôi đang sử dụng SQL Server 2008 pro, tất cả các bản sao lưu đều được nén.

Có sản phẩm thương mại nào có thể cung cấp cho chúng tôi kích thước sao lưu tương tự với tùy chọn (2) không?

Có một kịch bản toàn diện ngoài kia sẽ cho phép chúng ta thực hiện (2) không? (xử lý các khung nhìn được lập chỉ mục, các chỉ mục được lọc, khóa ngoại, v.v.)

Suy nghĩ đầu tiên dựa trên ý kiến ​​...

Sử dụng sao lưu vi sai cứ sau 6 giờ để giảm kích thước / thời gian sao lưu + FTP. Sau đó giảm sao lưu toàn bộ + FTP của bạn vào cuối tuần. Điều này tránh sự phức tạp của vận chuyển gỗ, đơn giản để làm và chỉ thêm độ phức tạp nhẹ vào DR

Tôi cảm thấy rằng các bản sao lưu khác biệt bị bỏ qua ... Tôi đã đề xuất sử dụng chúng trước đây:

• Cách sao lưu cơ sở dữ liệu nhỏ trong SQL Server 2008 R2 Express Edition
  Sử dụng bản sao lưu DIFF để giải quyết vấn đề này

  Tôi muốn giữ mọi thứ đơn giản nhất có thể từ góc độ khôi phục trong khi giảm thiểu lượng dữ liệu bị mất trong trường hợp xảy ra lỗi

• Ưu và nhược điểm của SQL Server sao lưu chiến lược và các tình huống sử dụng phù hợp của chúng
• Di chuyển cơ sở dữ liệu lớn
  Sử dụng các bản sao lưu DIFF để tăng tốc độ di chuyển máy chủ sao lưu / khôi phục

Chỉnh sửa: sau bình luận của jcolebrand Tôi sẽ cố gắng giải thích thêm

Một bản sao lưu khác biệt chỉ mất các trang đã thay đổi. Ngoài bất kỳ bảo trì chỉ mục nào (có thể ảnh hưởng đến rất nhiều cơ sở dữ liệu), chỉ một vài% trang sẽ thay đổi trong một ngày. Vì vậy, một bản sao lưu vi sai nhỏ hơn rất nhiều so với bản sao lưu đầy đủ trước khi nén.

Nếu bạn có một bản sao lưu đầy đủ, giả sử hàng tuần, sau đó bạn có thể thực hiện các khác biệt hàng ngày và gửi chúng ra khỏi trang web. Một bản sao lưu đầy đủ hàng ngày với các vi sai vẫn sẽ yêu cầu cả hai tệp tắt trang web.

Điều này sẽ giải quyết vấn đề lấy dữ liệu từ A đến B, C và D một cách nhanh chóng.

Bạn có thể cần khôi phục cả vi sai đầy đủ và mới nhất để có được dữ liệu mới nhất nhưng bạn có thể giải quyết vấn đề này với tệp BÌNH THƯỜNG và tệp STANDBY (Tôi đã không thử nó với khôi phục khác trong nhiều năm kể từ lần cuối tôi tham gia DBA thuần túy việc làm).

Một phần thưởng bổ sung là các bản sao lưu khác không liên quan đến các bản sao lưu nhật ký đang diễn ra để bạn có thể tách bất kỳ yêu cầu Tính sẵn sàng / DR cao nào khỏi yêu cầu "lấy dữ liệu cho khỉ mã".

Tôi thấy một số vấn đề nếu bạn có bản sao lưu đầy đủ hàng ngày theo chính sách hoặc kiểm toán, nhưng khôi phục khác có thể được áp dụng trước khi bất kỳ bản ghi nào khôi phục để rút ngắn thời gian phục hồi. Không giống như sao lưu, khôi phục khác biệt và đăng nhập tương tác.

Hy vọng tôi đã bao phủ hầu hết các căn cứ ...

Có những sản phẩm thương mại có thể giúp bạn nén các bản sao lưu của mình tốt hơn so với nén năm 2008. Ví dụ như Sao lưu RedGate , Hyperbac , Sao lưu SQL Idera , Sao lưu Litespeed .

Chúng đi kèm với chi phí gia tăng của các loại tệp và CPU cao sẽ cần được xử lý bằng các công cụ bên ngoài các loại MS được vận chuyển. Điều này ngoại trừ nén Hyperbac (hiện đã được Redgate mua lại), xử lý các tệp trong suốt và cho phép một người tạo các tệp tương thích zip (và cũng không cần bất kỳ công cụ của bên thứ ba nào).

Nhưng không có công cụ nào cung cấp cho bạn một tệp có kích thước mà bạn sẽ có được bằng cách thực hiện dọn dẹp thủ công. Vui lòng xem qua bài viết của Brent Ozar: Cách thực sự nén các bản sao lưu SQL Server của bạn , anh ấy sẽ khuyên bạn thực hiện các bước tương tự bạn có tại điểm không. 2.

Câu hỏi 1: Có một sản phẩm sao lưu thương mại nào sẽ cung cấp kích thước sao lưu tương tự để tước dữ liệu không cần thiết như các chỉ mục ra khỏi cơ sở dữ liệu không?

Không. Có rất nhiều sản phẩm nén sao lưu ngoài đó (Quest LiteSpeed, Red Gate SQL Backup, Idera SQLSafe, Hyperbac, v.v.) nhưng tất cả chúng đều hoạt động bằng cách chỉ nén đầu ra của quy trình sao lưu thông thường của SQL Server. Một số trong số họ làm điều đó theo những cách khó khăn - tùy chọn Engine của HyperBac và LiteSpeed ​​là trình điều khiển bộ lọc hệ thống tệp, có nghĩa là họ chặn đầu ra trên đường vào đĩa - nhưng kết quả cuối cùng của tất cả các sản phẩm này chỉ là đầu ra sao lưu được nén.

Câu hỏi 2. Có một kịch bản toàn diện ngoài kia để đổ tất cả dữ liệu bổ sung này không?

Theo thời gian, khi bạn lưu giữ nhiều lịch sử hơn trong cơ sở dữ liệu (4, 5, 8, 10 năm), bạn sẽ không muốn lấy ra tất cả dữ liệu chỉ mục và xây dựng lại nó ở phía bên kia của mạng WAN. Thay vào đó, bạn muốn chuyển dữ liệu đã sửa đổi và đó là nơi vận chuyển nhật ký đến.

Bạn không nên làm điều này.

Nhưng nếu bạn thực sự, thực sự muốn làm điều này (và không, tôi sẽ không giúp bạn), bạn có thể làm điều đó với các bản sao lưu của filegroup. Thiết lập các nhóm cơ sở dữ liệu của bạn như thế này:

• Tập đoàn chính (bắt buộc, nhưng để trống)
• Tập đoàn phân cụm (đặt các chỉ mục được nhóm của bạn ở đây)
• ExternCrap Filegroup (đặt mọi thứ khác ở đây)

Bắt đầu thực hiện sao lưu filegroup nén chỉ của hai cái đầu tiên và sao chép những cái nhỏ hơn vào máy chủ DR của bạn. Bạn có thể sử dụng khả năng sao lưu và khôi phục filegroup của SQL Server 2008 để chỉ khôi phục các nhóm fileg chính và Clustered Index, và sau đó chúng sẽ có sẵn để truy vấn. Chúng thực sự sẽ không thể hoạt động được cho đến khi bạn đưa tập đoàn phim ExrialCrap trực tuyến, nhưng cũng có một mẹo khó chịu cho điều đó - trong cuốn sách MVP Deep Dives , có một chương về chỉnh sửa các bảng hệ thống để tạo ra tập đoàn phim ExrialCrap và tất cả của các chỉ số liên quan biến mất. Thủ thuật này rất nguy hiểm, hoàn toàn không được hỗ trợ và là một ý tưởng tồi tệ - nhưng này, bạn đã yêu cầu nó.

Tôi khuyên bạn nên chuyển sang một cái gì đó như đăng nhập vận chuyển. Về cơ bản, nếu bạn có lựa chọn gửi 30 Gigs trong vòng 24 giờ so với gửi vào cuối ngày trong một cửa sổ thời gian ngắn hơn, tốc độ mạng sẽ ít gây ra vấn đề cho bạn.

Các nhà phát triển của bạn trên mạng chậm cũng sẽ có thể tải xuống các tệp có kích thước thuận tiện hơn, thông qua FTP hoặc bất kỳ quy trình nào bạn có tại chỗ. Họ cũng có thể thiết lập các công việc tải xuống trong suốt cả ngày.

Ngoài nén máy chủ sql, bạn có thể triển khai công cụ của bên thứ 3 có khả năng nén cao hơn như litespeed hoặc redgate sqlbackup.

Ngoài ra, về phía mạng, bạn có thể cài đặt các thiết bị mạng có thể tối ưu hóa thông lượng của bạn đến trang web DR. Trước đây, tôi đã sử dụng thành công Thiết bị Riverbed để nhận thành công 90GB sao lưu từ FL sang VA trong vòng chưa đầy 3 giờ.

Một tùy chọn khác là sao lưu các nhóm tệp cụ thể, ngoại trừ các chỉ mục, v.v., nhưng bạn vẫn bị mắc kẹt với các chỉ mục được nhóm và tùy thuộc vào cấu trúc db của bạn, bạn có thể nhận được nhiều chi phí / rắc rối hơn lợi ích từ cách tiếp cận đó.

Cảm ơn

Nếu bạn có tiền cho nó và kiến ​​trúc của bạn cho phép, hãy kiểm tra một cái gì đó như công nghệ Riverbed (http://www.riverbed.com/us/). Một thiết bị như thế này kết hợp với kịch bản sao chép hoặc vận chuyển nhật ký có thể là lựa chọn tốt nhất của bạn.

Nếu không thì vài câu hỏi. Nếu bạn chỉ phải làm mới mỗi vài tháng, tại sao mối quan tâm về băng thông? Lần duy nhất bạn phải lo lắng về việc chuyển tiền là một lần, nhận bản sao lưu đầy đủ ở đó để thực hiện khôi phục cục bộ hoặc tôi nhầm lẫn rằng đó là thiết lập của bạn?

Một khả năng khác là thay vì lo lắng về việc lấy tất cả dữ liệu đó cho họ, hãy thiết lập môi trường Citrix và để chúng từ xa vào bạn. Với Citrix, bạn có các yêu cầu băng thông tối thiểu giữa máy khách / máy chủ và bạn có khả năng thực hiện những gì bạn cần tại địa phương và không phải lo lắng về việc phải sao chép những thay đổi đó ở nơi khác. Chỉ 0,02 đô la của tôi

Tôi sẽ sử dụng bản sao giao dịch SQL. Tải ban đầu của bạn sẽ mất một chút thời gian nhưng một khi bạn đứng dậy và chạy, bạn chỉ có thể gửi qua những thông tin bạn muốn. Ví dụ: nếu bạn chỉ có 3 hoặc 4 bảng được cập nhật, bạn chỉ có thể gửi 3 hoặc 4 bảng đó.

Bạn cũng có thể chọn những gì bạn muốn gửi qua. FK, các chỉ mục được phân cụm / không phân cụm, các lược đồ phân vùng bảng, các procs được lưu trữ và TONS khác.

http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

Nếu đây không phải là một tùy chọn, bạn có thể sử dụng REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . Tôi đã sử dụng điều này trước đây và có mức nén lên tới 90%. Nhỏ hơn rất nhiều so với SQL.