Найменша можлива резервна копія… за допомогою SQL Server

Щодня ми доставляємо резервні копії SQL Server через WAN. Нам потрібно мінімізувати розмір цих резервних копій, щоб це не вічно було.

Ми не заперечуємо, якщо процес резервного копіювання займе трохи більше часу; як слід, нам потрібно перемістити 30 ГГ стисненого резервного копіювання по всій WAN, що займає більше 10 годин.

Є два варіанти, які ми повинні отримувати менші щоденні резервні копії.

1. Доставка журналу, що означатиме, що нам доведеться реструктурувати процес ДР.
2. Вийміть інформацію з db та відновіть на іншій стороні (скиньте некластеризовані індекси, запакуйте кластерні індекси на 100% - відновіть на іншій стороні)

І те й інше залучало б неабияку кількість роботи з нашого боку. Ми використовуємо SQL Server 2008 pro, всі резервні копії стиснуті.

Чи є комерційні продукти, які можуть надати нам аналогічний розмір резервного копіювання (2)?

Чи є там вичерпний сценарій, який дозволить нам виконати (2)? (обробка індексованих подань, відфільтрованих покажчиків, сторонніх ключів тощо)

Перша думка на основі коментарів ...

Використовуйте диференційні резервні копії кожні, скажімо, 6 годин, щоб зменшити розмір / час резервного копіювання + FTP. Тоді зменшіть повну резервну копію + FTP лише до вихідних. Це дозволяє уникнути складності доставки журналів, просту у виконанні, і лише додає незначної складності DR

Я відчуваю, що диференціальні резервні копії не помічені ... Я пропонував їх використовувати раніше:

• Як створити резервну копію невеликої бази даних в SQL Server 2008 R2 Express Edition,
  використовуючи резервні копії DIFF для вирішення цього питання

  Я хотів би зберегти все максимально просто з точки зору відновлення, мінімізуючи кількість втрачених даних у разі збою

• Плюси та мінуси створення резервного копіювання стратегій SQL Server та відповідних сценаріїв їх використання
• Перенесення великої бази даних
  Використання резервних копій DIFF для прискорення міграції сервера резервного копіювання / відновлення

Редагувати: після коментаря jcolebrand я спробую пояснити більше

Диференціальне резервне копіювання бере лише сторінки, які були змінені. Поза будь-яким обслуговуванням індексів (що може вплинути на велику кількість баз даних), протягом дня зміниться лише кілька% сторінок. Отже диференціальне резервне копіювання набагато менше, ніж повне резервне копіювання перед будь-яким стисненням.

Якщо у вас є повна резервна копія, скажімо, щотижня, ви можете робити щоденні диференціали та відправляти їх із сайту. Щоденне повне резервне копіювання з різними елементами все одно вимагатиме обох файлів із сайту.

Це має вирішити проблему швидкого отримання даних від A до B, C і D.

Вам, мабуть, потрібно відновити як повний, так і останній диференціал, щоб отримати найновіші дані, але ви можете, можливо, обійти це за допомогою NORECOVERY та файлу STANDBY (я не пробував це з різним відновленням протягом багатьох років, оскільки я останній раз був у чистому DBA робота).

Додатковим бонусом є те, що різні резервні копії не пов'язані з поточними резервними копіями журналу, тому ви можете відокремити будь-яку вимогу з високою доступністю / DR від вимоги "отримати дані до мавп коду".

Я бачу деякі проблеми, якщо у вас є щоденні повні резервні копії за політикою чи аудитом, але розширення відновлення можна застосувати до відновлення будь-якого журналу, щоб скоротити час відновлення. На відміну від резервного копіювання, відновлення diff та журналів взаємодіють.

Сподіваюся, я покрив більшість баз ...

Існують комерційні продукти, які можуть допомогти вам стиснути резервні копії краще, ніж натиснуті на 2008 рік. Прикладами є резервне копіювання RedGate , Hyperbac , Idera SQL Backup , Litespeed Backup .

Вони поставляються із додатковою вартістю високих процесорів та типів файлів, які потрібно обробляти інструментами, що не входять до складу MS. Це за винятком Hyperbac (зараз придбаного Redgate), який обробляє файли прозоро і дозволяє створювати файли, сумісні з zip (а також не потрібні сторонні інструменти).

Але не існує жодного інструменту, який запропонує вам файл розміру, який ви отримали, зробивши вручну очищення. Перегляньте статтю Brent Ozar: Як насправді стиснути резервні копії SQL Server , він порадить робити ті самі кроки, що і у вас. 2.

Питання 1: Чи існує комерційний резервний продукт, який надасть аналогічний розмір резервного копіювання, як вилучення несуттєвих даних, таких як індекси, із бази даних?

