Backup all databases & files
Go to file
2024-08-21 17:48:38 +05:00
service create 2024-07-11 16:18:02 +00:00
acme.sh autocommit 2024-08-14 10:49:57 +05:00
cleaner.sh changes 2024-08-08 05:50:15 +05:00
files-all.sh autocommit 2024-08-14 10:49:57 +05:00
files.sh autocommit 2024-08-14 10:49:57 +05:00
mariadb-all.sh autocommit 2024-08-14 10:49:57 +05:00
mariadb.sh autocommit 2024-08-21 17:48:38 +05:00
postgres-all.sh autocommit 2024-08-14 10:49:57 +05:00
postgres.sh autocommit 2024-08-14 10:49:57 +05:00
README.md changes 2024-08-08 05:50:15 +05:00
rozen_backup.sh changes 2024-08-08 05:50:15 +05:00

Backup all databases & files

Based on the: https://lohvynenko.com/ru/blog/a-way-to-get-daily-postgresql-backups-from-docker-swarm.html

  • В файле backups.list указываются папки, для которых нужно сделать резервные копии.

  • Скрипт автоматически находит все базы данных в postgres db и для каждой делает резервную копию в .sql формате.

  • Через заданный в файле cleaner.sh в переменной $EXPIRE_DAYS срок, устаревшие резервные копии будут удаляться.

  • Для запуска полного процесса нужно запустить скрипт all.sh с root правами.

  • Это тестовая версия скрипта, здесь могут быть недоработки.

  • Кроме того, необходимо проверить переменные, пути к директориям, которые указаны непосредственно в скриптах.

  • В скрипте remote-backup.sh приведен пример для удаленной синхронизации папки backups с другим сервером.

  • Скрипт должен быть запущен на другом сервере, нужно правильно указать настройки адреса сервера, пути, и кроме того, на сервере должен быть установлен ключ SSH для доступа.


Использование rsync для создания резервных копий на удаленный сервер, при котором инициатором подключения выступает сервер бэкапов, является хорошей практикой, повышающей безопасность ваших данных. Вот несколько советов, чтобы выполнить это правильно и надежно:

  1. Инвертируйте подключение:

    • Запускайте rsync с сервера бэкапов (сервер B), чтобы подключаться к основному серверу (сервер A) и забирать данные. Таким образом, у злоумышленника, который может получить контроль над сервером A, не будет прямого доступа к серверу B.
  2. Используйте SSH:

    • Обязательно используйте SSH для передачи данных, чтобы обеспечить шифрование соединения. Rsync может работать через SSH (например, rsync -avz -e ssh user@serverA:/path/to/data /local/path).
  3. Настройте управление доступом:

    • Ограничьте доступ к серверу A только для пользователя, который выполняет резервное копирование.
    • Используйте ключи SSH для аутентификации, и храните закрытый ключ на сервере B.
  4. Модифицируйте права на ключи:

    • Ограничьте права файлового доступа на закрытые ключи, чтобы только соответствующий пользователь мог их читать (chmod 600).
  5. Используйте ограничения SSH:

    • Ограничьте команды, которые могут быть выполнены с использованием ключа SSH, назначив предопределенную команду в файле authorized_keys на сервере A. Это можно сделать следующим образом:
      command="rsync --server -logDtprze.iLsfx --delete --numeric-ids . /path/to/data",no-agent-forwarding,no-port-forwarding,no-pty ssh-rsa AAAA... user@hostname
      
  6. Регулярные проверки и уведомления:

    • Настройте уведомления о сбоях и настраивайте регулярные проверки целостности данных.

Вот пример настроек, чтобы запустить резервное копирование с сервера B (сервера бэкапов):

  1. На сервере B создайте ключ SSH (если он еще не создан):

    ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa
    
  2. Скопируйте публичный ключ на сервер A:

    ssh-copy-id user@serverA
    
  3. На сервере B настройте cron job или systemd timer для регулярного выполнения rsync. Пример крон-задачи для ежедневного выполнения копирования в 2:00 ночи:

    0 2 * * * /usr/bin/rsync -avz -e ssh user@serverA:/path/to/data /local/path/to/backups
    

Использование этих техник значительно повысит безопасность вашего резервного копирования и уменьшит вероятность компрометации сервера бэкапов в случае взлома основного сервера.