12 поширених помилок під час резервного копіювання баз даних

автор: Олексій Ковязін, 11 листопада 2015 року

Завантажити PDF (англійською) Ця стаття спочатку призначалася для розробників та адміністраторів СКБД Firebird, але контакти з адміністраторами інших баз даних показали, що більшість помилок є спільними для всіх, і буквально кожен наступає на одні й ті ж граблі. Якщо ви можете додати щось до цього списку (навіть щось специфічне для конкретної СКБД), зв’яжіться з нами електронною поштою [email protected].

1. Видалення попередньої резервної копії до створення нової

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

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

Рекомендації: не видаляйте попередню резервну копію до створення нової! (і не створюйте нову резервну копію в існуючий файл).

Рекомендація для Firebird: Інструмент FBDataGuard, що входить до складу HQbird (розширеного дистрибутивного пакета Firebird), видаляє найстарішу резервну копію в історії лише після створення нової.

2. Перезапис існуючої бази даних під час відновлення з резервної копії

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

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

Firebird має певний захист від цієї помилки - неможливо відновити базу даних з резервної копії за допомогою утиліти gbak, якщо використовується стандартний ключ -create і якщо вказане ім’я файлу вказує на існуючу базу даних. На жаль, є спосіб обійти цей захист: ключ -rep все ще дозволяє перезаписати існуючий файл.

Рекомендація: ніколи не перезаписуйте файл робочої бази даних без письмової вказівки від вашого керівництва.

Рекомендація для Firebird: Використовуйте FBDataGuard, оскільки він ніколи не перезаписує файл бази даних.

3. Використання одноетапного резервного копіювання/відновлення без проміжного файлу резервної копії

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

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

Рекомендації: не використовуйте одноетапне резервне копіювання/відновлення в автоматичному режимі та завжди перевіряйте наявність достатньо свіжої копії в ручному режимі.

4. Зберігання резервних копій і бази даних на одному фізичному пристрої

Багатьом з вас може здатися смішним, що наша порада є досить дитячою - абетка резервного копіювання. Так, це правда, але через популярність віртуальних середовищ база даних і диск можуть опинитися в одній системі зберігання даних. І вона обов’язково вийде з ладу в найневідповідніший момент. До того ж досі є люди, які вірять, що з їхніми даними нічого не може статися, якщо вони використовують RAID-масиви (версії 1 або вище :)). Крім того, є люди, які вірять, що деякі “брендові” сервери є безвідмовними, але це окремий випадок.

Рекомендації: не зберігайте резервні копії та базу даних на одному пристрої, наскільки б надійним він не здавався.

5. Відсутність контролю за успішним завершенням процесу резервного копіювання

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

Уважний читач, який дістався до цього місця нашої статті (хоча нагороджувати його ще зарано), може запитати: “А яке відношення це має до керівництва?” Ось яке - адміністратор зазвичай налаштовує процес резервного копіювання, але йому занадто нудно перевіряти сповіщення, особливо коли вони зберігаються в окремій папці, тому ніколи не зайве вимагати додаткові звіти про стан процесу. Це стосується питання, хто винен, коли здається, що резервні копії є, але насправді їх немає саме в той момент, коли вони потрібні :)

! у поєднанні з проблемою 2 ми не маємо ні бази даних, ні її резервної копії.

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

Рекомендація для Firebird: FBDataGuard перевіряє, чи завершено процес резервного копіювання, і надсилає відповідне сповіщення. Для систем з великою кількістю баз даних існує дворівневий зведений моніторинг за допомогою інструмента Control Center, який дозволяє бачити статуси всіх контрольованих серверів і баз даних на одній сторінці.

6. Відсутність перевірки резервних копій

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

Тому ви повинні регулярно перевіряти створювані резервні копії, щоб переконатися, що вони не пошкоджені та не скопійовані в /dev/null.

Рекомендація для Firebird: ви можете автоматизувати перевірку резервних копій за допомогою FBDataGuard.

7. Відсутність перевірки стану бази даних при використанні неперевірених резервних копій

Зазвичай бази даних використовують кілька типів резервного копіювання - дампи, звичайні резервні копії тощо. Не вдаючись у деталі, можна виділити дві категорії: перевірені та неперевірені. У випадку Firebird це gbak та nbackup.

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

Nbackup (він же інкрементальне резервне копіювання) тимчасово блокує основний файл бази даних для оновлень (у узгодженому стані) і дозволяє швидко скопіювати файл бази даних (повністю або частково/інкрементально).

У випадку великих баз даних Firebird (понад 500 ГБ) доцільно використовувати nbackup, щоб не сповільнювати операції користувачів, але водночас необхідно перевіряти базу даних, оскільки неперевірені резервні копії, які він створює, є копіями сторінок бази даних, і якщо помилка знаходиться на рівні записів (через збій оперативної пам’яті) або на логічному рівні, неперевірена резервна копія міститиме її так само, як і оригінальна база даних.

