[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backup



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.
 >>
 > Ещё неплохо, чтобы дедупликация делалась на клиенте.

Тут, кстати, палка как минимум о двух концах. Я, например, дома
предпочитаю, чтобы отобранные фотографии из поездок хранились отдельно
от совпадающих с ними файлов из подборки оригиналов даже в бэкапе. Из
соображений "в случае сбоя диска будет второй экземпляр". Если сделать
полную дедупликацию, сбой диска убьет единственный.


Reply to: