Чим відрізняється бекап від резервної копії: не лише слова

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

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

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

Формально синоніми, на практиці — різні ролі

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

Англійська тут точніша за повсякденну українську. Дієслово to back up — дія. Іменник backup — і система, і результат. Окремо існує backup copy — конкретний артефакт. В українській цю трійку стискають у два слова, і через це виникає плутанина.

• Резервне копіювання — процес: хто, що, коли, куди й за якими правилами копіює.
• Резервна копія — результат: файл, образ диска, стрічка, об’єкт у хмарному сховищі з конкретною датою.
• Бекап — розмовний і технічний ярлик для всіх трьох смислів одразу. У журналі завдання пише: «бекап завершено о 02:14». У репозиторії з’являється файл на кшталт backup-2026-08-24.vbk — це вже резервна копія.

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

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

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

Коли звичайна копія ще не є бекапом

Скопіювати папку «Документи» на робочий стіл у каталог «Копія» — це дубль, не захист. Той самий диск, той самий контролер, той самий вірус, та сама помилка в одній команді rm чи «Очистити кошик». Щоб копія стала бекапом, їй потрібні чотири властивості. Якщо бракує хоча б однієї, у критичний момент система підводить.

Ізоляція від оригіналу

Копія має переживати те, що вбиває оригінал. Інший фізичний носій — мінімум. Інша локація — уже серйозний рівень: пожежа, крадіжка, затоплення, вихід з ладу цілого кабінету чи серверної не повинні забрати все. Мережева ізоляція теж важлива. Флешка, яка місяцями стирчить в USB, для програми-вимагача майже не відрізняється від диска C:.

Кілька точок у часі

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

Відновлюваність, а не «файл на місці»

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

Незалежність від тих самих ключів доступу

Якщо бекап лежить у тій самій хмарній консолі, під тим самим обліковим записом адміністратора, що й бойова система, витік пароля або токена знищує оригінал і копію одним рухом. Сучасний бекап або незмінний протягом визначеного терміну (WORM, object lock), або фізично від’єднаний, або доступний з окремого, вузько обмеженого облікового запису.

У реальних кейсах часто виявляється третя комбінація: копія є, носій інший, але відновлення ніхто не пробував два роки, а пароль шифрування записаний у файлі passwords.xlsx на тому ж комп’ютері. Це не бекап. Це ритуал.

Джерело: узагальнення термінології (процес / артефакт) і практики експлуатації систем резервного копіювання.

Бекап, снапшот, реплікація і архів: чотири різні інструменти

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

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

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

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

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

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

Окремо стоїть синхронізація — OneDrive, Google Drive, Dropbox, iCloud у режимі «ті самі файли на всіх пристроях». Видалили документ на ноутбуці — через хвилину його немає на телефоні. Версійність у хмарних дисках буває, і вона рятує в дрібних випадках, але ліміти за терміном, глибиною й типом файлів не замінюють політику бекапу. Синхронізація зручна для роботи. Бекап потрібен, коли зручність уже зламалася.

Джерело: галузеві визначення резервного копіювання, знімків стану, реплікації та архівування (практики BaaS/DR, настанови CISA).

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

Як збирається ланцюг відновлення

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

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

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

Інкрементальний копіює лише те, що змінилось після будь-якої попередньої точки — повної чи інкрементальної. Щоденні порції маленькі й швидкі. Ціна — довгий ланцюг. Щоб підняти п’ятницю, потрібні недільний повний і всі інкременти з понеділка по п’ятницю. Випав один файл у середині — і точка відновлення крива. Саме тому дорослі системи вміють збирати «синтетичний повний»: склеюють ланцюг у новий повний образ без повторного знімання з бойового сервера.

Окремий режим — майже безперервний захист (near-CDP): точки кожні 5–15 хвилин за рахунок журналу змін або знімків. Це вже не «нічний бекап», а спроба зменшити втрату даних до кількох хвилин. Він не скасовує офсайт і перевірку відновлення, лише стискає вікно, яке ви готові втратити.

Два числа, без яких розмова про «хороший бекап» порожня:

• RPO (Recovery Point Objective) — скільки даних можна втратити, виміряно часом. RPO 24 години означає: вчорашній вечірній бекап ще прийнятний, робота за сьогодні — ні.
• RTO (Recovery Time Objective) — за який час сервіс має знову жити. Для сімейних фото RTO може бути «на вихідних». Для каси магазину — «до відкриття».

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

Джерело: стандартна класифікація full / differential / incremental у системах резервного копіювання.

