Коротка відповідь
У DirectAdmin резервна копія акаунта робиться в розділі System Info & Files → Create/Restore Backups: відмічаєте, що саме копіювати, натискаєте Create Backup, і за кілька хвилин у папці backups з'являється архів. Його варто одразу завантажити на свій комп'ютер і видалити з сервера. Відновлення — на тій самій сторінці, у блоці Restore Backup.
Навіщо ручний бекап, якщо хостинг і так копіює щодня
На Meridaro файли й бази кожного акаунта щоночі вивантажуються на окремий сервер — як це влаштовано, описано в статті про щоденні бекапи поза сервером. Нічна копія захищає від збою обладнання та злому. Але вона знята вночі, а ви збираєтесь оновлювати тему о 15:00 — і все, що змінилося за день, у неї не потрапило.
Власний архів закриває три ситуації, де нічної копії мало:
- Перед ризиковою дією — оновлення CMS, заміна теми, чистка бази, експерименти з
.htaccess. Відкат на знімок, зроблений хвилину тому, не зачепить сьогоднішні замовлення. - Копія у ваших руках — архів на вашому диску чи в хмарі не залежить ні від хостингу, ні від того, чи оплачено тариф.
- Переїзд — архів DirectAdmin розгортається на іншому сервері з DirectAdmin майже без ручної роботи. Про повний перенос — у статті перенести WordPress на новий хостинг.
Крок 1. Відкрити розділ бекапів
- Зайдіть у панель:
https://ваш-домен:2222(доступи — у листі після замовлення, детальніше в статті DirectAdmin: перші кроки). - Відкрийте System Info & Files → Create/Restore Backups. У деяких версіях інтерфейсу пункт підписаний як Site Backup — це те саме.
Сторінка поділена на дві частини: зверху створення копії, нижче — список уже наявних архівів для відновлення.
Крок 2. Вибрати, що копіювати
Панель показує перелік галочок. Ось що за ними стоїть:
| Пункт | Що потрапить в архів | Коли можна зняти |
|---|---|---|
| Domains Directory | Усі файли сайтів: код, зображення, завантаження | Ніколи — це основа |
| Databases | Дампи всіх MySQL-баз акаунта | Тільки якщо сайт статичний, без бази |
| E-mail Accounts, E-mail Data | Поштові скриньки та самі листи | Якщо пошта не на хостингу |
| FTP Accounts, Subdomains, DNS | Налаштування акаунта | Займають мало місця, краще лишити |
Для знімка перед оновленням сайту достатньо файлів і баз. Повний архів з поштою потрібен, коли ви робите копію «на випадок усього» або готуєтесь до переїзду.
Крок 3. Створити архів
Натисніть Create Backup. Панель поставить завдання в чергу і покаже повідомлення, що копія готується. Невеликий сайт пакується за кілька хвилин, акаунт із кількома гігабайтами пошти — довше. Коли архів готовий, DirectAdmin надсилає повідомлення у внутрішню скриньку панелі (іконка з конвертом угорі).
Готовий файл лежить у папці backups у корені вашого акаунта. Назва — на кшталт backup-Sep.30.2026-14.05.12-admin.tar.gz; у свіжих версіях панелі розширення може бути .tar.zst. У назві є дата і час, тому кілька копій не переплутаються.
Не запускайте створення кілька разів поспіль, якщо здається, що «нічого не відбувається». Кожне натискання — окреме завдання, і в результаті ви отримаєте кілька однакових архівів, які з'їдять дисковий простір.
Крок 4. Забрати копію з сервера
Це крок, який найчастіше пропускають, і дарма. Архів усередині акаунта — це зручний знімок для швидкого відкату, але не незалежна копія: він живе на тому самому диску, що й сайт.
- Відкрийте System Info & Files → File Manager і зайдіть у папку
backups. - Клікніть на файл архіву і виберіть Download. Для великих архівів зручніше FTP-клієнт — він продовжить завантаження, якщо зв'язок обірветься.
- Покладіть архів туди, де він переживе ваш ноутбук: зовнішній диск або хмара.
Після завантаження видаліть архів із сервера. Він враховується в дисковій квоті тарифу: копія сайту на 3 ГБ займає ще близько 3 ГБ, і на невеликому тарифі кілька забутих архівів непомітно впираються в ліміт. Що тоді відбувається з сайтом — у статті перевищено ліміт ресурсів хостингу.
Крок 5. Відновити сайт з архіву
Якщо архіву вже немає на сервері, спочатку завантажте його назад у папку backups через File Manager або FTP. Далі:
- На сторінці Create/Restore Backups у блоці Restore Backup виберіть потрібний архів.
- Натисніть Select Restore Options і відмітьте тільки те, що справді треба повернути.
- Підтвердіть відновлення і дочекайтесь повідомлення в панелі про завершення.
Відновлення перезаписує поточний стан тим, що було на момент архіву. Якщо ви відмітите бази інтернет-магазину, повернеться і стара база — з нею зникнуть замовлення й реєстрації, які прийшли після створення копії. Тому, коли зламались лише файли після оновлення плагіна, відновлюйте тільки Domains Directory, а базу не чіпайте.
Тільки база даних: швидкий окремий шлях
Для CMS найцінніше — база: товари, замовлення, тексти сторінок. Її можна копіювати окремо, не пакуючи весь акаунт:
- Account Manager → MySQL Management — біля кожної бази є дія для завантаження дампа. Файл
.sqlабо.gzодразу качається на ваш комп'ютер, без проміжних архівів на сервері. - Повернути дамп можна там само — через завантаження файлу в обрану базу — або через phpMyAdmin (посилання є в тому ж розділі), вкладка Import.
Перед імпортом старого дампа в робочу базу зніміть свіжий дамп поточного стану. Якщо щось піде не так, у вас буде шлях назад, а не тільки вперед.
Як часто робити копію вручну
Розклад під настрій не працює — працює прив'язка до подій:
- перед кожним оновленням ядра CMS, теми або великого плагіна;
- перед масовим імпортом товарів чи зміною цін через файл;
- перед будь-якими правками, які робить підрядник, до якого ви ще не звикли;
- раз на місяць — повний архів із поштою собі на диск, про всяк випадок.
Щоденну рутину краще лишити автоматичним нічним копіям. Ручні архіви — це точкові знімки, які ви робите свідомо і знаєте, від чого вони страхують. А що робити, коли щось таки зламалося, — описано в плані аварійного відновлення сайту.
Типові проблеми
- Архів не з'являється — найчастіше не вистачає місця в квоті: панелі нікуди записати файл. Видаліть старі архіви з
backupsі спробуйте знову. - Архів створився, але дуже великий — перевірте, чи не потрапили в нього кеш-папки CMS або старі архіви, які ви колись поклали в
public_html. - Після відновлення сайт видає помилку бази — дамп повернувся в базу з іншим іменем чи користувачем. Звірте дані підключення в конфігурації CMS з тим, що показує MySQL Management.
Потрібна копія на певну дату з нічних бекапів або допомога з відновленням — напишіть нам у Telegram, адміністратор підніме потрібний знімок. Перед великою роботою над сайтом можна попросити і позаплановий знімок.