Чому так важливо створювати резервну копію журналу транзакцій?

Зараз ми реалізуємо рішення для резервного копіювання для клієнта, а їхнє рішення ERP використовує SQL Server.

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

Я трохи читав цей журнал транзакцій, і не розумію, чому це так важливо, коли я вже створюю резервну копію всієї машини (ми використовуємо ArcServe UDP, який знає про SQL Server і використовує VSS). Наскільки я розумію, що завдання очищення в VM SQL Server вже піклуються про обрізання журналу, проте UDP також дозволяє усіляти журнал журналу SQL Server.

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

Це потрібно робити, лише якщо для вашого режиму відновлення БД встановлено "повний". Якщо він встановлений на "просто", вам не доведеться робити резервну копію журналу транзакцій. Але слідкуйте за різницею цих двох варіантів!

Перш за все: Якщо ви хочете мати можливість відновити БД до певного моменту, вам доведеться використовувати режим "повний". (Я думаю, ви можете налаштувати хронологію настільки точно, що навіть можете вказати мілісекунди для точки відновлення) У "простому" режимі ви можете повернутися лише до останньої повної резервної копії .

Якщо не створити резервну копію / скорочення журналу транзакцій, він буде рости весь час (у повному режимі). Я бачив бази даних, де файл .trn був більш ніж удвічі більшим, ніж сама база даних. Це залежить від того, як часто вносилися зміни в БД.

Ще один момент полягає в тому, що резервне копіювання журналу зазвичай швидше, ніж повне резервне копіювання.

Тому я вважаю, що ваш план резервного копіювання щодня робити повне резервне копіювання не є оптимальним. Але це залежить від вашої ситуації:

Якщо ви скажете: Гаразд, якщо я можу відновити БД до останньої повної години, все гаразд. -> Ви також можете подумати про те, щоб встановити режим відновлення на "простий", якщо ви хочете тримати повну резервну копію щогодини.

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

Сподіваюсь, це допомагає.

Добре. Вас турбує те, що якщо у вас модель відновлення встановлена ​​на повну, і ви не створюєте резервну копію журналу транзакцій за допомогою резервної копії SQL (а не резервної копії сервера), журнал транзакцій продовжує зростати, поки він не затребує весь доступний дисковий простір. (Я колись бачив, як менший колега встановлює SQL Server на системний диск і ніколи не створює резервні копії журналу транзакцій. Він їв Windows .)

Так, воно також відновиться до певного моменту. Вниз до хвилини. Як каже Twinkles, так, люди скидають столи та подібне.

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

Ми також управляємо кількома ERP системами. І проблема часто полягає в тому, що вночі часто існують багаточасні пакетні завдання, які синхронізують дані з іншими системами. І вони займають іноді годину і більше. Тож, що ви хочете зробити у випадку аварії - це перейти до точки, де у вас є узгоджені дані. (Що означає право між двома пакетними завданнями.) Якщо ви дивитесь лише на час, ви не завжди можете точно знати, яким був статус бази даних у цей час.

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

Є кілька причин, чому ви хочете це зробити:

1. Система баз даних зазвичай зайнята, можливо, робить тисячі транзакцій в секунду. Дані можуть бути розкинуті по декількох файлах у різних файлових системах. Переконатися, що після відновлення база даних перебуває у послідовному (також корисному) стані, не суттєво. Якщо ваше резервне рішення вирішує завдання, чудово, але вам краще бути впевненим у цьому, перш ніж робити ставку на роботу.
2. Приклад: хтось помилково скидає таблицю з важливими даними. Якщо у вас є резервне копіювання бази даних з можливістю відновлення в момент часу, ви можете відновити дані швидко, не потребуючи відновлення всієї системи.
3. Якщо база даних перебуває в повному режимі відновлення, журнал транзакцій SQL Server зростатиме. Місце для зберігання в журналі транзакцій повторно використовується лише у тому випадку, якщо журнал транзакцій був резервний. Якщо ви не регулярно створюєте резервні копії журналу транзакцій, ваша файлова система заповнюватиметься, поки не залишиться місця. Після цього все негайно припиниться , оскільки не можна починати нових транзакцій.

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

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

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

Тут відновлення справді є проблемою, а не резервним копією. І це не технічне рішення, це ділове рішення!

Якщо власники вашого бізнесу в порядку, втрачаючи годину або більше своїх транзакцій із базою даних (що може бути ДУЖЕ складно або неможливо повторно!), Тоді ваша модель працює. Якщо вони в порядку, коли система не працює годинами, коли ви відновите всю базу даних із резервного копіювання, ваша модель працює.

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

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