Ні. Там багато продуктів для стиснення резервного копіювання (Quest LiteSpeed, резервна копія SQL Red Gate, Idera SQLSafe, Hyperbac тощо), але всі вони функціонують, просто стискаючи вихід регулярного процесу резервного копіювання SQL Server. Деякі з них роблять це хитрими способами - опція HyperBac та LiteSpeed's Engine - це драйвери фільтрів файлової системи, тобто вони перехоплюють вихід на шляху до диска, але кінцевим результатом усіх цих продуктів є лише стиснене резервне копіювання.

Питання 2. Чи є там вичерпний сценарій, щоб скинути всі ці додаткові дані?

З часом, коли ви зберігаєте більше історії в базі даних (4, 5, 8, 10 років), ви не захочете видобувати всі дані індексу та перебудовувати їх з іншого боку WAN. Натомість ви хочете просто передати змінені дані, і саме там надходить журнал доставки.

Ти не повинен цього робити.

Але якщо ви дійсно хочете це зробити (і ні, я вам не допоможу), ви можете зробити це за допомогою резервного копіювання файлових груп. Налаштуйте такі групи файлів бази даних:

• Основна група файлів (необхідна, але залиште її порожньою)
• Група файлів ClusteredIndex (покладіть сюди свої кластерні індекси)
• ExtraneousCrap Filegroup (помістіть тут усе інше)

Почніть робити стислі резервні копії файлових файлів лише перших двох і скопіюйте ці менші на ваш DR-сервер. Ви можете використовувати резервне копіювання та відновлення файлових груп SQL Server 2008 для відновлення первинних та групових файлів ClusteredIndex, і вони одразу будуть доступні для запитів. Вони насправді не стануть працездатними, поки ви не отримаєте ту групу файлів ExtraneousCrap в Інтернеті, але для цього теж є неприємний фокус - у книзі MVP Deep Dives є розділ про редагування системних таблиць для того, щоб зробити групу файлів ExtraneousCrap та всі зв'язаних індексів зникають. Цей трюк небезпечний, абсолютно не підтримується, і чорт поганої ідеї - але ей, ви просили його.

Я рекомендую перейти на щось на кшталт доставки журналів. По суті, якщо у вас є вибір надсилання 30 Гіг за 24 години проти надсилання в кінці дня протягом коротшого часового вікна, швидкість мережі буде меншою проблемою для вас.

Ваші розробники в повільній мережі також зможуть завантажувати файли зручнішого розміру через FTP або будь-який процес, який у вас є. Вони також могли налаштувати завдання, які завантажуються протягом дня.

На додаток до стиснення сервера sql, ви можете реалізувати сторонній інструмент, такий, що має більш високу компресію, як lESpeed ​​або Redgate sqlbackup.

Крім того, на стороні мережі ви можете встановити мережеві пристрої, які можуть оптимізувати вашу пропускну здатність до сайту ДР. У минулому я успішно використовував Riverbed Appliance, щоб успішно отримати резервне копіювання 90 ГБ від FL до VA менше ніж за 3 години.

Іншим варіантом буде резервне копіювання конкретних груп файлів, виключаючи індекси тощо, але ви все ще застрягли з кластерними індексами, і залежно від вашої структури db ви можете отримати більше витрат / клопоту, ніж користі від цього підходу.

Спасибі

Якщо у вас є гроші на це, а ваша архітектура дозволяє, перегляньте щось на зразок технологій Riverbed (http://www.riverbed.com/us/). Такий пристрій у поєднанні зі сценарієм доставки чи копіювання журналу може бути найкращим варіантом.

Якщо ні, то кілька запитань. Якщо вам потрібно робити оновлення лише кожні кілька місяців, навіщо турбуватися про пропускну здатність? Єдиний раз, коли вам доведеться потурбуватися про передачу, це один раз, отримати повну резервну копію там, щоб зробити відновлення локально, або я помиляюся, що це ваша установка?

Інша можливість - замість того, щоб перейматися отриманням усіх цих даних, налаштувати середовище Citrix та віддалити їх до вас. З Citrix у вас мінімальні вимоги пропускної здатності між клієнтом / хостом, і ви маєте можливість робити все, що вам потрібно локально, і не турбуватися про необхідність повторювати ці зміни в іншому місці. Тільки мої 0,02 долара

Я б використовував транзакційну реплікацію SQL. Початкове завантаження потребує певного часу, але як тільки ви встали та працюєте, ви могли лише надсилати інформацію, яку ви хочете. Наприклад, якщо у вас є лише 3 або 4 таблиці, які оновлюються, ви можете надіслати лише ті 3 або 4 таблиці.

Ви також можете вибрати те, що ви хочете перевезти. Показники FK, кластеризовані / некластеризовані індекси, схеми розділів таблиць, збережені документи та інші.

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

Якщо це не варіант, ви можете використовувати REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . Я використовував це раніше і отримував рівень стиснення до 90%. Набагато менше, ніж у SQL.