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

від Alexey Kovyazin, 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. Відсутність контролю за успішним завершенням процесу резервного копіювання

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

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

! у поєднанні з Проблемою 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