bareos и webdav

Я вот не уверен, но ЕМНИП для bareos запилили возможность писать отдельные storage-плагины. Возможно имеет смысла поискать/написать плагин, поддерживающий запись через webdav без костылей в виде примонтированной ФС.

ЕМНИП: если у тебя будет обрыв в сети, во время того, как bacula/bareos будет скидывать напрямую на сетевое хранилище, твоя job сразу загнётся. И через retry time, будет пахать сначала. В общем, ты перед тем как юзать все эти сетевые дела, убедись что я не прав... Или что у тебя, очень хороший коннект, если я прав.

Это не очень критично. Я собираюсь раз в несколько месяцев сливать полный бекап под присмотром, а всё остальное время маленькие инкрементальные бекапы. Ну и коннект у меня довольно хороший.

Если говорить по сабжу, то я предполагаю, что то, что ты хочешь - не возможно. Любой webdav клиент, кеширует. Насколько я понимаю, что по-другому особенно с этим протоколом никак собственно. Конкретно в твоём случае, я думаю, что можно попробовать ограничить скорость job. Какой тебе смысл делать backup, со скоростью 200МБ/сек, если у тебя внешка всего: 100? Попробуй в bareos ограничить скорость backup твоих job, метров до 60. Никаких костылей не надо. Просто строчка в конфиге job

Буферный жёсткий диск на терабайт и синхронизация посредством rsync

Я хочу не это. Я не против кеширования. Bareos пишет бекап в тома (шифрованные архивы). Каждый том в определенном пуле имеет максимальный размер, когда у меня том с полным бекапом становится размером 512 мегабайт, bareos его закрывает и создает следующий том. Вот в этот момент я хочу отправить внешним скриптом завершенный том на webdav и удалить его с локальной машины. И при этом нужно сделать так, чтобы bareos не начинал писать следующий том, пока предыдущий не зальется на webdav.

Буферный жёсткий диск на терабайт и синхронизация посредством rsync

Технико-экономически нецелесообразно.

Красиво хочешь, но реализация боюсь не выйдет. У тебя же sd, будет ожидать, что у него доступно всё локально, он же будет purgre/truncate для старых томов... Как ты так извернёшься, чтобы оно у тебя писало в одно место, потом как-то переносило в другое, но при этом sd, думал, что у него всё локально - не знаю. Самый правильный вариант - подрезать скорость. Какая тебе разница, или на прямую лить со скоростью 60МБ/сек, или лить со скоростью 200МБ/сек, потом ждать пока оно со скоростью в 100 МБ/сек, куда-то зальётся... - Слишком много звеньев в цепи. Надо будет обрабатывать возможные ошибки. А вот выигрыш - сомнителен. Делай тома по 512 метров, и ограничивай скорость. И думаю, что у тебя вообще никаких проблем не будет, в случае даже обрыва, всё тебе bareos сделает сам. Всё будет работать как часы, если стабильный конект - так тем более.

Bareos пишет бекап в тома (шифрованные архивы).

Не очень понял, что за этим скрывается. Быть может, просто, рассмотреть $cryptofs какую-нибудь?

Проблема еще в том, что davfs2 очень похожа на кривую поделку, которая может всраться на ровном месте. В принципе можно было бы разбить один большой FileSet на кучу маленьких, сделать для каждого отдельный Job и добавить скрипт синхронизации с webdav в ClientRunAfterJob. Но при этом надо как-то решить проблему с томами, пропавшими из локального хранилища.

Не очень понял, что за этим скрывается.

За этим скрывается файл с типом «Bacula volume». Внутри него лежат файлы, пожатые алгоритмом LZ4 и зашифрованные aes256.

Быть может, просто, рассмотреть $cryptofs какую-нибудь?

Нет, это будет просто лишняя сущность поверх другой лишней сущности.

Нет, это будет просто лишняя сущность поверх другой лишней сущности.

Я боюсь, что ты совершил ошибку. Ты взял продукт для домашнего пользователя, и хочешь его использовать для enterprise нужд. Тебе нужно что-то блочное, сетевое. Или для какого-нибудь s3/s3 совместимого хранилища есть плагины наверняка. - ИМХО тебе туда надо было копать. А сейчас, у тебя самый правильный со всех точек зрения ход, это сделать всё локально с шифрованием (raid из двух дисков по 1ТБ), и делать rsync (не спеша) на ЯД.

Проблема еще в том, что davfs2 очень похожа на кривую поделку

Она не просто похожа, она и есть кривая, не предсказуемая поделка. Я накушался её в своё время, довольно хорошо.

P.S. и вообще, webdav мёртв.

s3 стоит слишком дорого для хранения моих фоточек. Я тоже начинаю склоняться к тому, чтобы купить дешевый диск для локального буфера перед отправкой на ЯД. Но ведь bacula/bareos может хранить бекапы на ленте, которая большую часть времени лежит на полке. Почему нельзя сделать тоже самое, только вместо записи на ленту и замены кассеты сделать заливку файла на webdav?

s3 стоит слишком дорого для хранения моих фоточек.

У них вроде что-то есть специальное для backup, ценой 1цент в год за гигабайт, кажется, т.е. 800 руб./год. А может и дешевле.

Почему нельзя сделать тоже самое, только вместо записи на ленту и замены кассеты сделать заливку файла на webdav?

Написать свой ченджер... - В целом, звучит круто, но я думаю, что сложно. :)

Есть уже готовые ченджеры для usb флешек на shell, но по-моему это какая-то жесть. Я хочу что-то попроще, но видимо слишком много хочу.

Огонь! :) Скинь на поглядеть?)

Посоветуйте что-нибудь.

ecryptfs

https://github.com/bareos/contrib-vchanger

Он оказывается не совсем на shell, просто вчера я прочитал по этой ссылке: «vchanger is a shell script that emulates a traditional tape library device and acts as an interface to Bacula».

Вообще штука не плохая. Вот к примеру, смотри, мне надо сейчас сделать bareos, на 10ТБ. Блин, вот как мне в одном SD сделать такое?) Остаётся только RAID-10. Что в общем случае очень не бюджетно. Да и ещё, при пересборке даже такого массива, второй диск в плече, может и вылететь... И тут начинаешь думать, или как-то Job перераспределять, чтобы скидывались сперва на один, потом на другой диск и так по-кругу. Потом сбойный диск менять, и чистить bareos. Или замутить авточенджер. :) Разумеется, всё это я не очень серьёзно говорю, но, проблема больших дисков + raid любого уровня, существует...

Да. Мне видимо предстоит в ближайшее время страдать с vchanger.

В итоге решил проблему следующим образом:

• Разбил всё на небольшие FileSet'ы по 100 гигабайт, для каждого сделал отдельный Job.
• Сделал раздел на 100 гигабайт, каскадно примонтировал его поверх davfs2 через aufs.
• Указал точку монтирования aufs в SD.
• Написал в пулах MaximumVolumeJobs = 1, чтобы оно даже не пыталось дописывать тома, которые лежат на davfs2.
• В JobDefs написал ClientRunAfterJob = "/backup/yd-webdav-upload.sh"
• В yd-webdav-upload.sh:

  #!/bin/bash
  for i in /backup/yd-overlay/vol* ; do
      echo put $i | cadaver https://webdav.yandex.ru > /dev/null 2>&1 || exit 1
      echo "Volume `basename $i` uploaded"
      rm $i
  done

Теперь bareos делает бекапы в локальную директорию, а потом они сливаются через cadaver на сервер. С точки зрения SD локальный каталог и webdav выглядят как единое целое. И это даже работает, и даже можно не только забекапиться, но и восстановиться оттуда.