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