Для власників сайтів · 26.09.2026

Хостинг під загрозою: як перенести сайт і перевірити бекапи

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

Якщо хостинг уже недоступний

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

Куди переносити: обирайте інші залежності

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

Складіть паспорт проєкту

Запишіть домени та DNS-провайдера; версії PHP, Node або іншого середовища; тип і версію бази; дисковий обсяг; завдання cron; зовнішні API; поштові скриньки й пересилання; завантаження користувачів. Для інтернет-магазину додайте платежі, замовлення, залишки та інтеграції. Секрети зберігайте в менеджері паролів або зашифрованому сховищі окремо від відкритої документації. Перевірте запасний спосіб входу і коди відновлення 2FA.

Що саме має бути в копії

Для CMS потрібні файли сайту, завантаження користувачів і узгоджений дамп бази. Копія каталогу з файлами працюючої СУБД не замінює коректний дамп або штатний бекап цієї СУБД. Додайте конфігурацію, список версій, DNS-зону, пошту, якщо вона на тому самому хостингу. Для статичного сайту потрібні готові HTML, CSS, JavaScript і медіа; бази може не бути. Завантажте копію за межі сервера: архів поруч із сайтом буде втрачений разом із ним.

Як зняти бекап у cPanel

Відкрийте Files → Backup або Backup Wizard, створіть повну копію акаунта та завантажте її після завершення. Додатково корисні окремі копії домашнього каталогу і баз. Перевірте, що вистачило дискового місця, а архів розпаковується. Повний архів cPanel автоматично відновлюється через WHM або за допомогою хостера; звичайний користувацький cPanel не дає такого автоматичного відновлення. Для переїзду на іншу панель знадобиться ручне перенесення файлів, баз і пошти.

Графік бекапів: приклад для невеликого сайту

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

Захистіть копії та контролюйте виконання

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

Відновіть до перемикання

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

Перемикайте без втрати нових записів

Заздалегідь збережіть DNS-зону. За можливості зменште TTL потрібних записів і дочекайтеся закінчення попереднього TTL. Перед фінальною копією призупиніть зміни на старому сайті або переведіть його в режим читання; потім перенесіть останній дамп і нові файли. Не допускайте незалежного приймання замовлень обома копіями. Змініть потрібні A, AAAA або CNAME; перевірте також www та старий IPv6-запис. Якщо можна, залиште DNS у поточного постачальника: зміна всіх NS одночасно додає зайвих змін.

Пошта та HTTPS — окремі перевірки

Переїзд вебсайту не переносить автоматично поштові скриньки та листи. За окремої міграції пошти потрібні перенесення листів і звірка MX, SPF, DKIM, DMARC. Якщо змінюєте DNS-провайдера, перенесіть усю зону й узгодьте DNSSEC/DS, щоб не зламати перевірку підписів. Випустіть або перевірте сертифікат HTTPS на новому сервері. Протестуйте надсилання і приймання листів зовнішньою скринькою та доступність сайту з іншої мережі.

Коли вимикати старий сервер

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

Щомісяця — маленька репетиція відновлення

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

Джерела й корисні посилання

Оновлено 26.09.2026. Перед замовленням перевірте умови та кінцеву суму у постачальника.

Перевірити швидкість і якість зв’язку →