Неперевірені бекапи й рахунки за хмару, що ростуть: два ризики робочої системи

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

КОРОТКО

Два ризики, яких не видно на екрані

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

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

Щодо витрат є ринкові дані. У звіті State of the Cloud 2026, опублікованому 18 березня 2026 року, Flexera оцінила частку змарнованих грошей на хмару в 29%, і це перше зростання за п'ять років. Звіт базується на глобальному опитуванні понад 750 фахівців, які ухвалюють рішення щодо хмари й користуються нею; 85% з них назвали керування витратами на хмару однією з головних проблем. Цифра втрат складається з оцінок самих респондентів, але напрям зрозумілий: за їхньою власною оцінкою, майже третина грошей, які компанії платять за хмару, не приносить користі.

Бекап, який ніхто не відновлював, це надія за розкладом.

ВІДНОВЛЕННЯ

Бекап доводиться відновленням

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

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

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

Американське агентство з кібербезпеки та захисту інфраструктури CISA вимагає того самого у своєму посібнику #StopRansomware Guide: зберігати офлайн зашифровані резервні копії критичних даних і регулярно перевіряти їхню доступність і цілісність у сценарії аварійного відновлення. Причина практична: багато програм-вимагачів шукають доступні їм бекапи й видаляють або шифрують їх.

Перше відновлення має пройти в спокійний вівторок, а не під час аварії.

ЩО КОПІЮВАТИ

База, файли, налаштування й секрети

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

• База даних. Замовлення, клієнти, заявки, товари, ціни й контент усіма мовами. В активному магазині вона змінюється щохвилини, тому її копіюють найчастіше.
• Завантажені файли. Фото товарів, документи клієнтів, сформовані рахунки. Вони лежать поза базою, і про них забувають найчастіше.
• Налаштування. Параметри вебсервера і PHP, потрібні коду розширення PHP, завдання за розкладом, змінні середовища й DNS-записи. Більшої частини цього немає в репозиторії, тому заново зібраний сервер може запускати той самий код і поводитися інакше.
• Секрети. Паролі до бази, API-ключі платіжних систем і служб доставки, доступи до пошти, ключі шифрування. Їх має бути можливо відновити, але вони ніколи не лежать відкритим текстом поруч із бекапами чи в коді: їхнє місце в менеджері паролів або в сховищі секретів, наприклад Vault чи менеджері секретів хмарного провайдера.

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

Де лежать копії, так само важливо, як і що в них. Копія на тому самому сервері захищає від випадкового видалення й майже ні від чого більше. Правило, яке цитують найчастіше, походить із роботи, підготовленої Університетом Карнегі-Меллон для US-CERT, тепер частини CISA: зберігайте три копії будь-якого важливого файлу, одну основну й дві резервні; тримайте їх на двох різних типах носіїв; одну копію зберігайте поза офісом. Для сайту у 2026 році це означає робочі дані, копію в іншого провайдера або в окремому акаунті сховища і третю копію, яку не можуть видалити навіть доступи робочого сервера. Посібник CISA додає сучасну половину правила: копії мають бути офлайн і зашифровані, щоб пережити зловмисника, який уже дістався сервера.

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

RPO І RTO

Скільки можна втратити і скільки чекати

Два числа визначають, як часто робити бекапи і скільки коштує вся схема. NIST у посібнику з планування безперервності SP 800-34 визначає цільову точку відновлення (RPO) як момент часу, на який дані мають бути відновлені після збою, а цільовий час відновлення (RTO) як строк, який система може перебувати у відновленні, перш ніж збій почне шкодити бізнесу.

Простіше кажучи, RPO відповідає на питання «скільки роботи ми можемо дозволити собі втратити?», а RTO на питання «скільки ми можемо дозволити собі простояти?». Якщо бекап робиться о 2 ночі, а сервер падає о 6 вечора, зникає шістнадцять годин замовлень, заявок і змін в адмінці. Для корпоративного сайту, який змінюється раз на тиждень, втрата невелика. Для магазину, який приймає замовлення весь день, це означає обдзвонювати клієнтів і питати, що вони купили.

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

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

RPO і RTO це рішення бізнесу, які просто записані в годинах.

РАХУНОК ЗА ХМАРУ

Витрати, які ніхто не затверджував

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

Джерела зростання майже на всіх рахунках однакові:

• Сервери, що простоюють, і завеликі сервери. Машини, розраховані на пік, який більше не повторився. Сервер бази даних, обраний «із запасом на зростання» кілька років тому, часто виявляється найбільшим рядком рахунку.
• Забуті тестові середовища. Повна копія робочої системи, зібрана під один проєкт і так і не вимкнена, нерідко з реальними даними клієнтів на сервері, який ніхто не оновлює.
• Логи й знімки, які зберігаються вічно. В Amazon CloudWatch Logs логи за замовчуванням зберігаються безстроково, доки хтось не задасть строк зберігання для кожної групи логів. У власних прикладах цін AWS використовує $0,05 за ГБ на місяць для стандартного зберігання знімків EBS, і політика знімків, яка нічого не видаляє, збільшує цей рядок щодня.
• Дрібні платежі, що множаться. Кожна публічна IPv4-адреса в AWS коштує $0,005 на годину, використовується вона чи ні, тобто близько $3,65 на місяць. NAT-шлюз коштує $0,045 на годину в регіоні US East (Ohio), близько $33 на місяць, плюс $0,045 за кожен оброблений гігабайт.
• Вихідний трафік. AWS дає 100 ГБ вихідного трафіку в інтернет безкоштовно щомісяця по всіх сервісах разом; далі оплачується кожен гігабайт, і це помітно для сайтів із великими файлами або під час копіювання бекапів до іншого провайдера. (Цифри AWS перевірені в жовтні 2026 року.)

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

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

