Автоматичні бекапи сервера — 3-2-1 стратегія

Налаштування системи бекапів із перевіркою відновлення

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

Що входить

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

Чому копія на тому ж сервері не рахується

Вона рятує від помилки адміністратора чи невдалого оновлення — і це вже непогано. Але не рятує від виходу диска з ладу, блокування акаунта в хостера чи шифрувальника, який пройдеться всім, до чого має доступ. Тому одна копія обов'язково лежить поза основним майданчиком.

Скільки копій зберігати

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

Що ви отримуєте

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

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