12 типових помилок при бекапі баз даних

Автор: admin від 28-09-2015, 20:43, подивилося: 1555

Хотілося б про них розповісти, щоб адміністратори та розробники могли змінити свої підходи до управління бекапами та попередити можливі проблеми.

1. Видалення попередньої копії бекапу до того, як буде створено нову копію бекапуНайчастіше цю помилку роблять новачки, які не розуміють, що основна мета існування резервної копії БД – забезпечити мінімальну просту інформаційну систему (важливою частиною якої є БД) , а чи не просто створення копії БД. У результаті, з моменту видалення останнього бекапу до створення нового, система знаходиться в незахищеному стані, тому що в цей період база даних не має жодної резервної копії. Так як бекап може створюватися досить довго, то це ідеальний час для спрацьовування закону Мерфі. Особливо добре цей підхід працює у зв'язці з пунктом 7 (див. нижче). (і не робіть новий бекап у вже існуючий файл)

2. Перезапис існуючої бази даних при відновленні з бекапуЦю помилку роблять рідше, але результати можуть бути набагато сумнішими. Якщо бекап не перевірявся та був пошкоджений (див. пункт 6), то в результаті перезапису у вас не буде ні попередньої копії бази, ні валідного бекапу. Зазвичай це неподобство трапляється в п'ятницю ввечері, в момент дерготні, плутанини та суперечливих вказівок з боку начальства. Трохи негативного везіння і важкі вихідні в серверній забезпечені. У Firebird є якийсь захист від цієї помилки - створення рестора з бекапу за допомогою утиліти gbak з дефолтним ключем - create не спрацює вякщо зазначене ім'я файлу вказує на існуючу БД. На жаль, є і обхід цього захисту - перемикач -rep, який дозволяє переписати існуючий файл.Рекомендації: ніколи не перезаписуйте файл бойової БД, не отримавши письмового вказівки керівництва та, бажано, не отримавши пропозиції про нову роботу.

3. Використання однокрокового бекапу-рестора, без створення проміжного файлу бекапуСтандартні потоки введення-виведення дозволяють провернути з багатьма СУБД (з Firebird у тому числі) цікавий трюк: виконувати потоковий бекап з негайним відновленням БД з нього. В результаті не створюється проміжний файл бекапу. Це зручно для проведення регламентних робіт та запуску перевірного відновлення (за наявності іншої резервної копії), але в жодному разі не треба використовувати це для автоматичного бекапу! Якщо в процесі такого бекап-рестора відбудеться серйозний збій диска, наприклад, то може пошкодитися вихідна база даних, а нова ще не буде створена. Звичайно, якщо п.1 дотримується, і є копія БД від попередньої спроби, то відбудеться лише втрата даних, які були створені або змінені в БД з моменту створення її копії. -Рестор в автоматичному режимі, а в ручному завжди перевіряйте наявність достатньо свіжої копії.

4. Зберігання бекапу і бази даних на тому самому фізичному пристроїТут багато хто може посміятися, що поради ми якісь дитячі даємо – це ж абетка системного адміністрування. Так воно так, але у зв'язку з поширенням віртуальних середовищ і БД, і диск можуть перебувати на одній СГД. А вона обов'язково зламається в найбільш невідповідний для бізнесу момент. Плюс, все ще існують люди, які вірять у те, що якщо вони використовуютьRAID (від 1 і вище), то з їхніми даними взагалі нічого не може статися. Ще є люди, які вірять у наднадійність «брендового» заліза, але це особливий випадок.Рекомендації: не зберігайте бекап і БД на тому самому фізичному пристрої, яким би надійним воно не здавалося.

5. Відсутність перевірки успішного закінчення бекапуОсь це досить часта помилка і адміністраторів, і керівників ІТ підрозділів. Якщо результат бекапу не перевіряти, то можна бекап не робити взагалі — результат загалом той самий. Обов'язково потрібні нотифікації по email про успішний бекап, а ще краще і по СМС. Причому відсутність нотифікації – це ознака проблеми! А до чого тут керівники, запитає уважний читач, який дочитав до цього місця? А при тому, що адміністратор зазвичай бекап налаштує, але нотифікації йому перевіряти ліньки, тим більше що лежать вони у нього в окремій татці, і тому керівнику ІТ-відділу треба періодично вимагати додатковий звіт про стан усіх бекапів. Це питання, кого карати, якщо бекапи начебто є, але у потрібний момент їх виявилося :) ! А при комбінуванні з пунктом 2 отримуємо відсутність і бази, і бекапу.Рекомендації: використовувати інструменти автоматизації бекапів, які вміють відслідковувати успішні та неуспішні бекапи, повідомляти користувачів про проблеми, та мають оглядові засоби контролю (особливо) актуально, коли потрібно контролювати десятки та сотні бекапів на різних серверах).

8. Відсутність контролю за вільним місцем для бекапуЗагалом, це класична помилка - при нестачі місця бекап займає все вільне місце і аварійно завершується. При розміщенні бекапу на одному диску разом з БД може призвести до зупинки роботи з БД, при розміщенні на системному диску - до поломки системи.комбінації з пунктом 4 у кращому разі отримаємо зупинку роботи системи, тому що базі даних теж потрібно вільне місце, а воно скінчилося через бекап. А в комбінації з пунктами 5 і 2 знову отримуємо в результаті відсутність і бази, і бекапу .Рекомендації: використовувати інструменти для бекапу, які роблять прогноз розміру бекапу і попереджають про можливу нестачу місця.

9. Відсутність контролю часу тривалості бекапуБуквально півроку тому бекап тривав 40 хвилин, і раптом став 3 години – чому? Можливо, виріс розмір БД, а можливо, випав диск з RAID-масиву, через що швидкість запису різко деградувала, і всі ваші бекапи ось-ось покинуть цей тлінний світ. А може бути, добрий колега одночасно включив ще одну систему резервного копіювання (до речі, в Firebird можна запустити кілька бекапів відразу, тільки не дуже зрозуміло, навіщо це може бути потрібно). Якщо не контролювати час виконання бекапу, то можна переглянути виниклу проблему і прогаяти шанс виправити її до того, як вона стане великою. Також, у випадку, якщо система резервного копіювання не відстежує стану завдань, а запускає їх просто за графіком, легко можна потрапити на «ранковий тролейбус» — це коли новий бекап може початися в момент, поки попередній ще не закінчився.Рекомендації: використовувати засоби контролю тривалості процесу бекапу.

10. Виконання бекапу БД під час застосування апдейтів ОСДуже часто проблема, особливо в комбінації з п.9 і включеними автоматичними апдейтами Windows (які за замовчуванням відбуваються о 3 ночі). У кращому випадку призводить до уповільнення процесу, а якщо ОС перевантажується для застосування апдейтів, то бекап буде зіпсований. Добре ще, що апдейти ОС не щоднятрапляються.Рекомендації: Якщо не можна відключити, то призначте апдейти ОС на такий час, коли вони не зможуть перешкодити бекапам.

Для Firebird необхідно блокувати основний файл БД за допомогою nbackup до початку резервного копіювання та розблокувати після закінчення, для інших СУБД є аналогічні засоби увімкнення/вимкнення відповідних режимів.

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

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

Ну, і звичайно - не забувайте пестити і плекати свою адмінську параною, наприклад, візьміть і перевірте свої бекапи ... ось прямо зараз!