Налаштування часто обходиться дешевше за залізо. У проєкті на Laravel 7, про який ідеться нижче, тариф хостингу вже містив OPcache, кеш скомпільованого PHP-коду, але його ніхто не ввімкнув. Після ввімкнення відповідь сервера пришвидшилася приблизно з 55 до 21 мілісекунди, за кілька доларів на місяць і без потужнішого сервера.

ПЕРЕВІРКИ

Що перевіряти і як часто

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

Останній рядок легко планувати, бо дати публічні. Станом на жовтень 2026 року PHP 8.2 отримує виправлення безпеки до 31 грудня 2026 року, PHP 8.3 до 31 грудня 2027 року, PHP 8.4 до 31 грудня 2028 року; Laravel 12 до 24 лютого 2027 року, Laravel 13 до 17 березня 2028 року.

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

МОНІТОРИНГ

Сповіщення, які приходять раніше за клієнтів

Перевірка доступності, яка повідомляє, що головна сторінка відповідає, пропускає більшість збоїв, що коштують грошей, бо на екрані вони нічим себе не видають. Форма може показувати подяку, а лист так і не надійде. Переїзд на новий хостинг може загубити записи SPF і DKIM, і заявки почнуть потрапляти в спам. В одному з недавніх проєктів новий хостинг із власної ініціативи закрив у robots.txt доступ для GPTBot і краулерів Meta.

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

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

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

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

БЕЗПЕЧНІ ОНОВЛЕННЯ

Тестова копія, команди деплою і шлях назад

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

Це був тримовний корпоративний сайт із власною адмінкою, системою заявок і багаторічним контентом, що працював на Laravel 7 і PHP 7.4; PHP 7.4 перестав отримувати виправлення безпеки в листопаді 2022 року. Ми перевели його на Laravel 13 і PHP 8.4: шість мажорних версій, близько трьох днів розробки, один день приймального тестування і п'ять хвилин запланованого простою. Докладно ця історія описана у статті Шість версій Laravel за три дні; тут лише те, що стосується будь-якого оновлення.

До першої зміни. Ми створили окрему гілку й записали точний коміт, який працював у продакшені. Підняли закриту тестову копію з базою і файлами, обмежену на рівні сервера, а не просто позначену noindex, і задокументували розширення PHP, налаштування, команди деплою і процедуру відкату. Далі кожна версія Laravel ішла окремою міграцією, і після кожного кроку ми перевіряли публічний сайт, адмінку, форми й журнал помилок.

Що впіймала тестова копія. У Laravel 11 змінилося налаштування шифрування пошти, і зі старими параметрами форма й далі дякувала б відвідувачам, хоча листи із заявками перестали б надходити; ми надіслали реальну тестову заявку й дочекалися листа, перш ніж вважати крок завершеним. Кешування маршрутів, звичайне налаштування швидкості в Laravel, перетворило кожну сторінку на 404, бо цей сайт будує мовні префікси з бази даних. На скасування пішла приблизно хвилина, а на робочому сайті це була б аварія. Правило «ніколи не кешувати маршрути в цьому проєкті» тепер записане в інструкціях проєкту для розробників і ШІ-агентів, у тому самому файлі, про який ми пишемо у статті про посібник до коду для ШІ.

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

Реліз і приймання. Бекап, злиття, встановлення нових залежностей на PHP 8.4, перемикання версії PHP у панелі хостингу й очищення кешів. Єдиним простоєм було застосування нової версії PHP хостингом, близько п'яти хвилин у спокійну годину. Приймання охопило 15 публічних сторінок трьома мовами, 30 екранів адмінки, реальну тестову заявку з підтвердженим листом, журнал помилок і 987 внутрішніх посилань, з яких жодне не виявилося битим.

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

ХТО ЗА ЦИМ СТЕЖИТЬ

Підтримка, DevOps чи прийом проєкту

Який формат підходить, залежить від того, в якому стані система зараз, і ми часто радимо менший варіант.

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

Рядок про прийом проєкту трапляється частіше, ніж очікують власники. Один сайт, про який ми розповідаємо у статті Оновлення старого сайту на Laravel чи PHP у 2026 році, працював на PHP 5.6, акаунт хостингу контролювала людина поза бізнесом, а листи з контактної форми відхиляв поштовий сервер; на виправлення пішло два вечори.

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

FAQ

Джерела

• Flexera: Flexera Finds Cloud Value is Rising While AI Waste Grows (звіт State of the Cloud 2026, 18 березня 2026 року)
• US-CERT, Університет Карнегі-Меллон: Data Backup Options (правило 3-2-1)
• CISA: #StopRansomware Guide
• Глосарій NIST CSRC: Recovery point objective (SP 800-34 Rev. 1)
• Глосарій NIST CSRC: Recovery time objective (SP 800-34 Rev. 1)
• AWS: ціни Amazon VPC (публічні IPv4-адреси, NAT-шлюз)
• AWS: ціни Amazon EBS (зберігання знімків)
• AWS: ціни Amazon EC2 On-Demand (вихідний трафік)
• AWS: CloudWatch Logs, групи логів і строк зберігання
• PHP: підтримувані версії
• Laravel: примітки до релізів і політика підтримки