Как создать многотомный tar с загрузкой по ftp на лету?

Question

[Николай]

Добрый день.
Есть несколько веб сайтов с папками содержащими большое кол-во фото/видео, с довольно редким обновлением.
На одном проекте папка весит 250 гигов, за неделю добавляется несколько файлов.
В остальном сайты довольно часто обновляются и дорабатываются, соответственно всё это нужно как-то бэкапить на удаленный FTP.
Гонять каждую ночь терабайты статичных данных не вариант, к тому же хранилище одно и не вывозит по каналу / скорости записи.
В качестве выхода решено делать раздельный бэкап, больших папок и всего остального.
Всё остальное весит 200-400 мегабайт и отлично бэкапится каждую ночь.

С большими папками вопрос пока до конца не решен.
Были разные идеи типа сканирования сайта на предмет новых файлов и загрузке только их, но там вылезают лишние сложности.
Решили остановиться на полном бэкапе раз в неделю, но и тут есть нюанс.
На серверах нет свободного места для хранения бэкапа, поэтому tar (без сжатия) предполагается лить сразу на FTP, но и тут вылезает нюанс - размер файла.
С файлом на 250 гигов могут возникнуть проблемы, поэтому его нужно разбивать на части по 2 гига например.
В рядовых случаях шлем бэкапы через curl

tar -c -C ./  site.com/big_folder | curl -T - -u username:password ftp://backup.ru/disk2/user/file.tar

Я с linux консолью "на вы" пробовал пристроить сюда | split -b 2048M и так и сяк всё никак не могу добиться результата.
Какой командой это побороть?

P.S.: Думал про монтирование удаленного ftp отдельным разделом, но ftp хранилище отключается днём, есть опасение что с этим могут быть проблемы.

Answer 1

[pfg21]

сплит не работает с потоками, потому решением будет смонтировать фтп как файловую систему и сохранять туда нарезанные файлы.
---------------
поставить syncthing на сервере и на хранилище.
в синхфинге хранилища включить версионирование.
т.к. это демон, то любое изменение файлов будет сразу сливаться в хранилище ("бекапиться" в версионировании).
кстати и в обратку файлики тоже прекрасно будут заливаться. удобно если еще синхфинг поставить на рабочую машину

Comments

[Николай]

Ставить ничего не хочется, к тому же на хранилище ничего поставить не получится.
Логика бэкапов на самом деле весьма хитрая чем прост осинхронизация и она по сути реализована.
Задача только в передаче многотомного архива на лету по ftp.

[pfg21]

Николай, тогда, монтируйте фтп-хранилище перед бекап-операциями, а после отмонтировывайте.
ну и операции бекапа настройте делать только в то время, когда работает фтп-хранилище.
все онное засунуть в один скрипт и настроить крон.
или нарисовать системд-юнит.

опять же если меняется малая часть файлов, то стоит глянуть в rsync через ssh, который умеет диф к файлам.
кстати есть файловый диф и в самом tar. опция --listed-incremental, но чегойто мне кажется сия опция не доделана немношк.
и т.д. и т.п.

[hint000]

pfg21,

имхо постановка задачи кривовата

Согласен. У автора противоречие в условиях задачи. Нужно "на лету" (пайп, конвейер) и вместе с этим деление на тома. Так не бывает. Тем более, что в потоке будут бинарные данные, а не текстовые.

[pfg21]

hint000, в принципе такое намудрить можно.
к примеру написать сплиттер который будет получать команду с подстановкой номера нарезки. и при каждом сплите перезапускать команду.

имхо вданном случае эффективнее вариант с монтированием/отмонтированием curlftpfs - работа сплита становится нативна как пареная репа :)

хотя я все таки продумал бы надзадачу...

[Николай]

pfg21, спасибо!
Буду монтировать ftp в начале и размонтировать в конце бэкапа.

[pfg21]

переделаю таки ответ, а то как-то коряв он в сумме с обсуждениями.

Answer 2

[Drno]

rclone