Відповідь, якщо ви запитаєте їх, може бути: "НІ дані не можуть бути втрачені! Система ERP повинна бути доступна 24/7/365!" ... що, як ми всі знаємо, навряд чи може бути рентабельним. Якщо ви представите їм вартість, пов’язану з побудовою такої надмірної безперервної системи, вони придумають більш розумну цифру ..;)

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

Кожен отримав чудові відгуки на це, але я хотів би додати ще одну важливу примітку ... або дві.

Знання деталей моделей відновлення SQL Server та ваших бізнес-вимог щодо втрати даних є дуже важливими; однак у цьому випадку обов'язково потрібно зрозуміти, як працює ваш резервний продукт із SQL Server. (На підставі вищезазначених коментарів, це здається, що ви створюєте резервну копію томів диска за допомогою копії VSS, що означає, що додаткові резервні копії на SQL Server можуть бути або не потрібні.)

Нещодавно оцінивши подібний продукт, деякі важливі моменти, про які вам може знадобитися, - це:

• Як виконуються відновлення до певного часу для бази даних при повному відновленні?
• Як обробляється початкова резервна копія для нової бази даних при повному відновленні?
• Чи потрібен продукт резервного копіювання для резервного копіювання журналу SQL Server до певного часу? (У моєму випадку відповідь була так.)
• Чи може ваша інфраструктура зберігання обробляти об'єм даних для копій / диференціалів VSS (через заданий інтервал) на додаток до звичайного завантаження SQL?

Сподіваюся, це корисно.

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

Як і багато інших, хто вже сказав, якщо ви використовуєте сторонній інструмент для резервного копіювання / знімка або VM, або сховища, ви все одно ризикуєте не мати дійсної резервної копії. Усі сторонні інструменти, які керують резервними копіями SQL Server, реалізують та підключатимуться до SQL Server за допомогою VSS. Це робиться для того, щоб вимагати, щоб SQL Server припинив всі введення / виведення файлів даних, щоб можна було зробити послідовний знімок. Якщо ні, то у вас може бути багато транзакцій у різних станах, і відновлення не буде знати, чи ці транзакції можна прокрутити вперед або назад.

Я не працював з будь-якими третіми сторонами інструментами для знімків зображень VM / Storage, але ті, з якими я працював, ніколи не змогли здійснити зберігання знімків, де знаходилися системні бази даних - SQL Server не може закрити ці бази даних. Вони ВСІ створили резервну копію цих баз даних в потоковому режимі - тобто ... видаючи команди BACKUP DATABASE, а потім оснащуючи сам файл резервної копії.

Крім того, як багато хто також говорив, якщо ви перебуваєте у моделі ПОПУСКУВАННЯ відновлення, і ви регулярно не видаєте оператори BACKUP LOG, журнал транзакцій буде продовжувати зростати, поки на диску не залишиться місця.

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

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

Часта резервна копія файлів журналу робить кілька речей:

1. Це зменшує кількість VLF у фізичних файлах журналу, що добре для продуктивності.
2. Ви краще підготуєтесь до резервного копіювання журналу у випадку, якщо вам потрібно відновити базу даних.
3. Це зовсім швидше, ніж повна резервна копія

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

З іншого боку, якщо ваш додаток генерує багато транзакцій між вашими погодинними повними резервними копіями, це може пояснити, чому оригінальні розробники запропонували більш детальне обслуговування журналу. Багато транзакцій може збільшити кількість VLF у ваших журналах, що може спричинити штраф за ефективність, поки журнал не буде усічений. Я бачив це, виражене як помилка "закінчився час запиту" в додатку (незадовго до того, як він зависне).

Рекомендації, пов’язані з обслуговуванням журналу транзакцій, дуже добре описані в цій статті 8 кроків до покращення пропускної здатності журналу транзакцій . Крім того, у цій статті Основні поради щодо ефективного обслуговування баз даних згадується дещо довільний підрахунок VLF, націлений на (<200), який спрацював для мене дуже добре.

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

Для мене виникла пара вагомих причин, які не зверху. Що робити, якщо у стороннього додатка не вдалося взяти резервну копію, яку можна відновити? Ви намагалися відновити резервну копію? Що з новим сервером, який ви тільки що створили з ваших шаблонів (думайте, DR)? Що з іншим сервером вашого домену, який має інше порівняння? або екземпляр SQL?

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