Этого треда уже нет.
Это копия, сохраненная 24 октября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 24 октября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
182 Кб, 425x323Нужна программа для архивации данных в локальный бэкап для оффлан-хранения (читай: физически отсоединённый, между дописыванием бэкапа, диск).
Требований много. Вы советуйте, а я буду требовать по дороге.
Начнём со сложного, чтобы весь сброд сразу отфильтровать:
1. Инкрементальные байтовые бэкапы на подобие RSync.
2. Нужно, чтобы в бэкапе царила полная уникальность файлов, то бишь если в нём есть файл с таким-то хешем из папки Х, то при добавлении в бэкап файла с таким-же хешем из папки У, прога писала в бэкап вместо файла символическую ссылку на первый, а метаданные можно от второго.
Это чтобы, например, при переименовании папки с 50 гигами файлов, мне эта дура не дописывала ещё 50 гигов "новых" "непонятно откуда взявшихся" файлов в бэкап.
3. LZMA2-сжатие.
Требований много. Вы советуйте, а я буду требовать по дороге.
Начнём со сложного, чтобы весь сброд сразу отфильтровать:
1. Инкрементальные байтовые бэкапы на подобие RSync.
2. Нужно, чтобы в бэкапе царила полная уникальность файлов, то бишь если в нём есть файл с таким-то хешем из папки Х, то при добавлении в бэкап файла с таким-же хешем из папки У, прога писала в бэкап вместо файла символическую ссылку на первый, а метаданные можно от второго.
Это чтобы, например, при переименовании папки с 50 гигами файлов, мне эта дура не дописывала ещё 50 гигов "новых" "непонятно откуда взявшихся" файлов в бэкап.
3. LZMA2-сжатие.
Баш-скрипт: рсинкаешь, в пайпе сравнивешь хеш файла с бд хешей архива (можно плейнтекстовой), если хеш файла уникален, добавляешь в архив.
>>34533 (OP)
Нихрена не понел что ты хош, но попробуй zpaq.
Нихрена не понел что ты хош, но попробуй zpaq.
8 Кб, 341x29>>34551
Шин10 же.
Я конечно могу субсистему или Цигвин напрячь, но есть стойкое ощущение, что где-то на стыке будут сбои из-за специфик файловых систем и туда-сюда всякого platform-specific.
>>34620
Вижу, что не penis canina, но инкрементальная допись с атомизацией только на уровне файлов да при том по дате...
А что не понятно — спроси.
Символические ссылки гуглани, если это не понятно. Эффективный способ дедупликации и вне архивов. Вот надо, чтобы архивы поддерживали хранение символических ссылок и автоматически ими дедуплицировали добавляемые файлы.
Объём данных в номинале около терабайта.
Оверхедов пространства пытаюсь избежать, готов за это платить вычислительными оверхедами.
Как следствие вышеперечисленного, есть ещё требование:
4. Возможность починки архива и восстановление процесса бэкапа в следствии неожиданного или умышленного прерывания такового.
Ибо понятное дело оно минимум пару суток архивироваться с моим железом будет. Комп обычно не спит, но всякое бывает.
Шин10 же.
Я конечно могу субсистему или Цигвин напрячь, но есть стойкое ощущение, что где-то на стыке будут сбои из-за специфик файловых систем и туда-сюда всякого platform-specific.
>>34620
>zpaq
Вижу, что не penis canina, но инкрементальная допись с атомизацией только на уровне файлов да при том по дате...
А что не понятно — спроси.
Символические ссылки гуглани, если это не понятно. Эффективный способ дедупликации и вне архивов. Вот надо, чтобы архивы поддерживали хранение символических ссылок и автоматически ими дедуплицировали добавляемые файлы.
Объём данных в номинале около терабайта.
Оверхедов пространства пытаюсь избежать, готов за это платить вычислительными оверхедами.
Как следствие вышеперечисленного, есть ещё требование:
4. Возможность починки архива и восстановление процесса бэкапа в следствии неожиданного или умышленного прерывания такового.
Ибо понятное дело оно минимум пару суток архивироваться с моим железом будет. Комп обычно не спит, но всякое бывает.
>>34925
РСинк же не нативный.
Да и с большими объёмами всякое прерывание и восстановление придётся вручную писать.
Такими темпами проще уже велосипед изобрести, но когда на https://en.wikipedia.org/wiki/List_of_backup_software уже столько вариков — изобретать его не хочется. Если бы в этой поганой статье ещё реальную специфику работы софта описывали, я бы мог выбрать, а так приходится обращаться к случайному опыто анонов.
Просто покупать ставить каждую из них, потом писать в поддержку "а как настроить, чтобы оно вот так делало" и ждать месяц ответа "никак, мы хуй забили на такой функционал" не хочется.
РСинк же не нативный.
Да и с большими объёмами всякое прерывание и восстановление придётся вручную писать.
Такими темпами проще уже велосипед изобрести, но когда на https://en.wikipedia.org/wiki/List_of_backup_software уже столько вариков — изобретать его не хочется. Если бы в этой поганой статье ещё реальную специфику работы софта описывали, я бы мог выбрать, а так приходится обращаться к случайному опыто анонов.
Просто покупать ставить каждую из них, потом писать в поддержку "а как настроить, чтобы оно вот так делало" и ждать месяц ответа "никак, мы хуй забили на такой функционал" не хочется.
>>34533 (OP)
Linux rsync + ntfs-3g. Виндовый диск подключить к линукс в режиме read-only. Сделать бекап средствами линукосового rsync.
Linux rsync + ntfs-3g. Виндовый диск подключить к линукс в режиме read-only. Сделать бекап средствами линукосового rsync.
>>34533 (OP)>>34874
Dar, zpaq, borgbackup. Первые два - достаточно окаменевшие аксакалы для резервирования, которым нужно старательно читать документацию и подпердоливать параметры под конкретную ситуацию. Последний, относительно молодой (6 лет) продукт, которые уже активно юзается в проде нтюрпрайзом. Простой, быстрый, наварное надёжный.
zpaq uses a rolling hash function to split files into fragments with an average size of 64 KB along content-dependent boundaries
zpaq мощная говнинка, но, как говорил, её надо пердолить.
В dar и zpaq прямым текстом заявлена fault-tolerance архитектура. То есть битовая ошибка/обрыв архива позволяет восстановить как можно больше данных. Проверено лично мной. Работает.
В borg как минимум реализован repair битого хранилища. То есть тоже задумываются от тщетности бытия, в отличие от 7zip пидарасов, у которых битовая ошибка ломает архив целиком.
ECC, то есть добавление избыточности для починки ломаных архивов, нет ни в одном опенсорсном продукте. Сад бат тру.
Это только в borg видел. Лично не пробовал.
https://borgbackup.readthedocs.io/en/stable/faq.html#if-a-backup-stops-mid-way-does-the-already-backed-up-data-stay-there
В теории dar заточен на создание подтомов для записи на болванки, так что чисто гипотетически такая фича тоже может отыскаться.
АЛСО
Я в этом не спец, но покури стандартный NTBackup. Он как минимум не уступает всяким там костылям, а дедупликация со сжатием в последних версиях должна быть изкоробки.
Зачем тебе эта древность в эпоху zstd?
> 1. Инкрементальные байтовые бэкапы на подобие RSync.
Dar, zpaq, borgbackup. Первые два - достаточно окаменевшие аксакалы для резервирования, которым нужно старательно читать документацию и подпердоливать параметры под конкретную ситуацию. Последний, относительно молодой (6 лет) продукт, которые уже активно юзается в проде нтюрпрайзом. Простой, быстрый, наварное надёжный.
> атомизацией только на уровне файлов
zpaq uses a rolling hash function to split files into fragments with an average size of 64 KB along content-dependent boundaries
zpaq мощная говнинка, но, как говорил, её надо пердолить.
> 4. Возможность починки архива
В dar и zpaq прямым текстом заявлена fault-tolerance архитектура. То есть битовая ошибка/обрыв архива позволяет восстановить как можно больше данных. Проверено лично мной. Работает.
В borg как минимум реализован repair битого хранилища. То есть тоже задумываются от тщетности бытия, в отличие от 7zip пидарасов, у которых битовая ошибка ломает архив целиком.
ECC, то есть добавление избыточности для починки ломаных архивов, нет ни в одном опенсорсном продукте. Сад бат тру.
> и восстановление процесса бэкапа в следствии неожиданного или умышленного прерывания такового.
Это только в borg видел. Лично не пробовал.
https://borgbackup.readthedocs.io/en/stable/faq.html#if-a-backup-stops-mid-way-does-the-already-backed-up-data-stay-there
В теории dar заточен на создание подтомов для записи на болванки, так что чисто гипотетически такая фича тоже может отыскаться.
АЛСО
> Шин10 же.
Я в этом не спец, но покури стандартный NTBackup. Он как минимум не уступает всяким там костылям, а дедупликация со сжатием в последних версиях должна быть изкоробки.
> 3. LZMA2-сжатие.
Зачем тебе эта древность в эпоху zstd?
>>35730
для каждого файла можно самому прикрутить. есть консольные утилиты.
а вообще делается 2 бекапа. и Избытычность не нужна.
>
>ECC, то есть добавление избыточности для починки ломаных архивов, нет ни в одном опенсорсном продукте. Сад бат тру.
для каждого файла можно самому прикрутить. есть консольные утилиты.
а вообще делается 2 бекапа. и Избытычность не нужна.
>>35730
Сейчас уточнил. Borg под винду официального нет. Есть только. WSL и планы по портированию. Сорь, что ввёл в заблуждение.
Сейчас уточнил. Borg под винду официального нет. Есть только. WSL и планы по портированию. Сорь, что ввёл в заблуждение.
>>35735
Есть одна консольная утилита. PAR2. И она работает плохо. Очень плохо. На больших файлах можно не дождаться. Терабайт из разряда фантастики. Чуваки спецом пишут костыли, которые режут большие файлы на чанки и прогоняют их. Разраб обещает PAR3 уже лет 10. Плюс каждый раз генерится отдельный файл. Чтобы встроить это в систему резервирования с её ежедневными инкрементами надо реально упороться.
Лучше уж ФС c ECC навернуть.
>есть консольные утилиты.
Есть одна консольная утилита. PAR2. И она работает плохо. Очень плохо. На больших файлах можно не дождаться. Терабайт из разряда фантастики. Чуваки спецом пишут костыли, которые режут большие файлы на чанки и прогоняют их. Разраб обещает PAR3 уже лет 10. Плюс каждый раз генерится отдельный файл. Чтобы встроить это в систему резервирования с её ежедневными инкрементами надо реально упороться.
Лучше уж ФС c ECC навернуть.
>>35730
Совсем ебанашка?
https://softwarerecs.stackexchange.com/questions/26954/open-source-archiver-with-integrated-error-correction-code
>ECC, то есть добавление избыточности для починки ломаных архивов, нет ни в одном опенсорсном продукте.
Совсем ебанашка?
https://softwarerecs.stackexchange.com/questions/26954/open-source-archiver-with-integrated-error-correction-code
>>35739
multipar - закрытый костыль-обёртка вокруг того же par
dar - изкоробки не умеет, юзает par и очень костыльно
rar - лол
freeARC - реально единственный попенсорсный архиватор, который бай дизайн умеет в ECC, но официальные каналы распространения его выглядят пикрел
multipar - закрытый костыль-обёртка вокруг того же par
dar - изкоробки не умеет, юзает par и очень костыльно
rar - лол
freeARC - реально единственный попенсорсный архиватор, который бай дизайн умеет в ECC, но официальные каналы распространения его выглядят пикрел
>>35737
Короче поткал палкой в гугл. Из borg-подобных систем резервирования с дедупликацией, сжатием и поддержкой винды есть:
https://www.duplicati.com/
http://duplicity.nongnu.org/
https://restic.net/
https://kopia.io/
Но по ним уж детали выясняй сам.
Короче поткал палкой в гугл. Из borg-подобных систем резервирования с дедупликацией, сжатием и поддержкой винды есть:
https://www.duplicati.com/
http://duplicity.nongnu.org/
https://restic.net/
https://kopia.io/
Но по ним уж детали выясняй сам.
>>35738
Алсо даже нашлось несколько зверей с заявленным ECC. Но линакс-онли.
https://github.com/bup/bup
https://github.com/knoxite/knoxite
https://github.com/Roman2K/scat
Алсо даже нашлось несколько зверей с заявленным ECC. Но линакс-онли.
https://github.com/bup/bup
https://github.com/knoxite/knoxite
https://github.com/Roman2K/scat
Спасибо за советы, посоны.
Надо уточнить пару моментов:
Полноценный ЕСС не требуется.
Главное, чтобы при неожиданном прерывании херился не весь бэкап, а только последний чанк, над которым работа происходила и прога могла это понять, выкинуть битый чанк и продолжить с ровного места. Это может подразумевать атомарность сшивания новых данных с существующими, но не более.
И открытый код не является требованием. Если есть советы проприетарщины — советуйте. Воровать действительно не хочется, но будет не впервой...
>>35791
Duplicati начал тестить перед созданием треда.
Он в какой-то момент был заброшен.
Сейчас БЕТУ пилят. Дико сырая, всё неочевидно и костыльно.
Я как бы запилил с трёх пинков дописью один бэкап ею, ибо она без объяснения причин прекращала процесс на разных местах, но хер знает, чё там с надёжностью внутри, может там пол-бэкапа разворотило, трудно проверить. И насчёт дедупликации там хз, но похоже, что нет, судя по тому, как неуверенно там дела обстоят с симлинками в доках и issues на ГитХабе...
Не Шиндошс иначе уже давно попробовал бы. Кто-то рапортавал, что из под Цигвина гонял. Скепсис. На сайте у них расписаны некоторые красивые планы по расширению формата TAR с блэк-джеком и шлюхами, но, похоже, заброшено. Там же перечислены ограничения, с которыми прога сталкивается по причине использования ТАР.
Про дедупликацию не нашёл. Она РСинком подразумевается? Я не в курсе, РСинк сам ею занимается вообще?
Курю. В фичах заявлена дедупликация и шифрование. Это уже хорошо.
Но так же заявлено:
С одной стороны звучит битово, с другой стороны, в индустрии был тренд "инкрементальными" называть такие бэкапы, которые квантуют на уровне файлов.
ХЗ. Можно надеяться, что они не это имели в виду, наверное.
Тоже не совсем Шиндошс-специфик, и самый ахуй я словил от такой инструкции:
Шоблядь? А как же PATH? А как же "не суй говно всякое в системный путь"?
Про сжатие нихуя не нашёл.
Тоже в фичах заявлена дедупликация и шифрование. И тоже нет сжатия. Чёт как-то очень похоже на предыдущий. Тоже буду курить.
>>35771
Оу, ну с этим товарищем я знаком уже многие годы. Мой любимый архиватор для "просто пожать фаелы". Его собственный алгоритм сжатия — слабая, но стабильная и сравнительно быстрая имплементация PAQ, что дозволяет жать со всей дури сильнее, но медленнее LZMA(7z/xz), RAR или какого-нибудь ACE. (Ничего общего со старым форматом ARC не имеет кроме названия) А также поддерживает интерграцию с пакетом не-слишком-свободного обвеса в основном в виде пре-пакеров всяких, которые ещё сильнее улучшают соотношение сжатия.
Ну и распаковывать все распространённые и не очень виды архивов он умеет, а потому почти годен в замену 7Z на компе, кроме исключения, заключающегося в том, что он иногда ломается на попытке распаковать некоторые случайные архивы. Таки альфа всё ещё. Интерфейс по мне удобней.
У него раньше был какой-то нормальный сайт, но, видимо дехостнули. У тебя на скрине выглядит как помойка какая-то для русиков же, но может оно туда переехало, не знаю... На Соусфорже чёт не та версия.
Как бэкаповый архиватор его даже не думал пользовать. С тем сжатием, с которым я его пользовал для отдельных файлов, оно годами мой терабайт упаковывать будет. Да и, опять же, альфа. Немного сыкотно для таких объёмов, хотя на мелочи он себя за годы показал надёжным даже с обвесом проприетарных препакеров.
Их тоже пойду курить...
Надо уточнить пару моментов:
Полноценный ЕСС не требуется.
Главное, чтобы при неожиданном прерывании херился не весь бэкап, а только последний чанк, над которым работа происходила и прога могла это понять, выкинуть битый чанк и продолжить с ровного места. Это может подразумевать атомарность сшивания новых данных с существующими, но не более.
И открытый код не является требованием. Если есть советы проприетарщины — советуйте. Воровать действительно не хочется, но будет не впервой...
>>35791
Duplicati начал тестить перед созданием треда.
Он в какой-то момент был заброшен.
Сейчас БЕТУ пилят. Дико сырая, всё неочевидно и костыльно.
Я как бы запилил с трёх пинков дописью один бэкап ею, ибо она без объяснения причин прекращала процесс на разных местах, но хер знает, чё там с надёжностью внутри, может там пол-бэкапа разворотило, трудно проверить. И насчёт дедупликации там хз, но похоже, что нет, судя по тому, как неуверенно там дела обстоят с симлинками в доках и issues на ГитХабе...
Не Шиндошс иначе уже давно попробовал бы. Кто-то рапортавал, что из под Цигвина гонял. Скепсис. На сайте у них расписаны некоторые красивые планы по расширению формата TAR с блэк-джеком и шлюхами, но, похоже, заброшено. Там же перечислены ограничения, с которыми прога сталкивается по причине использования ТАР.
Про дедупликацию не нашёл. Она РСинком подразумевается? Я не в курсе, РСинк сам ею занимается вообще?
Курю. В фичах заявлена дедупликация и шифрование. Это уже хорошо.
Но так же заявлено:
>additional snapshots should only take the storage of the actual increment
С одной стороны звучит битово, с другой стороны, в индустрии был тренд "инкрементальными" называть такие бэкапы, которые квантуют на уровне файлов.
ХЗ. Можно надеяться, что они не это имели в виду, наверное.
Тоже не совсем Шиндошс-специфик, и самый ахуй я словил от такой инструкции:
>On Windows, put the restic.exe binary into %SystemRoot%\System32 to use restic in scripts without the need for absolute paths to the binary. This requires administrator rights.
Шоблядь? А как же PATH? А как же "не суй говно всякое в системный путь"?
Про сжатие нихуя не нашёл.
Тоже в фичах заявлена дедупликация и шифрование. И тоже нет сжатия. Чёт как-то очень похоже на предыдущий. Тоже буду курить.
>>35771
>freeARC
Оу, ну с этим товарищем я знаком уже многие годы. Мой любимый архиватор для "просто пожать фаелы". Его собственный алгоритм сжатия — слабая, но стабильная и сравнительно быстрая имплементация PAQ, что дозволяет жать со всей дури сильнее, но медленнее LZMA(7z/xz), RAR или какого-нибудь ACE. (Ничего общего со старым форматом ARC не имеет кроме названия) А также поддерживает интерграцию с пакетом не-слишком-свободного обвеса в основном в виде пре-пакеров всяких, которые ещё сильнее улучшают соотношение сжатия.
Ну и распаковывать все распространённые и не очень виды архивов он умеет, а потому почти годен в замену 7Z на компе, кроме исключения, заключающегося в том, что он иногда ломается на попытке распаковать некоторые случайные архивы. Таки альфа всё ещё. Интерфейс по мне удобней.
>официальные каналы распространения его выглядят пикрел
У него раньше был какой-то нормальный сайт, но, видимо дехостнули. У тебя на скрине выглядит как помойка какая-то для русиков же, но может оно туда переехало, не знаю... На Соусфорже чёт не та версия.
Как бэкаповый архиватор его даже не думал пользовать. С тем сжатием, с которым я его пользовал для отдельных файлов, оно годами мой терабайт упаковывать будет. Да и, опять же, альфа. Немного сыкотно для таких объёмов, хотя на мелочи он себя за годы показал надёжным даже с обвесом проприетарных препакеров.
>par, multipar, dar, rar как бэкап-архиваторы
Их тоже пойду курить...
Спасибо за советы, посоны.
Надо уточнить пару моментов:
Полноценный ЕСС не требуется.
Главное, чтобы при неожиданном прерывании херился не весь бэкап, а только последний чанк, над которым работа происходила и прога могла это понять, выкинуть битый чанк и продолжить с ровного места. Это может подразумевать атомарность сшивания новых данных с существующими, но не более.
И открытый код не является требованием. Если есть советы проприетарщины — советуйте. Воровать действительно не хочется, но будет не впервой...
>>35791
Duplicati начал тестить перед созданием треда.
Он в какой-то момент был заброшен.
Сейчас БЕТУ пилят. Дико сырая, всё неочевидно и костыльно.
Я как бы запилил с трёх пинков дописью один бэкап ею, ибо она без объяснения причин прекращала процесс на разных местах, но хер знает, чё там с надёжностью внутри, может там пол-бэкапа разворотило, трудно проверить. И насчёт дедупликации там хз, но похоже, что нет, судя по тому, как неуверенно там дела обстоят с симлинками в доках и issues на ГитХабе...
Не Шиндошс иначе уже давно попробовал бы. Кто-то рапортавал, что из под Цигвина гонял. Скепсис. На сайте у них расписаны некоторые красивые планы по расширению формата TAR с блэк-джеком и шлюхами, но, похоже, заброшено. Там же перечислены ограничения, с которыми прога сталкивается по причине использования ТАР.
Про дедупликацию не нашёл. Она РСинком подразумевается? Я не в курсе, РСинк сам ею занимается вообще?
Курю. В фичах заявлена дедупликация и шифрование. Это уже хорошо.
Но так же заявлено:
С одной стороны звучит битово, с другой стороны, в индустрии был тренд "инкрементальными" называть такие бэкапы, которые квантуют на уровне файлов.
ХЗ. Можно надеяться, что они не это имели в виду, наверное.
Тоже не совсем Шиндошс-специфик, и самый ахуй я словил от такой инструкции:
Шоблядь? А как же PATH? А как же "не суй говно всякое в системный путь"?
Про сжатие нихуя не нашёл.
Тоже в фичах заявлена дедупликация и шифрование. И тоже нет сжатия. Чёт как-то очень похоже на предыдущий. Тоже буду курить.
>>35771
Оу, ну с этим товарищем я знаком уже многие годы. Мой любимый архиватор для "просто пожать фаелы". Его собственный алгоритм сжатия — слабая, но стабильная и сравнительно быстрая имплементация PAQ, что дозволяет жать со всей дури сильнее, но медленнее LZMA(7z/xz), RAR или какого-нибудь ACE. (Ничего общего со старым форматом ARC не имеет кроме названия) А также поддерживает интерграцию с пакетом не-слишком-свободного обвеса в основном в виде пре-пакеров всяких, которые ещё сильнее улучшают соотношение сжатия.
Ну и распаковывать все распространённые и не очень виды архивов он умеет, а потому почти годен в замену 7Z на компе, кроме исключения, заключающегося в том, что он иногда ломается на попытке распаковать некоторые случайные архивы. Таки альфа всё ещё. Интерфейс по мне удобней.
У него раньше был какой-то нормальный сайт, но, видимо дехостнули. У тебя на скрине выглядит как помойка какая-то для русиков же, но может оно туда переехало, не знаю... На Соусфорже чёт не та версия.
Как бэкаповый архиватор его даже не думал пользовать. С тем сжатием, с которым я его пользовал для отдельных файлов, оно годами мой терабайт упаковывать будет. Да и, опять же, альфа. Немного сыкотно для таких объёмов, хотя на мелочи он себя за годы показал надёжным даже с обвесом проприетарных препакеров.
Их тоже пойду курить...
Надо уточнить пару моментов:
Полноценный ЕСС не требуется.
Главное, чтобы при неожиданном прерывании херился не весь бэкап, а только последний чанк, над которым работа происходила и прога могла это понять, выкинуть битый чанк и продолжить с ровного места. Это может подразумевать атомарность сшивания новых данных с существующими, но не более.
И открытый код не является требованием. Если есть советы проприетарщины — советуйте. Воровать действительно не хочется, но будет не впервой...
>>35791
Duplicati начал тестить перед созданием треда.
Он в какой-то момент был заброшен.
Сейчас БЕТУ пилят. Дико сырая, всё неочевидно и костыльно.
Я как бы запилил с трёх пинков дописью один бэкап ею, ибо она без объяснения причин прекращала процесс на разных местах, но хер знает, чё там с надёжностью внутри, может там пол-бэкапа разворотило, трудно проверить. И насчёт дедупликации там хз, но похоже, что нет, судя по тому, как неуверенно там дела обстоят с симлинками в доках и issues на ГитХабе...
Не Шиндошс иначе уже давно попробовал бы. Кто-то рапортавал, что из под Цигвина гонял. Скепсис. На сайте у них расписаны некоторые красивые планы по расширению формата TAR с блэк-джеком и шлюхами, но, похоже, заброшено. Там же перечислены ограничения, с которыми прога сталкивается по причине использования ТАР.
Про дедупликацию не нашёл. Она РСинком подразумевается? Я не в курсе, РСинк сам ею занимается вообще?
Курю. В фичах заявлена дедупликация и шифрование. Это уже хорошо.
Но так же заявлено:
>additional snapshots should only take the storage of the actual increment
С одной стороны звучит битово, с другой стороны, в индустрии был тренд "инкрементальными" называть такие бэкапы, которые квантуют на уровне файлов.
ХЗ. Можно надеяться, что они не это имели в виду, наверное.
Тоже не совсем Шиндошс-специфик, и самый ахуй я словил от такой инструкции:
>On Windows, put the restic.exe binary into %SystemRoot%\System32 to use restic in scripts without the need for absolute paths to the binary. This requires administrator rights.
Шоблядь? А как же PATH? А как же "не суй говно всякое в системный путь"?
Про сжатие нихуя не нашёл.
Тоже в фичах заявлена дедупликация и шифрование. И тоже нет сжатия. Чёт как-то очень похоже на предыдущий. Тоже буду курить.
>>35771
>freeARC
Оу, ну с этим товарищем я знаком уже многие годы. Мой любимый архиватор для "просто пожать фаелы". Его собственный алгоритм сжатия — слабая, но стабильная и сравнительно быстрая имплементация PAQ, что дозволяет жать со всей дури сильнее, но медленнее LZMA(7z/xz), RAR или какого-нибудь ACE. (Ничего общего со старым форматом ARC не имеет кроме названия) А также поддерживает интерграцию с пакетом не-слишком-свободного обвеса в основном в виде пре-пакеров всяких, которые ещё сильнее улучшают соотношение сжатия.
Ну и распаковывать все распространённые и не очень виды архивов он умеет, а потому почти годен в замену 7Z на компе, кроме исключения, заключающегося в том, что он иногда ломается на попытке распаковать некоторые случайные архивы. Таки альфа всё ещё. Интерфейс по мне удобней.
>официальные каналы распространения его выглядят пикрел
У него раньше был какой-то нормальный сайт, но, видимо дехостнули. У тебя на скрине выглядит как помойка какая-то для русиков же, но может оно туда переехало, не знаю... На Соусфорже чёт не та версия.
Как бэкаповый архиватор его даже не думал пользовать. С тем сжатием, с которым я его пользовал для отдельных файлов, оно годами мой терабайт упаковывать будет. Да и, опять же, альфа. Немного сыкотно для таких объёмов, хотя на мелочи он себя за годы показал надёжным даже с обвесом проприетарных препакеров.
>par, multipar, dar, rar как бэкап-архиваторы
Их тоже пойду курить...
29 Кб, 1261x273>>35730
Это про дедупликацию же. Непонятно как-то.
Смотри чуть ниже в пикриле про файлы.
Или подразумевается, что уровень файлов выше, он там добавляется по дате, разбивается на фрагменты уровнем ниже и там уже дедуплицируется на добавлении?
Неочевидно.
>zpaq uses a rolling hash function to split files into fragments with an average size of 64 KB along content-dependent boundaries
Это про дедупликацию же. Непонятно как-то.
Смотри чуть ниже в пикриле про файлы.
Или подразумевается, что уровень файлов выше, он там добавляется по дате, разбивается на фрагменты уровнем ниже и там уже дедуплицируется на добавлении?
Неочевидно.
>>35730
Очевидным плюсом, конечно поддержка VSS.
VHD не очень подходит, ибо я 3 диска бэкапаю. Можно конечно что-то выдумывать пытаться. Компрессию не поддерживает.
Ну и в целом главным целью, по видимому, является system state backup, а мне как раз вот это не нужно, ибо Шинда даже смену железок плохо переживает, чего смысл систем стейт её хранить...
>NTBackup
Очевидным плюсом, конечно поддержка VSS.
VHD не очень подходит, ибо я 3 диска бэкапаю. Можно конечно что-то выдумывать пытаться. Компрессию не поддерживает.
Ну и в целом главным целью, по видимому, является system state backup, а мне как раз вот это не нужно, ибо Шинда даже смену железок плохо переживает, чего смысл систем стейт её хранить...
>>35960
Этих можешь не трогать. Там только накладной ECC без сжатия.
Тогда посмотри бесплатные решения от Veeam. Они сейчас рулят рынком.
Я так понял, что подефолту файл с неизменной датой просто скипается. Если зафорсить, то он его будет разбивать и анализировать как новый файл, но в итоге один фиг найдёт сегменты в архиве и скипнет. То есть размер архива не должен вырасти.
> par, multipar,
Этих можешь не трогать. Там только накладной ECC без сжатия.
> И открытый код не является требованием.
Тогда посмотри бесплатные решения от Veeam. Они сейчас рулят рынком.
> Или подразумевается, что уровень файлов выше, он там добавляется по дате, разбивается на фрагменты уровнем ниже и там уже дедуплицируется на добавлении?
Я так понял, что подефолту файл с неизменной датой просто скипается. Если зафорсить, то он его будет разбивать и анализировать как новый файл, но в итоге один фиг найдёт сегменты в архиве и скипнет. То есть размер архива не должен вырасти.
>>35960
https://web.archive.org/web/20150831061640/http://freearc.org:80/
>У него раньше был какой-то нормальный сайт
https://web.archive.org/web/20150831061640/http://freearc.org:80/
>>36003
Только вот рынок щас уехал в сторону серверов бэкапающих сервера, а мне локальный чулановый бэкап нужен, от крипторансомвари всякой в том числе, не дай Б-г. Ну и диски сыпятся потихоньку, да...
Иначе бы я просто RAID развёл.
Один олдфаг снаружи советовал по старой памяти Acronis TrueImage, который как раз из той эпохи, когда никто не чесался по поводу облаков.
>Они сейчас рулят рынком.
Только вот рынок щас уехал в сторону серверов бэкапающих сервера, а мне локальный чулановый бэкап нужен, от крипторансомвари всякой в том числе, не дай Б-г. Ну и диски сыпятся потихоньку, да...
Иначе бы я просто RAID развёл.
Один олдфаг снаружи советовал по старой памяти Acronis TrueImage, который как раз из той эпохи, когда никто не чесался по поводу облаков.
>>36006
Миллионы параметров сжатия. Затратные дефолтные пресеты. Для ускорения надо знатную портянку из шаблонов накатать. Весьма костыльно выносить инкремент в отдельный файл. Ротация только вручную. Но в целом ничего сверхсложного.
У dar очень специфичный взгляд на пути и именование. Плюс он вечно норовит по поводу и без повода на интерактивное взаимодействие с пользователем. При скриптовании приходится кучу нюансов учитывать.
> А в чём заёбы с ним заключаются?
Миллионы параметров сжатия. Затратные дефолтные пресеты. Для ускорения надо знатную портянку из шаблонов накатать. Весьма костыльно выносить инкремент в отдельный файл. Ротация только вручную. Но в целом ничего сверхсложного.
У dar очень специфичный взгляд на пути и именование. Плюс он вечно норовит по поводу и без повода на интерактивное взаимодействие с пользователем. При скриптовании приходится кучу нюансов учитывать.
Алсо вот максимально полный список бэкапилок: https://github.com/restic/others
Информативность там хромает, но просто поделился из закромов.
Информативность там хромает, но просто поделился из закромов.
>>36006
Правда я надеюсь, что скипается только мясо файла, но метаданные таки пишутся, ибо надо как минимум знать потом при восстановлении, какие файлы какие папки занимали.
У меня в конкретном моём случае есть к примеру уже один ручной бэкап всей хуйни, просто файликами. Файлы в нём уже очевидно не на своих родных местах, откуда бэкапались. Я его хочу использовать как базу для бэкапа. Дальнейшие инкременты писать с живых дисков и, там будет много дубликатов файлов из базы. Но при этом если я решу восстановить файлы одного из живых путей из бэкапа, нужно, чтобы он понимал, что нужно вытащить те файлы из базового бэкапа, в пользу которых он скипнул живые в инкременте. То есть от инкремента хотя бы записать пути дубликатов.
>>36003
https://www.veeam.com/virtual-machine-backup-solution-free.html
Оно? Курю...
Правда я надеюсь, что скипается только мясо файла, но метаданные таки пишутся, ибо надо как минимум знать потом при восстановлении, какие файлы какие папки занимали.
У меня в конкретном моём случае есть к примеру уже один ручной бэкап всей хуйни, просто файликами. Файлы в нём уже очевидно не на своих родных местах, откуда бэкапались. Я его хочу использовать как базу для бэкапа. Дальнейшие инкременты писать с живых дисков и, там будет много дубликатов файлов из базы. Но при этом если я решу восстановить файлы одного из живых путей из бэкапа, нужно, чтобы он понимал, что нужно вытащить те файлы из базового бэкапа, в пользу которых он скипнул живые в инкременте. То есть от инкремента хотя бы записать пути дубликатов.
>>36003
>бесплатные решения от Veeam
https://www.veeam.com/virtual-machine-backup-solution-free.html
Оно? Курю...
>>36007
Я, кстати, конкретно этот случай решил через syncthing. Ни дедупликации, ни сжатия, ни инкремента. Всё просто как валенок. Врубаешь в чулане версионирование на последние 30 дней и спишь спокойно.
Это для вм. Тебе Veeam Agent for Windows, емнип, нужен.
Вряд ли это так просто заработает. Всё равно придётся с нуля всё сжимать и индексировать. Но насчёт метаинформации не парься. Эти системы запариваются за сохранением ACL атрибутов, уж путь то они не потеряют.
>от крипторансомвари
Я, кстати, конкретно этот случай решил через syncthing. Ни дедупликации, ни сжатия, ни инкремента. Всё просто как валенок. Врубаешь в чулане версионирование на последние 30 дней и спишь спокойно.
> Оно?
Это для вм. Тебе Veeam Agent for Windows, емнип, нужен.
> Я его хочу использовать как базу для бэкапа.
Вряд ли это так просто заработает. Всё равно придётся с нуля всё сжимать и индексировать. Но насчёт метаинформации не парься. Эти системы запариваются за сохранением ACL атрибутов, уж путь то они не потеряют.
>>36019
Вот тут не понял. Как это можно в чулане делать?
Я ведь действительно имею в виду подрубить диск к док-станции, бэкапнуть на него всю байду разом, заклеить диск в антистатический пакетик с силикагелем и убрать в тёмный чулан. Как же "continuous file synchronization" с этим совместим?
А если его не убирать в чулан, то что помешает крипторансомвари его похерить?
Ну а так я в том числе это делаю для того, чтобы продлить срок службы диска, ибо уже не один диск из строя выходил и текущие постепенно сыпятся. (Никогда не покупайте HDD Seagate, но если найдёте минтовые [не б/у] диски Hitachi [которые уже не производятся] — то берите). Надоел выход дисков из строя в общем.
Ошибся. Почитал этот маркетинг блурб про Вьетнам Мацхине Бацкуп и подумал, что Ораклы совсем уже разучились что-либо делать без виртуалок.
https://www.veeam.com/windows-endpoint-server-backup-free.html
Это, значит.
>>36019
Для дубликатов, самое главное, тоже?
Кстати, таки на Шинде ведь ACL нативней, а не как надстройка в Прыщах, но всё же иной зверь. Всегда немного ссал, как мультиплатформерные тулзы с этим работают...
>syncthing
>версионирование
>continuous file synchronization
>в чулане
Вот тут не понял. Как это можно в чулане делать?
Я ведь действительно имею в виду подрубить диск к док-станции, бэкапнуть на него всю байду разом, заклеить диск в антистатический пакетик с силикагелем и убрать в тёмный чулан. Как же "continuous file synchronization" с этим совместим?
А если его не убирать в чулан, то что помешает крипторансомвари его похерить?
Ну а так я в том числе это делаю для того, чтобы продлить срок службы диска, ибо уже не один диск из строя выходил и текущие постепенно сыпятся. (Никогда не покупайте HDD Seagate, но если найдёте минтовые [не б/у] диски Hitachi [которые уже не производятся] — то берите). Надоел выход дисков из строя в общем.
>Это для вм.
Ошибся. Почитал этот маркетинг блурб про Вьетнам Мацхине Бацкуп и подумал, что Ораклы совсем уже разучились что-либо делать без виртуалок.
>Тебе Veeam Agent for Windows, емнип, нужен.
https://www.veeam.com/windows-endpoint-server-backup-free.html
Это, значит.
>>36019
>ACL атрибутов
Для дубликатов, самое главное, тоже?
Кстати, таки на Шинде ведь ACL нативней, а не как надстройка в Прыщах, но всё же иной зверь. Всегда немного ссал, как мультиплатформерные тулзы с этим работают...
>>36025
У меня в чулане медиацентр крутится 24 на 7. Там стоит sincthing и в реальном времени сливает данные с рабочей машины. В случае криптолокера ломаные файл так же зальются в чулан, но сохранятся история версий. В теории.
Со съёмными дисками, офк, такой подход не пройдёт.
>Как это можно в чулане делать?
У меня в чулане медиацентр крутится 24 на 7. Там стоит sincthing и в реальном времени сливает данные с рабочей машины. В случае криптолокера ломаные файл так же зальются в чулан, но сохранятся история версий. В теории.
Со съёмными дисками, офк, такой подход не пройдёт.
>>36026
Ну да. Диск как бы обыкновенный, но на док-станции хотсвап настроен для удобства. Вроде Мелкопакостники чего-то там грозились запретить в Шинде10 съёмные диски, но хз, как это коснётся хотсвапа напрямую в САТА.
Потому в шапке написал "для оффлан-хранения", то бишь не в сети (данных/электричества).
Иначе бы мог держать его в канпуцкере физически подключённым и придумать какую-то систему, чтобы он всегда был выключен, кроме как когда какой-то низкоуровневый демон получает от меня авторизацию.
Ну да. Диск как бы обыкновенный, но на док-станции хотсвап настроен для удобства. Вроде Мелкопакостники чего-то там грозились запретить в Шинде10 съёмные диски, но хз, как это коснётся хотсвапа напрямую в САТА.
Потому в шапке написал "для оффлан-хранения", то бишь не в сети (данных/электричества).
Иначе бы мог держать его в канпуцкере физически подключённым и придумать какую-то систему, чтобы он всегда был выключен, кроме как когда какой-то низкоуровневый демон получает от меня авторизацию.
ОП, расскажи хоть, на чём остановился?
Интересно как там дела с дедупликацией под виндой.
Интересно как там дела с дедупликацией под виндой.
Тред утонул или удален.
Это копия, сохраненная 24 октября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 24 октября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.