Як влаштовані резервні копії, коли за них відповідаємо ми

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

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

Копія, якої ніхто не перевіряв, — це не копія

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

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

Тому головне питання не «чи робляться копії», а «чи хтось перевіряв, що вони відновлюються». І перевіряв не рік тому, а за розкладом.

Принцип, а не продукт: 3-2-1

Ми будуємо копії за класичним правилом, яке в індустрії називають 3-2-1:

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

Покоління копій: не одна точка, а історія

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

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

Шифрування, яке не тримається на секреті

Копія — це весь ваш бізнес в одному файлі, і сторонньому він не має сказати нічого. Тому кожна копія шифрується ще до того, як покине систему, — сучасним відкритим стандартом (ми користуємося age).

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

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

Дві незалежні хмари, обидві поза офісом

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

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

Щоночі — і з перевіркою

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

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

Різниця між «ми думаємо, що захищені» і «ми знаємо, що захищені» — це і є регулярний тест відновлення.

Антипатерн, який коштує найдорожче

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

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

Три питання до свого IT

Не обов’язково працювати з нами, щоб навести лад із копіями. Досить поставити тому, хто відповідає за ваше IT, три питання:

1. За яким принципом зроблені наші копії — чи зашифровані вони й чи є хоч одна поза офісом?
2. Коли востаннє хтось відновлював дані з копії, щоб переконатися, що вона робоча?
3. Де я можу побачити дату останньої вдалої перевірки — своїми очима, а не з ваших слів?

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