Резервний майданчик: три схеми і що перевіряти щокварталу

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

Навіщо другий майданчик#

Резервна копія відповідає на запитання «чи збережуться дані». Резервний майданчик — на запитання «де і коли ми знову працюватимемо». RAID, резервоване живлення і канали дата-центру захищають від відмови диска чи лінії, але не від втрати всього майданчика. Ми знаємо це з власного досвіду: дата-центр United DC в Україні знищено ударом 23 вересня 2026 року (наша історія). Тому копії й резервний сервер варто тримати в іншій країні.

Жодна схема не дає абсолютних гарантій. Вона зменшує втрати даних і простій до рівня, який ви обрали й перевірили на практиці.

Три схеми#

Спершу керівник відповідає на два запитання: за який проміжок часу компанія готова вводити дані заново і скільки вона може простояти без облікової системи.

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

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

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

• Другий сервер в іншій країні. Якщо основні сервери в Україні або в офісі, беріть сервер у Польщі: час відгуку від Києва — близько 15 мс. Якщо основний сервер уже в Польщі, беріть резервний у Німеччині або Франції: це окремий дата-центр з окремим живленням і каналами; від Києва — близько 35 і 40 мс відповідно. Цифри — за нашими вимірюваннями з мереж українських провайдерів, жовтень 2026 року; вони залежать від провайдера й маршруту, а з мобільного інтернету більші.
• Приватна мережа між країнами на основних лінійках: реплікація йде нею, тож порт бази не потрібно відкривати в інтернет. Підключення — за зверненням до підтримки, налаштування — у статті про приватну мережу і VLAN.
• VPN між офісом і обома серверами, налаштований заздалегідь: WireGuard між офісом і сервером.

Ліцензії на програмне забезпечення для резервного сервера тут не розглядаємо.

Кроки#

1. Імена і DNS із малим TTL#

Користувачі мають підключатися за іменем, наприклад app.example.com, а не за IP-адресою: тоді перемикання — це зміна одного запису A. Заздалегідь задайте для нього TTL 300 секунд. Зменшувати TTL під час аварії запізно: старе значення вже в кешах. DNS-хостинг не має залежати від жодного з двох серверів. Перевірте запис:

dig +noall +answer app.example.com

Друге поле відповіді — залишок TTL у секундах; він не має перевищувати заданого значення. У Windows те саме покаже Resolve-DnsName app.example.com.

2. Реплікація бази даних#

Приклад — потокова реплікація PostgreSQL 18 на Debian або Ubuntu (пакети PGDG, кластер 18/main); в інших системах шляхи й назви служб інші. Адреси 10.10.0.1 (основний сервер) і 10.10.0.2 (резервний) — приклад адрес у приватній мережі. На резервному сервері заздалегідь встановіть ту саму основну версію (пакет postgresql-18). На основному сервері створіть роль для реплікації:

sudo -u postgres createuser --replication --pwprompt replicator

У файлі /etc/postgresql/18/main/postgresql.conf задайте приватну адресу й обмежте обсяг журналів WAL, які утримує слот реплікації: без обмеження диск основного сервера заповниться, якщо резервний довго недоступний. 20 ГБ — приклад; якщо межу перевищено, репліку доведеться створити заново.

listen_addresses = 'localhost,10.10.0.1'
max_slot_wal_keep_size = 20GB

У файл /etc/postgresql/18/main/pg_hba.conf додайте рядок:

host  replication  replicator  10.10.0.2/32  scram-sha-256

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

sudo systemctl restart postgresql@18-main

pg_basebackup копіює лише каталог даних, а файли в /etc/postgresql/18/main на резервному сервері залишаються власні. До запуску репліки перенесіть у них налаштування основного сервера: max_connections не може бути меншим, ніж на основному, інакше репліка не запрацює.

Увага. Команди нижче виконуйте лише на резервному сервері: вони прибирають його поточний каталог даних (перейменовують, а не видаляють). Щоб відкотити зміни, зупиніть службу, видаліть новий каталог main, поверніть на його місце main.old і запустіть службу.

sudo systemctl stop postgresql@18-main
sudo mv /var/lib/postgresql/18/main /var/lib/postgresql/18/main.old
sudo -u postgres pg_basebackup -h 10.10.0.1 -U replicator -D /var/lib/postgresql/18/main -R -X stream -C -S standby1 -P
sudo systemctl start postgresql@18-main

Ключ -R створює файл standby.signal і записує параметри підключення разом із паролем у postgresql.auto.conf; ключі -C -S standby1 створюють слот реплікації. Реплікація асинхронна: резервний сервер трохи відстає, тож останні транзакції можна втратити. Синхронний режим (synchronous_standby_names) усуває цю втрату, але кожен запис чекає на підтвердження з другої країни, а без резервного сервера записи на основному зависають. Докладніше — в документації PostgreSQL.

