18.02.2018 23:07, Artem Chuprina пишет: > artiom -> debian-russian@lists.debian.org @ Sun, 18 Feb 2018 21:23:52 +0300: > > >> >> >> >> - rsync поддерживает использование ssh как транспорт, > существуют так же > >> >> >> >> надстройки разные > >> >> >> >> > >> >> >> > Да, rsync хорошая штука. Я пользуюсь. Но дело в том, что над > ним > >> >> >> > придётся всё доделывать самостоятельно, а в той же Bacula > большинство > >> >> >> > функций реализовано и отлажено. > >> >> >> > >> >> >> >> Ничего не знаю по поводу "репликации в облко с шифрованием". > Это всё так > >> >> >> >> абстрактно... > >> >> >> >> > >> >> >> > 1. Шифрование бэкапов. > >> >> >> > 2. Репликация в выбранное облако (например, dropbox). > >> >> >> > >> >> >> > Т.к. dropbox и подобные - одна сплошная дыра, требуется > надёжное шифрование. > >> >> >> > Т.к. раньше я ими не пользовался, ничего конкретного про > >> >> >> > репликацию/наличие API спросить не могу. > >> >> >> > >> >> >> "Тут ведь как..." "Отправлять зашифрованное", "минимально гонять > по > >> >> >> сети", и "восстанавливать за разумное время" - выберите любые два > из > >> >> >> трех. > >> >> > Первые два, но время именно "разумное", я же не говорю "быстро". > >> >> > >> >> Я тоже говорю "разумное". Выберите любые два из трех. > >> >> > >> > В процессе изучения вопроса я обнаружил, что есть такая технология, как > >> > дедупликация на клиенте. > >> > И вообще, как ни странно, в случае с файлопомойками, дедап позволяет > >> > экономить до 98% дискового пространства. > >> > >> Это, гм, новость. По моим представлениям, дедупликация на файлопомойке > >> (где вообще-то каждый файл в среднем чуть более чем в одном экземпляре) > >> дает от силы процентов 10, если она пофайловая, и процентов 20, если > >> поблочная. А более вероятно - 3 и 5% соответственно. 98% - это надо > >> чтобы каждый файл (или блок) хранился в среднем в 50 экземплярах. Я могу > >> себе такое представить на хранилище, откуда работают сотни виртуальных > >> машин, но на файлопомойке? > >> > > Видимо, там большая файлопомойка с большим числом пользователей. > > Пользователи, как правило, не создают контент. > > Потому, файлы (и, тем более, блоки) часто дублируются. > > На файлопомойках пользователи как раз обычно создают контент. Если не > сам контент целиком, то выборка-то у всех разная. И для 50-кратного > дублирования надо устраивать очень специфический набор пользователей. Я > бы, пожалуй, взялся только роботами такое обеспечить, причем специально > криво написанными. > Возможно.
> >> Вот дедупликация на ее бэкапе - да, в разы. Но опять же, при разумной > >> политике хранения бэкапов ну, в 10 раз (если история бэкапов - штук > >> 15). Но не в 50. > >> > > Ещё неплохо, чтобы дедупликация делалась на клиенте. > > Тут, кстати, палка как минимум о двух концах. Я, например, дома > предпочитаю, чтобы отобранные фотографии из поездок хранились отдельно > от совпадающих с ними файлов из подборки оригиналов даже в бэкапе. Из > соображений "в случае сбоя диска будет второй экземпляр". Если сделать > полную дедупликацию, сбой диска убьет единственный. > Возможно, при ограниченных ресурсах по аппаратуре это применимо, но в целом, я считаю, подход неправильный. Надёжность хранилища должна нижним уровнем обеспечиваться. Явно не прикладным, на котором работает система резервного копирования.
