Регулярне резервне копіювання допомагає захистити сайти та бази даних від випадкового видалення, пошкодження файлів, помилок під час оновлення або проблем із сервером. Для систем із Debian чи Ubuntu та панеллю ISPConfig 3 цей процес можна автоматизувати за допомогою Bash-скрипту.

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

Додаткові резервні копії зберігаються в окремому системному каталозі, доступному адміністратору сервера. Це дозволяє відновити дані навіть тоді, коли клієнт випадково видалив архів зі свого каталогу.

## Підготовка каталогу для скрипту

Спочатку потрібно створити захищений каталог, у якому зберігатиметься сценарій резервного копіювання:

```bash
mkdir -p /root/scripts
```

Після цього створюється файл скрипту та встановлюються права, які дозволяють запускати його лише користувачеві root:

```bash
touch /root/scripts/mybackup.sh
chmod 700 /root/scripts/mybackup.sh
```

Редагувати файл можна через консольний редактор:

```bash
nano /root/scripts/mybackup.sh
```

## Основні налаштування

На початку скрипту вказуються дані для підключення до MySQL:

* користувач бази даних;
* пароль;
* адреса сервера MySQL;
* основний каталог для резервних копій;
* окрема папка для архівів сайтів.

Для читання інформації про сайти й користувачів сценарій звертається до службової бази `dbispconfig`. Обліковий запис MySQL повинен мати достатні права для читання її таблиць і створення дампів клієнтських баз.

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

## Копіювання баз даних

Для кожної знайденої бази виконується `mysqldump`. Отриманий SQL-дамп одразу стискається за допомогою Gzip.

У результаті створюється файл приблизно такого формату:

```text
database_nameBU.gz
```

Архів зберігається в каталозі сайту, а його копія переноситься до загальної папки резервного копіювання адміністратора.

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

## Копіювання файлів сайтів

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

Назва архіву формується на основі домену:

```text
example.comBU.tar.gz
```

Після створення файлу сценарій встановлює правильного власника та групу. Завдяки цьому архів залишається доступним відповідному клієнту ISPConfig, але не відкривається стороннім користувачам сервера.

## Зберігання старих копій

Щоб резервні копії не заповнили весь диск, скрипт автоматично видаляє застарілі архіви.

У системному каталозі зберігаються:

* актуальні щоденні копії;
* кілька попередніх щоденних архівів;
* окремі недільні копії для тривалішого зберігання.

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

## Ручний запуск

Після заповнення параметрів скрипт можна перевірити вручну:

```bash
/root/scripts/mybackup.sh
```

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

Після завершення необхідно перевірити:

* чи створилися архіви сайтів;
* чи сформувалися дампи баз даних;
* чи правильно встановлені власники файлів;
* чи з’явилися копії в системному каталозі;
* чи відкриваються створені архіви.

## Автоматичний запуск через cron

Коли ручна перевірка пройшла успішно, скрипт можна додати до планувальника cron.

Для редагування розкладу користувача root виконується:

```bash
crontab -e
```

Наприклад, запуск щодня о 22:30 можна налаштувати так:

```cron
30 22 * * * /root/scripts/mybackup.sh >> /var/log/backup.log 2>&1
```

Повідомлення про роботу сценарію записуватимуться у файл `/var/log/backup.log`. Цей журнал потрібно періодично перевіряти, оскільки наявність завдання в cron ще не гарантує успішного створення копій.

Також важливо контролювати вільне місце на диску. Якщо сервер містить великі сайти або бази даних, навіть кілька комплектів архівів можуть займати значний обсяг.

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