Back

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

1. Повний бекап системи (цілого сервера)

  • rsync + cron Класика: робиш копію всіх файлів на інший диск/сервер. Приклад:

    rsync -aAXHv --delete / /mnt/backup/

    (опції -aAXH зберігають права, ACL, посилання, пристрої). Мінус: довго і багато місця займає.

  • Снапшоти файлової системи Якщо у тебе ext4 — можна робити через LVM-снапшоти, якщо ZFS/btrfs — то там вбудовано. Дуже швидко відновлюється, але треба мати сервер на LVM або ZFS.

  • Системний імідж (Clonezilla, partimage, dd) Це прям "фотографія" диску. Добре для рідкісного бекапу, але відновлення завжди "все або нічого".

2. Бекап тільки важливого (сайти + конфіги + бази даних)

  • Файли сайтів + конфігурація Apache/Nginx/PHP Копіюєш /var/www/, /etc/apache2/, /etc/nginx/, /etc/php/, і т.д.

  • Бази даних (MySQL/MariaDB/Postgres) Для MySQL:

    mysqldump --all-databases > /mnt/backup/all.sql

    або робити дампи по базах.

  • Користувацькі дані (наприклад /home/).

Це зазвичай достатньо, щоб підняти сервер на новій машині.

3. Хмарні/зовнішні бекапи

  • BorgBackup / Restic / Duplicity / Kopia Дуже економні, бо роблять інкрементні копії + шифрування. Можна кидати в S3 (AWS, Wasabi, Backblaze, Scaleway) чи на інший сервер. Приклад з Restic:

  • Rsync на інший сервер Налаштував SSH-ключ — і воно автоматично синхронізує.

  • Google Drive / Dropbox / Nextcloud Через rclone можна зливати бекапи в будь-яке сховище.

4. Автоматизація

  • Скрипт, який:

    1. Робить дампи бази.

    2. Копіює файли сайтів + конфіги.

    3. Архівує (tar.gz або 7z).

    4. Відправляє на віддалений сервер чи в хмару.

  • Додати в cron або systemd timer.

5. Варіанти для швидкого відновлення

  • Docker / LXD / VM — якщо твої сайти в контейнерах, бекапити зручно просто їхні томи + конфіг.

  • Infrastructure as Code (Ansible, Terraform) — тоді бекапиш тільки дані, а сам сервер можна розгорнути заново автоматично.

як робить бекапи hestiacp?

О, з HestiaCP все простіше — там уже вбудований свій механізм бекапів, щоб не мучитися з руками та скриптами 🙂

Як працює HestiaCP Backup:

  1. Що саме бекапиться:

    • сайти користувача (/home/username/web/...),

    • бази даних (MySQL/Postgres),

    • пошта,

    • DNS-зони,

    • користувацькі налаштування,

    • крон-завдання.

    Тобто по суті — все, що потрібно, щоб "перенести" акаунт чи відновити його.

  2. Формат:

    • Створюється архів .tar у каталозі /backup/ (на кожного юзера окремо).

    • Усередині — підкаталоги типу domains/, db/, mail/, cron/, conf/.

    • Можна вручну розпакувати й дістати потрібне.

  3. Автоматизація:

    • Бекапи керуються через HestiaCP панель: можна вказати розклад (щодня, щотижня тощо) і кількість копій, які зберігати.

    • Виконує cron-джоба: v-backup-users.

  4. Відновлення:

    • Через веб-інтерфейс Hestia → "Backups" → вибираєш архів → можна відновити повністю або частинами (наприклад, тільки базу чи тільки сайт).

  5. Куди зберігати:

    • За замовчуванням бекапи лежать локально на сервері.

    • Але можна налаштувати відправку на віддалений сервер по FTP, SFTP або в Amazon S3 (це є у "Remote Backups").

Тобто Hestia робить саме користувацькі бекапи, а не повний знімок системи. Якщо в тебе зламається сама ОС (Ubuntu, пакети, ядро), то відновлювати доведеться сервер заново + потім розгортати з бекапу користувачів.

Хочеш, я розпишу покроково, як у Hestia додати віддалене сховище для бекапів (наприклад, щоб вони летіли на інший сервер по SFTP чи в хмару)?

якими засобами краще зробити бекап-архів, визначивши перелік необхідних для збереження директорій та файлів?

