Правило 3-2-1: як організувати резервні копії невеликій компанії

Оновлено 4 жовтня 2026 10 хв читання Read in English

Зміст статті

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

Що означає 3-2-1#

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

Приклад. Компанія на 15 працівників орендує виділений сервер у Польщі: на ньому облікова база BAS і тека з договорами. Робочі дані на дисках сервера — перший примірник. Щоночі сервер надсилає копію на окреме сховище, у місце для резервних копій, — це другий. Комп’ютер в офісі щоранку забирає свіжу копію із сервера — це третій, і він поза дата-центром. Тепер жодна окрема подія — відмова сервера, помилка працівника, шифрувальник чи втрата доступу до майданчика — не знищить усіх примірників одразу.

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

Що знадобиться#

Перелік даних, без яких компанія не працює, і людина, яка відповідає за копії.
Два місця для копій, крім самого сервера (про них — у кроці 3).
Програма для копіювання: у Linux — наприклад, restic; у Windows Server — стандартний компонент Windows Server Backup (його треба встановити); для баз даних — засоби самої СУБД.
Година щомісяця на пробне відновлення.

Крок 1 Визначте, що копіювати#

Облікові бази. Робіть вивантаження засобами СУБД або самої облікової системи, а не копіюйте файли бази, з якою зараз працюють: така копія може виявитися непридатною. Докладно — у статті про резервні копії баз даних.
Файли. Спільні теки, договори, скановані документи, архіви звітності.
Пошта. Якщо поштовий сервер ваш — скриньки й налаштування доменів. Якщо пошта в зовнішнього сервісу — з’ясуйте, чи можете ви самі вивантажити скриньки.
Налаштування. Конфігурації служб, завдання планувальника, сертифікати, правила мережевого екрана, налаштування VPN, перелік установлених програм. Без них відновлення на чистому сервері триватиме не години, а дні.
Ключі та паролі до самих копій. Пароль шифрування, облікові дані сховищ, коротка інструкція з відновлення. Тримайте їх поза сервером у двох місцях: у менеджері паролів і на папері в сейфі. Якщо пароль до копії був лише на сервері, якого вже немає, — копії у вас теж немає.

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

Крок 2 Як часто копіювати і скільки зберігати#

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

Допустима втрата даних: За який проміжок часу ви готові ввести дані наново. Якщо копію роблять раз на добу вночі, а збій стався о 17:00, втрачено робочий день. Якщо це забагато, облікову базу копіюють частіше — наприклад, щогодини в робочий час.
Час відновлення: Скільки компанія може простояти. Цей час складається з отримання нового сервера чи диска, встановлення системи, завантаження копії та перевірки даних.

Скільки зберігати. Помилку в базі часто помічають не наступного дня, а під час закриття місяця, тож самої вчорашньої копії замало. Поширена схема (це приклад, а не норма): 7 щоденних копій, 4 щотижневі та 6–12 щомісячних.

У restic (команди в статті перевірено для версії 0.19.1) таку схему задає одна команда. З параметром --dry-run вона нічого не видаляє, лише показує, які копії залишаться, а які буде прибрано:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run

Увага. Без --dry-run команда прибирає зайві копії зі сховища, а з параметром --prune ще й безповоротно стирає їхні дані. Спершу перегляньте список у пробному режимі.

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

Крок 3 Куди складати копії#

Локальне вивантаження на сервері#

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

Місце для резервних копій на окремому сховищі#

Воно входить до серверів United Cloud: у лінійках Стандарт, Бізнес, Потужність і Ультра — 500 ГБ, у Класик — 100 ГБ, для Турбо — дивіться картку сервера в каталозі. У лінійці Лайт його немає. За окрему плату підтримка розширить місце до 10 ТБ; докладно — на сторінці про місце для резервних копій. Що варто знати:

сховище саме копій не робить — програму й розклад налаштовуєте ви;
воно не залежить від сервера: відмова дисків сервера чи самого сервера копій не зачепить;
підключення — за NFS (лише версія 3), SMB (лише версія 2.0), FTP або FTPS;
доступ відкрито лише з IP-адрес ваших серверів — підтримка додає їх до списку доступу на ваш запит; з інтернету й з офісу сховище недоступне;
з однієї IP-адреси — не більше трьох з’єднань водночас;
коли місце закінчується, сховище переходить у режим «лише читання», доки ви не звільните місце;
режиму «лише додавання» немає: що сервер може записати, те може й видалити, тож третьої копії сховище не замінює (див. крок 4).

