Чек-лист переїзду з українського дата-центру чи офісу в Європу

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

Зміст статті

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

Для кого і навіщо#

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

Наш власний дата-центр в Україні знищено ударом 23 вересня 2026 року (наша історія). Звідси порада з досвіду: не відкладайте. Плановий переїзд можна розкласти на два тижні й перевірити кожен крок; аварійний доводиться робити з того, що збереглося в копіях.

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

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

Графік переїзду#

Коли	Що зробити	Результат
За два тижні	Інвентаризація; вибір лінійки, конфігурації й країни; заявка на сервери	Таблиця систем, рахунок, дата «вікна»
За тиждень	Налаштування й захист серверів, VPN; зниження TTL; нові адреси — банкам і партнерам; попередня синхронізація; резервні копії; пробний вхід	Нові сервери з копією даних, перевірені користувачами
День переїзду	Зупинка служб на старому майданчику; фінальна дельта файлів і баз; перевірка; перемикання DNS; рішення «працюємо чи відкат»	Робота на нових серверах
Після	Спостереження тиждень-два; повернення звичайного TTL; пробне відновлення з нової копії; стирання даних зі старих дисків	Старий майданчик виведено з роботи

Кроки#

1. Інвентаризація систем і залежностей#

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

# Linux
sudo ss -tulpn
systemctl list-units --type=service --state=running
systemctl list-timers
sudo ls -R /etc/cron.d /var/spool/cron
# Windows Server (PowerShell)
Get-NetTCPConnection -State Listen
Get-ScheduledTask | Where-Object State -ne 'Disabled'
Get-SmbShare

Окремо випишіть те, про що згадують останнім: сертифікати TLS, ключі електронного підпису, USB-ключі в старому сервері, принтери й сканери, обмін із банком і касами.

2. Сервери, країна, замовлення#

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

Заявку подавайте щонайменше за тиждень до «вікна»: ми зв’язуємося протягом робочого дня й виставляємо рахунок у гривнях (оплата), а сервер із наявності видаємо до 12 або до 72 годин після оплати; дані для входу надсилаємо на контакти із заявки. У коментарі до заявки вкажіть ОС — її встановлять до видачі, а для Linux — і публічний ключ SSH: його одразу додадуть користувачеві з правами sudo. Докладніше — від заявки до доступу.

3. Мережевий план: адреси зміняться#

Нові сервери матимуть інші адреси: IPv4 і блок IPv6 /64 (Потужність і Ультра — /56, Лайт — одна адреса). Додаткові адреси IPv4 (до 256 на сервер, на Лайт — до 128) замовляють через підтримку. Заздалегідь знайдіть усе, що посилається на старі.

DNS. Знизьте TTL записів, які змінюватимете (A, AAAA, MX), до 300 секунд — тоді зміна розійдеться за хвилини. Зробіть це щонайменше за один старий TTL до перемикання: якщо було 86400 секунд — за добу.
Білі списки. Банки (клієнт-банк, API), платіжні сервіси й партнери, які приймають з’єднання лише з відомих адрес. Надішліть їм нові адреси й попросіть на час переїзду залишити обидві.
VPN і налаштування. Адреси вузлів у тунелях, правила на маршрутизаторі офісу, файли .rdp у користувачів, рядки підключення до баз, файл hosts.
Пошта. Якщо листи йдуть із вашого сервера, оновіть запис SPF (ip4:203.0.113.10 — приклад) і зворотний запис DNS: він має збігатися з іменем поштового сервера. Зворотний запис налаштовує підтримка за зверненням, коли прямий запис цього імені вже вказує на нову адресу.

Поточні записи й TTL (друге поле в рядку відповіді, у секундах):

dig +short NS example.com
dig +noall +answer @ns1.example.com example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com TXT
dig +short -x 203.0.113.10

Замість ns1.example.com підставте сервер імен із першої команди: він показує повний TTL, а не залишок у кеші.

4. VPN і приватна мережа#

RDP, SMB і порти баз даних не відкривайте в інтернет навіть «на час переїзду»: копіювання спільних папок і робота користувачів ідуть через VPN — див. WireGuard між офісом і сервером і безпечний RDP. Якщо серверів кілька, з’єднайте їх приватною мережею: це окремий інтерфейс без публічної адреси, сервери в неї об’єднує підтримка (попросіть у коментарі до заявки), а приватні адреси обираєте ви. На лінійках Лайт і Турбо приватної мережі немає.

5. Перенесення даних: попередня синхронізація і фінальна дельта#

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

Увага. Параметри --delete (rsync) і /MIR (robocopy) видаляють у місці призначення все, чого немає в джерелі: переплутаний напрямок або шлях знищить дані. Спершу запустіть ту саму команду, додавши -n -i (rsync) або /L (robocopy), — вона лише покаже, що буде зроблено. Видалене повернете лише з резервної копії.

Linux: rsync

Пакет rsync потрібен на обох серверах. Власників файлів rsync зберігає, лише коли на новому сервері працює від імені root. Для цього потрібні параметр --rsync-path і тимчасове правило на новому сервері: рядок admin ALL=(root) NOPASSWD: /usr/bin/rsync, доданий командою sudo visudo -f /etc/sudoers.d/migration, де admin — ваш користувач із правами sudo. Правило фактично дає йому права root, тож після переїзду видаліть цей файл. Ключ SSH має бути в користувача, від імені якого запущено команду, — тут це root.

# на старому сервері; попередня синхронізація: можна повторювати
sudo rsync -aHAX --numeric-ids --partial --info=progress2 \
  --rsync-path="sudo rsync" /srv/data/ admin@203.0.113.10:/srv/data/

