backup/README.md
2024-08-08 05:50:15 +05:00

61 lines
5.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

### 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. Это можно сделать следующим образом:
```plaintext
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 (если он еще не создан):
```sh
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa
```
2. Скопируйте публичный ключ на сервер A:
```sh
ssh-copy-id user@serverA
```
3. На сервере B настройте cron job или systemd timer для регулярного выполнения rsync. Пример крон-задачи для ежедневного выполнения копирования в 2:00 ночи:
```plaintext
0 2 * * * /usr/bin/rsync -avz -e ssh user@serverA:/path/to/data /local/path/to/backups
```
Использование этих техник значительно повысит безопасность вашего резервного копирования и уменьшит вероятность компрометации сервера бэкапов в случае взлома основного сервера.