Третє місце — поза сервером і сховищем#

Офіс. Комп’ютер або мережевий накопичувач (NAS), який сам забирає копії із сервера. Зважайте на відключення світла: пропущене завдання має запуститися, щойно відновиться живлення.
Сервер в іншій країні. Якщо основний сервер у Польщі, другий може стояти в Німеччині чи Франції — країни описано на сторінці «Локації». Згодом такий сервер може стати резервним майданчиком.
Зовнішнє сховище. Сховище іншого постачальника, не пов’язане з вашим сервером ні обліковим записом, ні майданчиком.

Крок 4 Захистіть самі копії#

Шифрування. Копія — це вся ваша база в одному місці, тому шифруйте її ще до того, як вона залишить сервер. Програма restic завжди шифрує своє сховище. Якщо ваша програма цього не вміє, шифруйте архів перед надсиланням або том, на який він потрапляє.
Окремі облікові дані. Для кожного місця — свій користувач і пароль, яких більше ніде не використовують. Не обліковий запис адміністратора сервера і не особиста пошта директора.
Захист від видалення із самого сервера. Шифрувальник, отримавши права адміністратора, зазвичай спершу шукає і знищує копії, до яких сервер має доступ. Тому принаймні одну копію має бути неможливо видалити із сервера. Способи: третє місце саме забирає копії, і на сервері немає його паролів; зовнішнє сховище приймає дані в режимі «лише додавання» (append-only) або зберігає версії, яких не можна стерти до визначеної дати; носій після копіювання від’єднують. У місця для резервних копій такого режиму немає: процес на сервері, який може туди записувати, може й видаляти. Тож дайте процесу копіювання окремі облікові дані й мінімальні права, а захищений від видалення примірник тримайте поза сервером і сховищем — в офісі чи в іншій країні.

Таблиця «що — куди — як часто»#

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

Що	Куди	Як часто	Скільки зберігати
Облікова база (вивантаження)	Каталог на сервері → окреме сховище → офіс	Щоночі; за потреби щогодини в робочий час	7 щоденних, 4 щотижневі, 12 щомісячних
Файли	Окреме сховище → офіс або сервер в іншій країні	Щоночі	7 щоденних, 4 щотижневі, 6 щомісячних
Пошта	Окреме сховище → третє місце	Щоночі	7 щоденних, 4 щотижневі
Налаштування сервера	Окреме сховище → третє місце	Щотижня і після кожної зміни	4 щотижневі, 6 щомісячних
Ключі та паролі до копій	Менеджер паролів і папір у сейфі	Після кожної зміни	Доки існують копії, які ними відкриваються

Як перевірити результат#

Щодня: чи копію взагалі створено#

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

Для restic (сховище і файл пароля задано змінними RESTIC_REPOSITORY і RESTIC_PASSWORD_FILE): перша команда показує останню копію кожного сервера і набору каталогів, друга вибірково перевіряє цілісність — читає випадкові 5 % даних.

restic snapshots --latest 1
restic check --read-data-subset=5%

Команда check на час роботи блокує сховище — не запускайте її під час копіювання.

Windows Server Backup: у PowerShell від імені адміністратора перегляньте перелік копій і час останньої успішної:

wbadmin get versions
Get-WBSummary

За розкладом: пробне відновлення#

Це головний пункт усієї схеми. Копія, з якої жодного разу не відновлювали дані, — це припущення, а не копія.

Увага. Відновлюйте лише в окремий каталог, у тестову базу або на інший сервер — ніколи поверх робочих даних: наявні файли restic перезаписує без запитань. Перед початком перевірте вільне місце на диску (df -h). Після перевірки тестові дані видаліть.

restic restore latest --target /srv/restore-test --verify

Параметр --verify перевіряє вміст відновлених файлів. Якщо в сховищі є копії кількох серверів чи наборів каталогів, потрібну для latest вибирають параметрами --host і --path.

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

Типові помилки#

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

Що далі#

Linux: резервні копії за допомогою restic.
Windows: резервні копії Windows Server вбудованими засобами.
Бази даних: PostgreSQL, MS SQL Server і облікові бази BAS.
Коли самих копій замало: резервний майданчик — три схеми.
Довідка: документація restic, команда wbadmin.

Параметри підключення до місця для резервних копій надішле підтримка: телефон +38 044 206 08 08, пошта info@united.net.ua.