Представлен выпуск системы резервного копирования Restic 0.18, позволяющей хранить резервные копии в зашифрованном виде в версионированном репозитории с поддержкой дедупликации. Система изначально рассчитана на то, что резервные копии сохраняются в окружениях не заслуживающих доверия, и попадание резервной копии в чужие руки не должно скомпрометировать систему. При создании резервной копии возможно определение гибких правил для включения и исключения файлов и каталогов (формат правил напоминает rsync или gitignore). Поддерживается работа в Linux, macOS, Windows и BSD-системах. Код проекта написан на языке Go и распространяется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62996
> в системах, использующих дедупликацию, при наличии возможности добавлять свои файлы в резервную копию можно поступить проще и определить наличие интересующих файлов косвенным путём. После добавления проверяемого файла можно оценить изменение размера хранилища - если файл уже имеется в хранилище, то его повторное добавление из-за дедупликации не приведёт к должному увеличению размераВот сюрпрайз-то какой! Надо в каждый дублирующийся фрагмент добавлять соль, чтобы он отличался от других и при шифровании не совпадал с уже имеющимися. Это очень эффективная система дедупликации.
Дедупликация исключает возможность блокирования определения файла в хранилище. Хочешь больше безопасности - отключай дедупликацию и плати за место.
нети в борге уже сделали это давно
the chunk size fingerprinting attack is not new to us, it is the reason why we added the “obfuscate” pseudo compressor in Dec 2020 (released in borg 1.2.0 in Feb 2022). it has random-based additive and multiplicative methods to obfuscate the chunk size visible in the repository. if you have reason to fear high-profile attacks, that was made for you! it adds some space overhead though (which is configurable via its level parameter in a wide range), so that is the reason why it is not on by default. See “borg help compression”.
даже сомневаются что им надо для этого что-то делать в борге 2
But the question is whether we need changes there or whether it is better to just use the obfuscation.
The second paper also suggests padding of the chunks. Guess this has a similar effect as the already existing “obfuscate” functionality.
Возможно, я не очень хорошо знаю английский, но кажется в том, что вы процитировали, присутствует только самохвальная болтавня, без объяснения сути, как они сделали. И в конце дописка, что включение добавляет накладные расходы на дисковое пространство, и по этому, по умолчанию не включено.И раз уж вы так безапелляционно заявляете, что так можно, то не могли бы вы своими словами по-русски объяснить, как именно?
вот ссылка на полный текстhttps://github.com/borgbackup/borg/wiki/CDC-issues-reported-...
если засунуть в AI чат то он переведет вполне сносно, и может даже объяснит если понадобится
Только tar и ssh. По многим причинам эта парочка превосходит любые другие варианты.
Плюс башпортянка, плюс крон вместо таймеров системд (даже если системд уже установлен).
Какой софт, такая и степень доверия, уж извините.
> плюс крон вместо таймеров системдпару раз этот системд таймер не сработал без ошибок
был крайне удивлен
Ссылку на баг забыл приложить.
Для подкроватного сервака сойдет
А для кладовочного, для балконного?
tar + ssh в качестве бэкапа и для этих подойдет
> Только tar и ssh.И как там с инкрементальным, на 20 летний баг не нарывались еще?
Только zfs send/receive и ssh!
Да. И еще rsync.
Да господи, дедупликация не работает.И никогда не работала.
Все, что делает дедупликация - поднимает CPU и роняет io + память.
Выигрыша по обьему нет.
Это по опыту эксплуатации как блочных так и объектных хранилок
И уж совсем хороша дедупликация на лентах, хорошей обаной удачи с этим.
Вот конкретно тут -- работает и работает хорошо.Первый снапшот -- 10 GB добавилось в репозиторий.
Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB.Именно так оно у меня годами уже и работает, делая снапшоты по 4 раза в день. При сотнях ГБ сохраняемых данных размер репозитория не сильно больше.
Фрол, такое впечатление что твой коммент вызван травмой от ZFS, а не от пользования restic.
У тебя дедупликация и инкрементальное резервирование - это одно и то же?
> Первый снапшот -- 10 GB добавилось в репозиторий.Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB.
Сара пришла домой от врача и жалуется мужу:
- Изя, ты представляешь?! Я десять лет думала, что это оргазм, а оказалось, что это астма!Так и у тебя.
> Последующие -- только новые или изменённые файлы.Не совсем так. Измененные **части** файла только, а не весь файл. На виртуалках особенно заметно.
BTW, Пасиб за анекдот :)
Ты путаешь дедупликацию и инкрементальный бэкап.Дедупликация -- это когда у тебя один и тот же файл в разных директориях (или в одной, но с разными названиями), например. И вместо того, чтобы все их хранить в архиве, хранится только одна версия. Звучит полезно, но как часто такое нужно? Я единственный кейс могу придумать, когда данные разных пользователей (например фото/видео), почему-то, бэкапятся в один бэкап (что мне уже кажется антипаттерном).
А инкрементальный бэкап просто записывает изменения в оригинальном архиве, а не весь каждый раз -- технология стара как Юникс. Вон, что пишет Гопатыч:
> Incremental backups have been available in Unix-like operating systems since the 1970s. The first major implementation was in Version 6 Unix (1975), which introduced the dump and restore utilities.
> Звучит полезно, но как часто такое нужно?Очень нужно для файлового бэкапа большого количества одинаковых виртуалок. Штука действительно не очень востребованная на каждом локалхосте (и не локал тоже), и я даже соглашусь, что это костыль, но вот поди ж ты в прошлом году у клиента воспользовался, экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось.
> экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось.Не только на виртуалках, если виндовая сетка с folder redirection с раб.станций на сервак, то получится очень даже прилично отсечь дубликаты, бэкапируя сервачило.
Гит репы, тоже самое, когда народ натащил одинаковых зависимостей и у всех по копии
Про виндовые сетки не знаю, бог миловал, а вот с гитом пришлось повозиться. Если коротко, то бэкапить гит проще всего гитом через git clone --mirror […] git push --mirror.
> which introduced the dump and restore utilitiesЧто то я не припомню чтоб `dump` был инкрементальным.
тар, да, есть инкременталка, пока не нарвешься на баг который никто не фиксит
>> which introduced the dump and restore utilities
> Что то я не припомню чтоб `dump` был инкрементальным.
The following options are supported by dump:-0-9 Dump levels. A level 0, full backup, guarantees the entire file
system is copied (but see also the -h option below). A level
number above 0, incremental backup, tells dump to copy all files
new or modified since the last dump of any lower level. The
default level is 0.Но есть нюанс - как обычно, в пингвичике решили что все это устарело и ненужно, пользуйтесь таром.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511651 (ну и поддержки снапшотов в ext4 тоже нема).
> The following options are supported by dump:О блин, сорян , с fsarchiver перепутал...
> пользуйтесь таром.
нет уж спасибо, наступали уже...
>Я единственный кейс могу придуматьСамый оргазм - это образа VM-ок с дедупом бэкапить. Их то _все_ с нескольких шаблонов раскатывают, в результате экономия "чумачечия!"(С) (*)
Для всего остального я профита не нашёл и тупо отключил. :)(*) голубошляпые пушат как жЫть по-новому, и этот метод фэйзят в "голубой туман" :( А с новым дедуп ничего не даст, дешевле тоже выключить :( Покупайте сторидж спЭйс, больше спэйса! :)))
Ничего он не путает. Дедупликация это когда одни и те же (совпадающие) блоки переиспользуются.А уж используете вы дедупликацию для инкрементальности, для компрессии, или для экономии трафика, уже дело десятое.
Ну вот, похоже никто не смог оценить первоапрельскую шутку Фрол-а.
Если серьезно. Дедупликация, к примеру, в zpaq, не просто работает. Она радикально сокращает затраты места при хранении бекапов БД аля sqlite. Т.е. например объем бекапов хомяка юзера, активно использующего мессенджеры вроде Signal или SimpleX.
Еще про rsync ыспомни, как средство резервного копирования.Из мануала zpaq
> It does not follow or save symbolic links or junctions. It unknowingly follows hard links. It does not save owner or group IDs, ACLs, extended attributes, the registry, or special file types like devices, sockets, or named pipes.
Отличное средство для бэкапа своего ~/. Для бэкапа системы - тоже отличное, ровно до первого раза, как попробуешь восстановить из этого бэкапа систему. Ну или хотя бы часть системы.
Зато радикально сократил затраты. Я тебе еще более радикальный способ подскажу - в /dev/null копируй, там, говорят, экономия места еще выше.
Я думаю, что никто в самом деле не будет пытаться "восстановить" что бы то ни было из бэкапа.Бэкапы это если случайно нужный файл удалил, или система скрашилась с концами. Всё равно скорее всего придётся переустановить систему и разложить файлы из бэкапа по местам вручную.
Ну я ж говорю, для таких, как вы, резервное копирование в /dev/null - лучший выбор.Не всем так везет, с некоторых disaster recovery plan требуют, чтоб под рукой (и желательно км так в 300 от) всегда был актуальный набор медиа, с которого можно за сутки на голом железе развернуть копию ДЦ. Без всяких там переустановок забутстрапиться и развернуть.
Соглашусь, что написал недостаточно понятно. zpaq был приведен в качестве показательного примера, наглядно демонстрирующего эффективность дедупликации как таковой, при должных настройках. Как универсальное средство бэкапа он естественно не подходит, но может использоваться в составе.
Последнее предложение из предыдущего коммента относилось к бэкапу хомяка restic-ом, в нем эффект от дедупликации тоже заметен.
Хакер и солонка.
Хакер и солонка это глупая метафора, потому что в столовой есть "бай дизайн", капча. Роботы не едят в столовой.Если бы в столовой ели роботы, да ещё по 10к заказов в секунду, а в интернете так и есть, то всем сразу стала бы очевидна нелепость аналогии.
> Роботы не едят в столовойВерсия 2.0: Хакер и розетка.
>При сборке образов для GitHub Container Registry учтены рекомендации SLSA (Supply-chain Levels for Software Artifacts).Балканизация интернета наступает.