# фінальна дельта після зупинки служб
sudo rsync -aHAX --numeric-ids --partial --info=progress2 --delete \
  --rsync-path="sudo rsync" /srv/data/ admin@203.0.113.10:/srv/data/

Скісна риска в кінці шляху джерела означає «вміст каталогу». Довге копіювання запускайте в tmux.

Windows: robocopy

robocopy D:\Shares \\10.10.0.2\Shares /E /SEC /DCOPY:DAT /Z /R:2 /W:5 /MT:16 /XJ /NP /LOG:C:\Logs\presync.log
robocopy D:\Shares \\10.10.0.2\Shares /MIR /SEC /DCOPY:DAT /Z /R:2 /W:5 /MT:16 /XJ /NP /LOG:C:\Logs\final.log

Обидві команди запускайте від імені адміністратора: першу — заздалегідь, другу — у «вікно». 10.10.0.2 — приклад адреси нового сервера у VPN, Shares — спільна папка на ньому; каталог C:\Logs має існувати. Код завершення, менший за 8, означає, що збоїв не було. Копіювати права доступу (/SEC) варто, якщо обидва сервери в одному домені.

Бази даних

Файли запущеної СУБД не копіюють «як є»: базу переносять вивантаженням або резервною копією. Версія СУБД на новому сервері має бути не нижчою, ніж на старому.

# PostgreSQL, старий сервер (від імені користувача postgres)
pg_dumpall --globals-only -f globals.sql
pg_dump -Fc -f appdb.dump appdb

# PostgreSQL, новий сервер, після копіювання обох файлів
psql -d postgres -f globals.sql
pg_restore -C -d postgres -j 4 appdb.dump

У globals.sql є хеші паролів ролей — не залишайте файл у загальнодоступному каталозі.

-- MS SQL Server, старий сервер
BACKUP DATABASE [AppDB] TO DISK = N'D:\Backup\AppDB_move.bak'
  WITH COPY_ONLY, CHECKSUM, STATS = 10;
RESTORE VERIFYONLY FROM DISK = N'D:\Backup\AppDB_move.bak' WITH CHECKSUM;

Відновлення MS SQL Server і перенесення баз BAS — у статтях про резервні копії баз даних і про перенесення облікової бази.

6. Скільки триватиме передавання даних#

Оцінка: години ≈ обсяг у ГБ × 2,22 ÷ швидкість у Мбіт/с. Швидкість беріть із пробного копіювання великого файлу: зазвичай її обмежує вихідний канал старого майданчика. Приклад: 500 ГБ на 70 Мбіт/с — близько 16 годин, 5 ГБ щоденних змін — близько 10 хвилин. Дрібні файли копіюються повільніше.

7. Перемикання і план відкату#

Попередьте користувачів, завершіть сеанси, зупиніть служби застосунків і баз на старому майданчику. Нічого там не видаляйте.
Перенесіть фінальну дельту файлів і вивантаження баз, відновіть бази на нових серверах.
Перевірте нові сервери за списком із розділу «Як перевірити результат» — ще до зміни DNS, через VPN.
Змініть записи DNS, адреси у VPN і в ярликах користувачів.
Впустіть тестову групу, потім усіх.

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

8. Резервні копії з першого дня#

Резервне копіювання має запрацювати до того, як прийдуть користувачі. До сервера входить місце для резервних копій на окремому сховищі: 500 ГБ на лінійках Стандарт, Бізнес, Потужність і Ультра, 100 ГБ на Класик, на Лайт його немає, для Турбо — див. картку. Копіювання налаштовуєте ви, а підтримка надсилає параметри підключення й відкриває доступ з адрес ваших серверів. Ще одну копію тримайте поза сервером і сховищем — за правилом 3-2-1. Старі копії не видаляйте, доки не відновите щось із нових.

9. Виведення старого майданчика з роботи#

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

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

lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL,MOUNTPOINT
# HDD: прохід випадковими даними, потім нулями
sudo shred -v -n 1 -z /dev/sdX
# NVMe: вбудоване стирання (пакет nvme-cli)
sudo nvme format /dev/nvmeXn1 --ses=1

У Windows несистемний диск очищає diskpart: list disk, select disk N, clean all. Системний диск стирайте, завантажившись із зовнішнього носія. На SSD перезапис охоплює не всі комірки — користуйтеся вбудованим стиранням диска. Диски за RAID-контролером стирайте його засобами, несправні знищуйте фізично.

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

DNS повертає нові адреси й новий зворотний запис.
Повторний запуск rsync з -n -i або robocopy з /L не показує розбіжностей.
В обліковій системі є останні документи, введені перед зупинкою, а контрольний звіт збігається зі старим.
Користувачі входять через VPN з офісу та з дому; час відгуку такий, як очікували (як його виміряти).
Працюють обмін із банком і друк; лист на зовнішню скриньку не потрапляє в спам.
Резервна копія створилася на новому місці, і з неї вдалося відновити файл і базу.

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

TTL знизили в день переїзду — частина користувачів ще добу потрапляє на стару адресу.
Забули про білі списки: клієнт-банк або API партнера не приймає з’єднання з нової адреси.
Фінальну дельту запустили, не зупинивши служби: частина змін залишилася на старому сервері.

Що далі#

Каталог виділених серверів, локації й час відгуку, сценарії для бізнесу.
Нові сервери: перша година на Linux і Windows Server.
Другий сервер в іншій країні як резервний майданчик.
Питання щодо переїзду — технічна підтримка 24/7, телефон +38 044 206 08 08.