Випадково натиснув Delete. 8 кейсів, коли бекап (з)міг врятувати дані

Ми часто недооцінюємо, наскільки важливими для нас є дані, аж поки їх не втратимо. Зникнення файлів може вплинути не лише на роботу, а й буквально змінити життя. Наприклад, лауреат Ґреммі за продюсування хітів Кендріка Ламара Mike WiLL Made-It навіть змінив професію та зайнявся продажем нерухомості, коли в нього вкрали флешки з музикою, а резервні копії він теж втратив. 

Для бізнесу втрата даних – це ще й втрата грошей, репутації та результатів багаторічної роботи всієї команди. Один із показових свіжих кейсів: історія українського медіа «Заборона». У 2025 році стало відомо, що німецький хостинг-провайдер Hetzner автоматично видалив усю ІТ-інфраструктуру видання через прострочений на два місяці рахунок. Унаслідок цього медіа втратило контент, який створювало сім років: тисячі статей, мультимедійні матеріали та архів сайту. 

Нижче – декілька історій, які показують, до чого ще може призвести відсутність бекапів або ненадійна система резервного копіювання. 

Під час DDoS-атаки на платформу для розробників Codespaces зловмисник отримав доступ до адмінпанелі Amazon EC2, через яку керувалася інфраструктура компанії. Коли Codespaces спробували повернути контроль і змінили паролі, виявилося, що нападник заздалегідь створив кілька прихованих доступів. 

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

І хоча в компанії був бекап інфраструктури в AWS, у них не було жодної копії даних на власних серверах, як і не було плану відновлення. Усього за 1 день компанія вимушена була повністю припинити своє існування.  

У 2017 році вірус NotPetya фактично паралізував інфраструктуру глобальної транспортно-логістичної компанії Maersk. Особливо критичним стало те, що компанія втратила приблизно 150 контролерів домену — серверів у різних точках світу, які відповідають за автентифікацію користувачів, доступи та базову логіку роботи корпоративної мережі. Без них відновлення всієї інфраструктури було майже неможливим.  

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

Врятував Maersk випадок: у Гані знайшли єдиний неушкоджений контролер домену, який у момент атаки був відключений від мережі через перебої з електрикою. Саме ця машина стала основою для відновлення. Цей кейс показує, що резервування усередині системи – не те саме, що повноцінний бекап. Якщо всі копії доступні для атаки, компанія може втратити все.  

Підписуйтеся на наші соцмережі

Пожежа в датацентрі OVHCloud у Страсбурзі в 2021 році знищила понад 30 тисяч серверів. В один момент перестали працювати 3,6 млн сайтів, відключивши 2% усіх вебсторінок з доменом .fr, серед яких банки та державні послуги.  

Об’єктивно компанія не подбала належним чином про безпеку: у датацентрі не було автоматичної системи пожежогасіння, була затримка у вимкненні електроживлення, а загоряння спричинило потрапляння води на інвертор. Окрім того, OVHCloud надала кільком клієнтам некоректну інформацію про розміщення і стан їхніх серверів, через що не всі змогли швидко врятувати дані. У результаті компанія зіткнулася з близько 140 позовами, і за деякі з них суд постановив стягнути по €100+ тисяч. 

Ще одна пожежа призвела до закриття державних сервісів цілої країни. У 2025 році в датацентрі південнокорейської National Information Resources Service (NIRS) у Теджоні сталася пожежа, яка паралізувала 647 сервісів, включно з порталом державних послуг, поштою, аварійно-рятувальними службами. Усього втрачено 858 ТБ даних, зібраних упродовж 8 років роботи. 

Особливо постраждала система G-Drive, яку держпосадовці використовували для зберігання файлів. Незадовго до інциденту міністр внутрішніх справ і безпеки Республіки Корея доручив працівникам міністерства не зберігати нічого на власних комп’ютерах і натомість відправляти все у G-Drive. Ця система не мала бекапів, а отже вся важлива інформація міністерства та інших держструктур була втрачена.  

У 2020 році чергове оновлення Adobe Lightroom на iOS видалило усі фото та платні елементи оформлення користувачів. Ці дані так і не вдалося відновити, а керівництво Adobe порадило користувачам надалі синхронізувати запис файлів у хмарне сховище Lightroom чи iCloud. 

Того року це був не єдиний випадок втрати великої кількості фото. Усього через кілька місяців після презентації нової платформи image.canon з передачі даних з камери відразу у хмару, більшість файлів з позначкою «для довготривалого зберігання» звідти просто зникли. 

Через помилку бекапів «Історія іграшок 2» могла так і не вийти на екрани. Під час внесення правок до капелюшка Вуді одна помилкова дія видалила два місяці роботи усієї команди аніматорів.  

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

У 90-х У Pixar не проводили регулярної перевірки резервних копій. Саме тут і почалися проблеми: бекапи зберігалися на стрічковому накопичувачі, і коли розмір файлів досяг 4 гігабайтів, нові дані продовжували записуватися на носій, але при цьому стиралися старіші файли, про що у Pixar тоді ще не знали. 

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

Через відсутність бекапів можна втратити не лише фільми, а й історичні артефакти. Після висадки Apollo 11 на Місяць у 1969 році NASA зберігала оригінальні записи цієї події на випадок, якщо виникнуть проблеми в онлайн-трансляції. І більше ці стрічки ніхто не бачив: у 1970-1980-х роках їх розмагнітили й повторно використали, щоб зекономити кошти на покупці носіїв. У результаті людство втратило оригінальний запис у найкращій якості, а сьогодні має лише пізніші копії телевізійної трансляції, гірші за якістю. 

У 2021 році Університет Кіото в Японії втратив близько 77 ТБ дослідницьких даних через збій у програмі резервного копіювання суперкомп’ютера. Помилка в оновленні системи призвела до того, що замість обробки файлів програма почала їх видаляти. У результаті зникло приблизно 34 мільйони файлів, створених 14 дослідницькими групами.

Розробник суперкомп’ютера Hewlett Packard Enterprise взяв повну відповідальність за цей інцидент на себе.  

Як можна помітити, дані можуть зникнути у найбільш неочікуваний момент, саме тому бізнесу потрібна продумана система безперервності. Зокрема в GigaCloud ми рекомендуємо поєднувати бекапи у хмарі з інструментами аварійного відновлення (реплікації), розробляти Business Continuity Plan і дотримуватися правила 3-2-1: мати три копії даних, зберігати їх на двох різних носіях або локаціях, і щонайменше одну розмістити поза основною інфраструктурою. А також постійно тестувати систему резервного копіювання. 

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