Щоб уникнути цього, слід використовувати онлайн-перевірку оригінальної бази даних (онлайн-перевірка за допомогою gfix доступна починаючи з версії Firebird 2.5.4, тоді як наш інструмент FBDataGuard підтримує онлайн-перевірку бази даних для версій 1.5-2.5).

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

Рекомендація для Firebird: окрім онлайн-перевірки стану, FBDataGuard дозволяє тестувати процес відновлення з резервної копії в автоматичному режимі.

8. Відсутність контролю за вільним місцем для резервних копій

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

У поєднанні з проблемою 4 найкращим можливим результатом буде ситуація, коли система перестає функціонувати, оскільки базі даних також потрібне вільне місце, але воно зайняте резервними копіями. Щодо поєднання з проблемами 5 і 2, це знову залишає нас без бази даних та її резервної копії.

Рекомендації: використовуйте інструменти резервного копіювання, які прогнозують розмір резервної копії та попереджають про можливу нестачу вільного місця.

Рекомендація для Firebird: FBDataGuard контролює розмір вільного місця для резервного копіювання, а також розмір вільного місця на диску з базами даних та на системному диску.

9. Відсутність контролю за часом створення резервної копії

Процес резервного копіювання займав 40 хвилин буквально пів року тому, а тепер раптом уже три години - чому? Розмір бази даних міг збільшитися, або диск міг випасти з вашого RAID-масиву, що призвело до значно повільнішої продуктивності запису, і всі ваші резервні копії можуть бути на межі зникнення. Або ваш добрий колега міг запустити ще одну систему резервного копіювання одночасно (до речі, Firebird дозволяє запускати кілька процесів резервного копіювання одночасно, хоча не зовсім зрозуміло, навіщо це взагалі може знадобитися). Якщо ви не контролюєте час створення резервної копії, ви можете пропустити нову проблему, що виникла, і втратити шанс виправити її до того, як вона стане масштабною.

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

Рекомендації: використовуйте інструменти, які контролюють час процесу резервного копіювання!

Рекомендація для Firebird: FBDataGuard контролює час процесу резервного копіювання.

10. Резервне копіювання бази даних під час застосування оновлень операційної системи

Це дуже поширена проблема, особливо в поєднанні з проблемою 9 та увімкненими автоматичними оновленнями Windows (за замовчуванням оновлення застосовуються о 3 годині ночі). Це призводить щонайменше до уповільнення, але якщо операційна система перезавантажується для застосування оновлень, резервна копія буде пошкоджена. Принаймні, хороша новина в тому, що операційна система оновлюється не щодня.

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

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

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

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

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

1. повністю зупинити служби та процеси СКБД, щоб у кеші нічого не залишилося,
2. використовувати агенти та/або скрипти, які перемикають базу даних у спеціальний режим, що робить безпечним послідовне копіювання файлу бази даних. Наприклад, для баз даних MSSQL існує механізм під назвою VSS writer. За запитом він перемикає базу даних у режим, сприятливий для створення знімків, у момент створення знімка. Якщо ви використовуєте механізми, засновані на відстеженні змінених блоків, ви самі повинні переконатися, що база даних узгоджена в момент синхронізації.

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

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

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

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

Рекомендації: не використовуйте інструменти файлового резервного копіювання та резервного копіювання віртуальних машин без відповідних інструментів автоматизації для баз даних.

Рекомендація для Firebird: використовуйте FBDataGuard (з дистрибутивного пакета HQbird), який забезпечує інтеграцію з інструментами резервного копіювання, що підтримують VSS.

12. Заміна резервного копіювання реплікацією

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

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

Рекомендації: якщо у вас налаштована реплікація, не нехтуйте резервними копіями, використовуйте обидва підходи.

Рекомендація для Firebird: використовуйте дистрибутивний пакет HQbird Enterprise, який включає як інструменти резервного копіювання, так і реплікації.

Підсумок

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

Для Firebird (вибачте за рекламу) існує пакет під назвою HQbird, який включає FBDataGuard.

Крім того, наша компанія надає повну підтримку резервного копіювання та обслуговування для Firebird та інших баз даних - це хороший вибір для тих, хто не знайомий з усіма технічними деталями резервного копіювання.

І, звісно, продовжуйте плекати свою адміністративну параною, наприклад, встаньте і перевірте свої резервні копії прямо зараз :)

Контакти

Не соромтеся ставити будь-які запитання: [email protected]

Хочете отримувати новини та статті про Firebird? Приєднуйтесь до нас у Telegram https://t.me/firebirdsql