Що насправді означає 3-2-1

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

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

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

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

Інвентар: що має повернутися після втрати пристрою

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

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

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

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

Два прості показники замість абстрактного «регулярно»

Поставте побутове запитання про допустиму втрату: скільки нових даних не страшно вводити повторно? Якщо відповідь — один день, щотижнева копія не виконує ціль. Це аналог recovery point objective, або RPO. Друге запитання — скільки часу можна чекати повернення доступу? Відновлення з повільного архіву за дві доби може бути прийнятним для старих фото, але не для документа, потрібного вранці.

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

Розділяйте копії за причинами відмови

Два зовнішні диски однієї моделі все одно є двома фізичними носіями, але якщо вони постійно лежать біля ноутбука, крадіжка забере всі три копії. NAS і комп’ютер у тій самій мережі можуть одночасно постраждати від помилки налаштування або шкідливого ПЗ. Два cloud-каталоги під одним логіном залежать від одного відновлення акаунта. Перелік зон відмови часто важливіший за кількість іконок.

Локальна копія дає швидке відновлення великого обсягу без інтернету. Offsite переживає локальну аварію. Offline або immutable-копія обмежує зміну з робочого середовища. Жодна роль не є «кращою» сама по собі. У схемі вони доповнюють одна одну: швидкість, географічна окремість і стійкість до небажаного перезапису.

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

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

Що копіюють Windows, macOS, Android та iPhone

Windows File History орієнтується на версії особистих файлів у бібліотеках і включених папках. Офіційна довідка Microsoft дозволяє відновити вибрану версію в інше місце — це зручний спосіб тесту без перезапису актуального документа. Але File History не слід описувати як повний образ усіх програм, облікових даних і системного стану. Перелік папок треба звірити вручну.

Windows Backup використовує OneDrive для вибраних користувацьких папок і пам’ятає частину налаштувань та ярликів програм. Microsoft прямо описує folder backup як синхронізацію з OneDrive. Отже, цей шар може бути offsite, але залишається пов’язаним із cloud-акаунтом і правилами sync. Для другої резервної копії додайте інший контроль доступу або локальний носій.

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

В Apple-екосистемі синхронізація й device backup розподіляють дані. Якщо ввімкнені iCloud Photos, iCloud Drive або Messages in iCloud, ці категорії синхронізуються й не дублюються в щоденному iCloud Backup. Комп’ютерна копія iPhone/iPad не тотожна sync і охоплює майже всі дані та налаштування, проте її шифрування треба свідомо ввімкнути. Це привід інвентаризувати категорії, а не припускати подвійний захист.

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

Частота, обсяг і зберігання версій

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

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

Автоматизація зменшує пропуски, але сповіщення про успіх має бути перевірюваним. Записуйте дату останньої копії, її scope, місце та результат restore-drill. Не покладайтеся тільки на зелений значок: він може означати завершення завдання без конкретної папки, яку перемістили або перейменували.

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

Проведіть тестове відновлення без ризику для оригіналів

1. Створіть контрольний набір. Виберіть кілька фото різних років, PDF, офісний документ, невелику базу або експорт програми. Додайте текстовий файл із датою тесту, але без секретів.
2. Використайте інший каталог. Restore має йти в нову порожню папку або тестовий профіль. Не погоджуйтеся на перезапис робочої версії, доки результат не порівняно.
3. Перевірте структуру й зміст. Зіставте кількість, назви, розміри та дати; відкрийте кожен тип файлу. Для важливого архіву можна порівняти checksums, але хеш не перевіряє працездатність програми.
4. Випробуйте залежності. Імпортуйте копію бази в тестове середовище, переконайтеся, що є потрібний інсталятор, і перевірте законний доступ до cloud-акаунта без основного телефона.
5. Запишіть дефект і повторіть. Якщо формат не відкрився або категорії немає, не позначайте test як пройдений. Виправте scope, вільне місце чи процедуру, створіть нову копію й повторіть саме проблемний сценарій.

Перед очищенням пам’яті без поспішного видалення відновіть кілька майбутніх кандидатів на видалення з резерву. Побачити thumbnails у cloud-галереї недостатньо: завантажте оригінал, відкрийте його та перевірте дату й роздільність.

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

Планувальник копій за пристроями й обсягом

Введіть сумарний обсяг обраного scope, а не місткість усіх дисків. Результат показує першу прогалину за пріоритетом і мінімальний payload для двох повних резервів; він не враховує версії, compression, deduplication, службові файли та майбутній приріст.

Статичне правило модуля прозоре: неповне поле блокує висновок; потім перевіряються 3 копії, 2 середовища, offsite, offline/immutable бар’єр, restore і ключ. Два резерви по 480 ГБ містять щонайменше 960 ГБ корисних даних, але реальні носії потребують місця для історії та росту. Не використовуйте цю нижню межу як рекомендацію конкретного диска.

Шифрування, доступ і межі домашнього плану

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

Не під’єднуйте єдиний offline-резерв до пристрою з ознаками ransomware. Спершу ізолюйте підозрілу систему, зафіксуйте обставини й використайте чисте середовище або допомогу спеціаліста. Відновлення поверх зараженої ОС може знову пошкодити повернуті файли. Для робочих даних дійте за політикою організації та не стирайте журнали самостійно.

Правило 3-2-1 не гарантує, що копія актуальна, повна чи законно доступна. Воно не замінює retention policy, перевірку цілісності баз, сумісність програм, захист акаунтів і документований порядок recovery. Воно також не визначає конкретну марку диска або cloud-тариф. Вибір залежить від обсягу, темпу змін, чутливості та часу, за який дані мають повернутися.

Після заміни комп’ютера, телефона, програми, структури папок або способу шифрування повторіть inventory і restore. Старий backup може залишатися читабельним, але не містити нової папки; новий застосунок може не імпортувати попередній формат. План завершується не створенням копії, а доказом відновлення потрібного результату.

Короткі практичні відповіді

Чи достатньо одного зовнішнього диска й хмари?

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

Чи можна рахувати фотографії одночасно в телефоні та iCloud?

Це дві доступні реалізації даних, але iCloud Photos працює як синхронізована категорія. Для стійкішого плану додайте незалежний export або backup, який не повторює звичайне видалення тим самим акаунтом.

Як часто тестувати?

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

Висновок

Складіть inventory незамінних даних, визначте допустиму втрату, розподіліть робочу й дві резервні копії між різними зонами, винесіть одну offsite та захистіть окремий резерв від звичайного запису. Потім відновіть репрезентативний набір у нове місце й запишіть результат. Лише така перевірка перетворює формулу 3-2-1 на план recovery.