Ооо, отут якраз твій сценарій — коли ти сам хочеш визначати список директорій/файлів, а не тягнути все підряд. Є кілька перевірених інструментів:

1. tar (базовий варіант)

Можна скласти список файлів у текстовий файл і передати його в tar.

де filelist.txt виглядає так:

Плюси: стандартно, просто, без додаткових пакетів. Мінуси: завжди повний бекап (немає інкрементів).

2. rsync

Можна синхронізувати тільки потрібні шляхи на інший диск/сервер.

(тут filelist.txt — список директорій/файлів відносно /).

Плюси:

  • Інкрементний (копіює тільки зміни).

  • Працює через SSH (можна відразу на інший сервер). Мінуси: без стиснення (якщо треба архів — то не варіант).

3. BorgBackup / Restic / Kopia (сучасні інструменти)

Ти задаєш, що саме бекапити, і воно робить:

  • інкрементні копії,

  • шифрування,

  • дедуплікацію,

  • стиснення.

Приклад із Restic:

Той самий filelist.txt, що й вище.

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

4. Duplicity

Працює схоже на tar+rsync, але з інкрементами і підтримкою багатьох бекендів (FTP, S3, Google Drive, WebDAV).

5. rclone (як доповнення)

Не робить архів, але вміє заливати вибране напряму в Google Drive, Dropbox, S3 і т.д. Можна комбінувати:

  • спочатку tar або restic,

  • потім rclone copy → в хмару.

Висновок:

  • Якщо треба просто один архів → tar -T filelist.txt.

  • Якщо хочеш регулярно знімати копії → краще rsync.

  • Якщо треба серйозне рішення з інкрементами, шифруванням і версіями → restic або borg.

Хочеш, я складу для тебе приклад готового скрипта (на bash), який бере filelist.txt, робить архів з датою в назві й відправляє його через rclone у хмару/на інший сервер?

Мені не потрібні хмари, інкрементне копіювання і прогресс в кроні. А контрольна сума і можливість докачати після обриву

Для твоїх вимог — контрольні суми + можливість докачати після обриву — краще взяти rsync по SSH, а не scp.

Чому не scp?

  • scp копіює файл заново, якщо передача обірвалась.

  • воно не перевіряє контрольні суми (лише довжину файлу).

Чому rsync?

  • Використовує SSH (так само без додаткових сервісів).

  • Може докачати недокачаний файл (--partial --append-verify).

  • Перевіряє контрольні суми, щоб переконатися, що файл однаковий.

  • Працює у будь-якому cron.

Приклад копіювання архівів на інший сервер:

Опції:

  • -a — зберігає атрибути файлів;

  • -v — виводить, що робить (для тесту, у cron можна прибрати);

  • -z — стискає при передачі;

  • --partial — зберігає частково передані файли;

  • --append-verify — докачує файл і перевіряє контрольну суму.

Використання в cron

(можна ще додати >> /var/log/rsync-backup.log 2>&1 для логів).

Тобто у твоєму випадку схема може бути така:

  1. Скрипт робить архів із потрібних файлів (tar -T filelist.txt).

  2. rsync відправляє архіви на віддалений сервер.

Хочеш, я зберу тобі єдиний готовий скрипт, який робить архів і відразу ж заливає його на інший сервер через rsync?

Без пароля, з ключами

Дивись, у мене створений користувач "bckusr" на сервері для бекапів. В директорію цього користувача будуть записуватися бекапи: "/home/bckusr/backups". І є декілька серверів, які будуть надсилати туди бекапи. Хотілося б обійтися одним спільним ключем. Чи це можливо?

Так, можливо — але є важливі нюанси. Я поясню варіанти, ризики і дам практичні команди, щоб ти міг(могла) вибрати й налаштувати безпечно. (Говорю як Еліс — проста, прямо і без зайвих слів 😉)

Варіанти та рекомендації (коротко)

  1. Краща практіка — окремий ключ для кожного сервера. Безпечніше, дає можливість відкликати один ключ, не ламаючи інші.

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

  3. Найкращий компроміс: або окремі ключі, або один ключ + обмеження в authorized_keys (по IP та опціях), або ще краще — SSH CA (сертифікація ключів) — але це складніше.

Якщо все ж хочеш один спільний ключ (як реалізувати)