MS SQL Server має два вбудовані механізми. Доставка журналів (log shipping): завдання SQL Server Agent роблять копію журналу транзакцій, копіюють її на резервний сервер і відновлюють там; автоматичного перемикання немає, тож це «тепла» схема. Групи доступності Always On (availability groups): журнал передається постійно, синхронно чи асинхронно; у Windows потрібен відмовостійкий кластер (WSFC), а в редакції Standard доступні лише базові групи — одна база і дві репліки. Файлову базу BAS не можна надійно синхронізувати, поки в ній працюють користувачі: переносьте її копіями за розкладом, як у статті про резервні копії баз даних.

3. Синхронізація файлів#

Увага. Ключ --delete видаляє на резервному сервері все, чого немає на основному. Перевірте шляхи та скісні риски наприкінці, а спершу запустіть команду з --dry-run: разом із -v вона лише покаже зміни.

rsync -av --delete --dry-run /srv/files/ admin@10.10.0.2:/srv/files/

Якщо список змін правильний, приберіть --dry-run і запускайте команду за розкладом. У Windows те саме робить robocopy з ключем /MIR — з тим самим застереженням.

4. План дій і список доступів#

• Хто ухвалює рішення про перемикання і хто заміняє цю людину.
• Кроки за порядком: ізолювати старий основний сервер, перевести базу на резервному в робочий режим, змінити DNS, перевірити вхід, повідомити користувачів.
• Список доступів: сервери, панель DNS і реєстратор домену, VPN, бази даних, сховище копій і ключі шифрування, контакти підтримки.
• План є в менеджері паролів і на папері, а не лише на сервері, який може зникнути.

5. Навчальне перемикання#

Увага. Після pg_promote() резервний сервер стає самостійним, і повернути його в роль репліки однією командою не можна. Старий основний сервер після цього не має приймати записи, інакше дві бази розійдуться. Щоб повернутися, заново зробіть старий основний сервер реплікою (pg_basebackup або pg_rewind) і перемкніться ще раз.

1. Оберіть неробочий час, попередьте користувачів, зробіть свіжу резервну копію.
2. Зупиніть застосунки на основному сервері, переконайтеся, що репліка не відстає, і зупиніть на ньому PostgreSQL: sudo systemctl stop postgresql@18-main.
3. На резервному сервері переведіть базу в робочий режим командою під цим списком.
4. Змініть запис A на адресу резервного сервера й дочекайтеся, поки мине TTL.
5. Попросіть користувачів увійти й виконати звичні операції. Запишіть час від початку до моменту «працюємо».
6. Поверніться на основний сервер і занотуйте, що пішло не так.

sudo -u postgres psql -c "SELECT pg_promote();"

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

На основному сервері перевірте стан реплікації та слота:

sudo -u postgres psql -x -c "SELECT client_addr, state, sent_lsn, replay_lsn, replay_lag FROM pg_stat_replication;"
sudo -u postgres psql -c "SELECT slot_name, active, wal_status FROM pg_replication_slots;"

Має бути: state — streaming, active — t, wal_status — reserved або extended. На резервному сервері:

sudo -u postgres psql -c "SELECT pg_is_in_recovery(), now() - pg_last_xact_replay_timestamp() AS delay;"

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

Що перевіряти раз на квартал#

• Відновлення з копії: розгорніть останню копію на резервному сервері або в тестовій базі й попросіть бухгалтера знайти останні документи.
• Навчальне перемикання за планом із записом фактичного часу; порівняйте з минулим кварталом.
• Реплікація: стан, відставання, активний слот, вільне місце на дисках обох серверів.
• DNS: TTL не змінився, доступ до панелі DNS і реєстратора мають щонайменше двоє людей, домен оплачено.
• Мережа: VPN з офісу і з дому до резервного сервера працює, правила мережевого екрана на обох серверах однакові.
• Версії: ОС, СУБД і платформа облікової системи на обох серверах оновлені до однакових версій; сертифікати TLS не прострочені.
• Доступи і план: ключі й паролі зі списку працюють; доступи людей, які пішли з компанії, закрито; телефони, відповідальні й кроки в плані актуальні; рахунки за обидва сервери сплачено.

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

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

Що далі#

• Оберіть країну для резервного сервера: локації і стаття про вибір країни.
• Підберіть сервер у каталозі. Чи є в моделі приватна мережа, видно в картці сервера. Типові сценарії — на сторінці «Для бізнесу».
• Налаштуйте копії: restic для Linux, вбудовані засоби Windows Server.
• Питання щодо схеми ставте технічній підтримці 24/7: +38 044 206 08 08, info@united.net.ua.