Кожен адмін проходить три етапи прийняття бекапів: «та навіщо воно мені», «колись обов'язково зроблю» і «чому воно не піднімається». Між другим і третім зазвичай стоїть п'ятниця, вечір, одна команда rm -rf із зайвою скісною рискою і фраза «о, а де всі дані?». Давайте поговоримо про правило 3-2-1, про хмари, про те, що бекапом не є, і про те, чому половина вашого архіву не варта місця, яке займає.

Нагадування: що таке 3-2-1

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

Сучасна версія називається 3-2-1-1-0: плюс одна копія, відключена від мережі або захищена від змін (щоб вірус-шифрувальник не зашифрував усе разом із вами), і нуль помилок під час перевірки відновлення. Остання цифра найрідкісніша в дикій природі.

Що бекапом не є

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

• RAID. Це про доступність, а не про збереження. Він із великою надійністю та однаковою швидкістю повторить ваш DROP TABLE на всіх дисках одразу.
• Синхронізація. Dropbox, OneDrive і решта чудово синхронізують не лише файли, а й їхнє видалення та шифрування.
• Знімок стану на тому самому сховищі. Згорить сховище, згорять і знімки. Вони не були «копією», а лише гарним спогадом.
• «Воно ж дзеркалиться». Дзеркалування теж не бекап. Це дзеркало, яке з однаковою щирістю відображає і ваші дані, і вашу помилку.
• Копія на тому самому фізичному диску, лише в іншій папці. Привіт, backup_final_v2.

Дві школи

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

Нове покоління. Дані лежать у хмарі, бо нам розповіли, що хмара — це «надійно» і «недорого». Локальної копії немає. Іншої копії теж немає. Навіщо, адже «воно ж у хмарі»?

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

Хочеться списати все на покоління, але справа не у віці. Просто люди поділяються на дві категорії…

…точніше, на три

Стара приказка каже: є ті, хто ще не робить бекапів, і ті, хто вже робить. Час її оновити.

Є ще третя категорія: ті, хто перевіряє, що з бекапу можна відновитися.

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

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

Абсолютної надійності не існує

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

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

Наступний етап просвітління

Він настає, коли ви ставите собі прикре питання: а чи така вже цінна та інформація, яку я хочу зберегти?

І раптом з'ясовується, що головний ворог збереження даних — це їхня актуальність. Дампи бази 2016 року від проєкту, якого вже не існує. Дистрибутиви операційних систем, які не підтримуються зі смерті Windows 7. Каталог old_stuff_DO_NOT_DELETE, який ніхто не відкривав з часів попередньої роботи. Усе це ми продовжуємо копіювати з інерції, і воно з року в рік їсть місце, гроші та ліміти ліцензій.

Грамотна політика резервного копіювання містить не лише «що копіюємо», а й «що вже можна нарешті відпустити». Строки зберігання існують не для краси.

Сімейні альбоми

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

А потім ловиш себе на думці: а як часто я взагалі переглядав цей архів? І виявляється, що за тридцять років — лише один раз, коли пакував бекапи.

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

Як це влаштовано в мене

«Уже скільки разів твердили світові…» Хмару я використовую лише для копій. Усе є локально. Не знаю, наскільки моя школа «стара», але я ще й параноїк. А в питаннях бекапу це, схоже, не діагноз, а професійна якість.

Коротко

• 3-2-1 — це відправна точка, а не стеля.
• RAID, синхронізація та дзеркалування — не бекап. Це зовсім інші речі з інших категорій.
• Хмара, де лежить єдина копія, — не бекап, а чужий диск.
• Одна копія має бути відключена від мережі або захищена від змін, інакше вірус-шифрувальник зашифрує все разом, а ви тільки вигадаєте нове слово для «ой».
• Перевіряйте відновлення. Регулярно, а не «колись».
• Час від часу переглядайте, що саме ви бережете і навіщо.
• Оберіть свій баланс між ризиком і трудовитратами й живіть із ним свідомо.