Альтернативи мережі резервного копіювання

У нашому середовищі є деякі сервери, які знаходяться у групі Always On Availability, і деякі, які є окремими.

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

Сценарій Ola hallengren використовується для стиснення, а також розбиття файлів резервного копіювання. Я виконую лише щоденні "повні" резервні копії. Резервні копії збираються на мережевий накопичувач EMC isilon.

Мені ніколи не подобається EMC DD Boost. Єдина альтернатива - зробити локальну резервну копію та скопіювати на ту саму мережу.

Чи існує ефективний спосіб, відмінний від вищевказаного?

Альтернатива, яку ви згадали, здається, найкращий вибір.

Що ви можете зробити, це двоступеневий процес:

• Створіть резервні резервні копії на сервері sql, використовуючи локальне рішення для резервного копіювання Ola.
• Використовуйте Robocopy, щоб зробити передачу на загальну мережу. Це роздільно і може працювати як заплановане завдання Windows.

Таким чином, ваші резервні копії є локальними, і вони будуть швидкими. Вам знадобиться більше місця на диску і, очевидно, надмірність (що робити, якщо резервний диск вийде з ладу - ви не хочете втрачати всі свої резервні копії).

Крім того, як рекомендує Макс Вернон, зробіть Robocopy як крок у роботі резервного копіювання, щоб переконатися, що робокопія відбувається лише за умови успішного завершення резервного копіювання, і якнайшвидше після завершення резервного копіювання. Резервне копіювання є таким же ризиком, що й дані, якщо воно залишається локальним.

Крім того, регулярно перевіряйте відновлення, оскільки якщо ви не можете відновити резервну копію - для чого це служить!

Також зверніться до моєї відповіді на налаштування великих баз даних SQL Backup

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

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

Вашим першим завданням повинно бути орієнтування пам’яті, для якого ви створюєте резервну копію, за допомогою Crystal Disk Mark або DiskSpd . Це дасть вам уявлення про те, як швидко ви можете розраховувати, що записи будуть в їх кращих випадках.

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

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

Пара потенційних рішень:

1. Перехід від повного лише до тижневого повного резервного копіювання та нічного диференціалу може бути простим рішенням.

2. Існує ряд параметрів, що стосуються продуктивності, які ви можете налаштувати в сценаріях Ola, ви можете налаштувати їх, щоб отримати потрібну продуктивність:

   • BlockSize
     Вкажіть фізичний розмір блоків у байтах.

     Параметр BlockSize в DatabaseBackup використовує BLOCKSIZEпараметр у команді BACKUP SQL Server.

   • BufferCount
     Вкажіть кількість буферів вводу-виводу, які будуть використані для операції резервного копіювання.

     Параметр BufferCount у DatabaseBackup використовує BUFFERCOUNTпараметр у BACKUPкоманді SQL Server .

   • MaxTransferSize Укажіть найбільшу одиницю передачі у байтах, яка буде використовуватися між SQL Server та резервним носієм.

     Параметр MaxTransferSize в DatabaseBackup використовує MAXTRANSFERSIZEпараметр у BACKUPкоманді SQL Server .

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

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

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

Ми використовуємо EMC DD Boost, і ви раді вашій власній думці про це, але ми встановили, що завдяки методам дедуплікації на стороні клієнта, який використовує, повне резервне копіювання навіть баз даних з багатьма ТБ може бути дуже швидким, до того, що нам не доведеться турбуватися про диференціальне резервне копіювання SQL Server. Насправді за допомогою EMC DD ви будете робити диференціальне резервне копіювання, але тільки не в SQL Server. Використання декількох файлів призначення також значно покращує швидкість, навіть на DDBoost.