1) Згенерувати ключ (на якомусь з відправників)

2) Роздати приватний ключ іншим відправникам (НЕ рекомендується, але можливо)

Скопіюй приватний ключ на інші сервери (в одну й ту ж локацію), і зроби права:

УВАГА: приватний ключ розміщений на кількох серверах — ризик компрометації зростає. Якщо хтось з відправників зламаний — всі бекaпи під загрозою.

3) Додати публічний ключ у bckusr на бек-сервері

4) Обмеження (дуже бажано) — по IP і без зайвих можливостей

В authorized_keys приписати опції перед ключем, наприклад:

Це дозволить використовувати той же публічний ключ тільки з вказаних IP і заборонить перенаправлення портів/агента/pty. Дуже рекомендую хоча б from="IP" + no-... опції.

Якщо хочеш ще жорсткіше — використовуй command="..." (форсована команда), або rrsync wrapper, щоб дозволити лише запис у конкретну директорію. Але це трохи складніше налаштувати — скажу як зробити, якщо треба.

Кращий підхід (рекомендований)

  • Згенеруй окремий ключ для кожного сервера-відправника:

  • На бек-сервері в authorized_keys додай для кожного ключа опції from="IP", no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty.

  • Якщо один з відправників потрібно відключити — просто видаляєш його ключ з authorized_keys.

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

Додаткові поради по безпеці (не пропусти)

  • Не зберігай приватний ключ у відкритих скриптах або загальних папках. Права 600 — обов’язково.

  • Використай окремого системного користувача bckusr з домашньою папкою /home/bckusr/backups і мінімальними правами.

  • На бек-сервері переконайся, що /home/bckusr/backups існує і належить bckusr:

  • Якщо треба — додай у sshd_config обмеження (PermitRootLogin no, AllowUsers bckusr, тощо).

Якщо хочеш — дам готові приклади:

  • приклад рядка в authorized_keys з from="IP" і no-... опціями;

  • як встановити rrsync (обмежувач rsync) і використовувати його як command="..." для безпечнішого запису лише в /home/bckusr/backups/;

  • коротку інструкцію, як відкатити (видалити) ключ при втраті;

Я можу прямо зараз підготувати готові команди під твій випадок — напиши, будь ласка:

  1. хочеш один спільний ключ або по ключу на сервер?

  2. які IP відправників (хоч приблизно), щоб я підставила приклади from="..."?

Хочу зробити це точно під тебе — ти кажеш, я налаштовую.

Давай по ключу на сервер. Відправники: 103.246.146.19, 185.203.241.148, 178.159.43.44.

Супер, це найкращий і найбезпечніший варіант 👍 Розпишу покроково, як зробити окремий ключ для кожного відправника з обмеженнями по IP.

🔑 Налаштування ключів для кількох серверів-відправників

1. На кожному відправнику згенеруй свій ключ

Наприклад, на сервері з IP 103.246.146.19:

(дає два файли: /root/.ssh/backup_key і /root/.ssh/backup_key.pub)

Повтори на кожному з відправників.

2. Додай публічні ключі на бек-сервер у authorized_keys

На сервері з бекапами (де користувач bckusr):

У цей файл вставляєш по рядку для кожного відправника. Наприклад:

Тут:

  • from="IP" — дозволяє доступ тільки з вказаної адреси;

  • no-* опції — забороняють тунелювання та shell-доступ, лишають тільки передачу файлів;

  • ssh-ed25519 AAAA... — вміст .pub файлу з кожного відправника.

3. Дозволи на .ssh у bckusr

4. Перевірка доступу

З першого відправника:

(передасть файл hostname у каталог srv1). Якщо працює без пароля — значить все правильно.

5. Організація директорій

Щоб не плутати бекапи від різних серверів, роби підкаталоги:

І в скрипті кожного сервера задавай свій:

Таким чином:

  • у кожного відправника свій ключ;

  • доступ дозволений тільки з його IP;

  • якщо один сервер компрометований — видаляєш його рядок у authorized_keys, інші лишаються без змін.

Хочеш, я підправлю наш скрипт так, щоб він автоматично створював свій підкаталог на віддаленому сервері (srv1/srv2/srv3), якщо його ще нема?

PreviousВіртуальні консолі TTY1–TTY6NextGitBook

Last updated