Как настроить автоматическое копирование бэкапов на сторонний FTP?

Question

[motomac]

Использую automysqlbackup, который складирует дампы на основном сервере. Стоит задача настроить перенос этих бэкапов на сторонний FTP. Раньше пользовался ISP Manager - там эта функция есть по умолчанию, но недавно отказался от этой панели. Ставить целиком новую панель типа VestaCP не получится, потому что сервер уже работает, а установка этой панели требует начать с чистого листа.

Ищу самый простой способ настроить перелив бэкапов по крону. Кроме того FTP не бесконечный, потому старые файлы должны удаляться. В идеале хотелось бы какое-нибудь готовое и бесплатное решение.

Comments

[Сергей Соколов]

на стороннем сервере вы можете настроить logrotate, задачу на cron поставить – или только по FTP есть доступ?

[motomac]

Сергей Соколов: ага, только FTP.

Answer 1

[zzamzam]

Как раз недавно искал подобное решение и остановился на backupninja
Умеет по расписанию бэкапить БД и файлы и отправлять их на сторонний сервер разными способами, включая rsync, rdiff, duplicity

В /etc/backup.d/ создаёте конфиги вида 10-db.mysql , 50-ftp.dup
Числа в начале файла описывают очерёдность выполнения в случае одновременного запуска (сначала сдампить базу, а затем заливать из папки с архивом на ftp).
Расширение файла указывает на тип задачи (.mysql - бэкап mysql, .dup - используем duplicity)

Время выполнение бэкапов по-умолчанию задаётся в /etc/backupninja.conf

...
when = everyday at 01:00
...

Его можно переопределить для каждого отдельного бэкапа в начале его конфига

when = sundays at 02:00
when = 30th at 22
when = 30 at 22:00
when = everyday at 01            <-- the default
when = Tuesday at 05:00
when = hourly

Подробнее о конфигах backupninja здесь

Сам duplicity, которым я, например, делаю бэкапы, поддерживает кучу протоколов, в том числе и передачу по ftp. Также поддерживает ротацию бэкапов

Конфиг для duplicity выглядит примерно так:

## Переопределяем время выполнения
when = sundays at 02:00
## Параметры, передаваемые напрямую duplicity при запуске бэкапа
## --no-encryption позволяет отключить шифрование архивов с бэкапом и получить обычный .tar.gz
#options = --no-encryption

testconnect = no
tmpdir = /tmp

[source]
include = /var/backups/mysql
include = /home/user/projects/site1
exclude = /home/user/projects/.git

[gpg]
## Ключ для симметричного шифрования. Duplicity шифрует бэкапы с помощью gpg. Должен быть указан, даже если стоит --no-encryption, хоть и не будет использоваться
password = 123

[dest]
## perform incremental backups
incremental = yes

## days of incremental backups before doing full backup again
increments = 7

## how many days of data to keep
keep = 14

## for how many full backups do we keep their later increments
keepincroffulls = all

desturl = ftp://backup_user@your_backup_server/
ftp_password = backup_user_password

В бэкапах получаются на первый взгляд не очень понятные файлы, типа
duplicity-full-signatures.20130510T160711Z.sigtar.gpg
duplicity-full.20130510T160711Z.manifest.gpg
duplicity-full.20130510T160711Z.vol1.difftar.gpg

Тут можно чуть поподробнее прочитать про них

С бэкапами лучше работать самой утилитой duplicity, но можно и вручную их вытащить. Вручную минус в том, что инкрементальные бэкапы придётся вручную накатывать на полные, когда duplicity сделает это автоматом при указании даты восстановления.
duplicity collection-status src выдаст что-то типа этого

Total number of contained volumes: 3
Type of backup set:                        Time:                        Num volumes:
Full                            Mon Apr 17 00:24:46 2017                 1
Incremental                     Mon Apr 17 01:00:03 2017                 1
Incremental                     Mon Apr 17 09:53:38 2017                 1

после чего можно прочитать содержимое архива на определённую дату
duplicity list-current-files --time 2017-04-17T05:00:00 src (покажет бэкап Mon Apr 17 01:00:03 2017, т.е. ближайший ДО указанного времени)
и восстановить
duplicity restore --time 2017-04-17T05:00:00 src dst

src - это то, где ваши бэкапы хранятся.
Это может быть и локальная директория file:///var/backups//
И ftp ftp://user:password@backup_server//var/backups

Сами файлы хранятся в vol#.difftar.[tar.gz|gpg], если надо вручную вытащить
Если шифровали, то сначала расшифровать .gpg, чтобы получить .tar.gz

Comments

[motomac]

Большое спасибо за столь развернутый ответ! Все это время разбирался с duplicity и backupninja. Вроде разобрался, хотя сначала все это казалось ну очень уж запутанным :)

Если я правильно понял и настроил, действует все следующим образом:

1. Backupninja ежедневно запускает mysqldump, который создает бэкап БД под одним и тем же именем, затирая вчерашний;
   
2. Далее Backupninja запускает Duplicity, который сливает содержимое папки с бэкапами на FTP/WebDAV. При этом именно Duplicity следит за удалением старья из удаленного хранилища, а также отвечает за "инкрементность" бэкапов;
   

Жаль, в Duplicity нельзя полностью отказаться от шифрования.

Решил попробовать с Яндекс.Диском вместо FTP. Небольшой совет тем, кто будет делать то же самое: в Яндекс.Диске есть возможность создать пароль для приложения. Такие образом, в конфигах Duplicity не будет светиться ваш основной пароль на Яндекс-аккаунта. Пароль для приложения дает доступ только в определенный сервис Яндекса - в нашем случае в Диск. Надеюсь, в будущем они добавят возможность доступа только в определенные папки Диска.

[zzamzam]

motomac: да, всё верно

Шифрование можно отключить, в примере конфига выше есть информация

В самом начале задания на бэкап ставите
options = --no-encryption
options передаёт любые параметры запуска для duplicity

Но всё равно обязательно должна быть секции [gpg] и password

[gpg]
## Ключ для симметричного шифрования. Duplicity шифрует бэкапы с помощью gpg. 
## Должен быть указан, даже если стоит --no-encryption, хоть и не будет использоваться
password = 123