Правило 3-2-1 і чому однієї «копії в хмарі» вже замало

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

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

Дослідження ESG 2025 зафіксувало неприємну норму: серед організацій, які переживали атаку ransomware за попередні два роки, 96% повідомили, що копії теж були ціллю. Незмінне сховище вважають критичним елементом захисту, але розгортають його далеко не всі; класичного 3-2-1 дотримується лише частина опитаних. Майже половина постраждалих відновлювалась до п’яти робочих днів — і не завжди повністю.

Звідси сучасне розширення, яке закріпила екосистема Veeam як 3-2-1-1-0:

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

Це не маркетинг «додаткової цифри». CISA у настановах StopRansomware прямо вимагає тримати офлайн- або ізольовані зашифровані копії критичних даних і регулярно перевіряти, що з них можна відновитися. У NIST Cybersecurity Framework 2.0 є окремий результат PR.DS-11: резервні копії треба створювати, захищати, підтримувати й тестувати. Четверте дієслово — те, яке пропускають найчастіше.

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

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

Сім помилок, через які копія не рятує дані

Більшість історій «бекап не спрацював» починаються не з рідкісного збою ПЗ. Вони починаються з підміни понять.

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

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

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

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

Відновлення ніколи не пробували. У логах «success». На ділі не вистачає місця розгорнути образ, ланцюг інкрементів битий, агент не читає старий формат, ліцензія скінчилась, а ключ шифрування знає людина, яка звільнилась. Бекап, який не відновлювали, — гіпотеза.

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

Знімають уже заражену систему і заспокоюються. Якщо шифрувальник сидів тиждень, остання «успішна» копія може бути вже зіпсована. Без глибини зберігання (два–чотири тижні мінімум для бізнесу, інколи більше) вибір точок «до атаки» зникає. Саме тому одна перезаписувана копія — антипатерн.

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

Як це виглядає в трьох типових ситуаціях

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

Сімейні фото й документи

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

Що не працює: «перекинув на флешку і ношу в рюкзаку разом із ноутбуком», «є копія в Telegram “Вибране”», «надіслав собі на пошту». Це канали передачі, не сховище з політикою.

Ноутбук фрилансера чи ФОП

На кону договори, акти, переписка з замовниками, макети, репозиторій, база обліку. RPO тут часто «один робочий день», бо втратити п’ятницю боляче, але не смертельно; втратити місяць — уже касація перед податковою й клієнтами.

Робоча схема: щоденний файловий або образний бекап на зовнішній диск / NAS; окрема копія в хмарне сховище з версіями й, за можливості, з забороною видалення на 30 днів; список того, що взагалі треба знімати (не забути браузерні профілі, ключі підпису, файл ліцензій, експорт з «Дії» та банк-клієнт — те, що згадують останнім). Раз на квартал — повне відновлення на запасний диск або в віртуалку. Якщо піднімається лише частина проєктів, бекап брехав, навіть якщо індикатор був зеленим.

Сайт, магазин, невелика фірма

Тут резервна копія файлів сайту — лише фрагмент. Потрібні база, медіа, сертифікати, DNS-зони, пошта, CRM, офісні диски. Репліка на другий сервер закриває падіння «заліза». Бекап закриває реліз, який зламав каталог, бухгалтера, який видалив номенклатуру, і шифрувальника, який прийшов через RDP.

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

Якщо RTO «до відкриття магазину», це вже не питання «чи є архів у панелі». Це питання, чи відновлення проганяли по годиннику, а не «теоретично встигнемо».

Якщо відновлення не спрацювало

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

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

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

Коли варто звернутися до фахівця, а не «ще раз натиснути Відновити»

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

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

Короткий чек-лист: у вас бекап чи лише копія

1. Є щонайменше дві копії плюс оригінал.
2. Вони на різних типах носіїв.
3. Одна копія не ночує в тій самій кімнаті, що й комп’ютер.
4. Є кілька дат, не лише «останній файл».
5. Бойовий обліковий запис не може стерти всі копії за один логін.
6. Ключ шифрування існує окремо від самих даних.
7. За останні 90 днів ви реально щось відновлювали, не лише дивились лог «success».
8. Ви знаєте RPO і RTO хоча б навскидку: «доба / вихідні» для дому, конкретні години для бізнесу.

Якщо чесно відмічено менше п’яти пунктів, у вас є резервна копія в побутовому сенсі. Бекапу як системи ще немає.

Ключові інсайти

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

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

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