| 1.4, YetAnotherOnanym (ok), 11:00, 01/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 > в системах, использующих дедупликацию, при наличии возможности добавлять свои файлы в резервную копию можно поступить проще и определить наличие интересующих файлов косвенным путём. После добавления проверяемого файла можно оценить изменение размера хранилища - если файл уже имеется в хранилище, то его повторное добавление из-за дедупликации не приведёт к должному увеличению размера
Вот сюрпрайз-то какой! Надо в каждый дублирующийся фрагмент добавлять соль, чтобы он отличался от других и при шифровании не совпадал с уже имеющимися. Это очень эффективная система дедупликации.
| | |
| 1.5, Аноним (5), 11:39, 01/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Дедупликация исключает возможность блокирования определения файла в хранилище. Хочешь больше безопасности - отключай дедупликацию и плати за место.
| | |
| |
| 2.28, penetrator (?), 19:29, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
нет
и в борге уже сделали это давно
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.
| | |
| |
| 3.37, Аноним (5), 21:53, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Возможно, я не очень хорошо знаю английский, но кажется в том, что вы процитировали, присутствует только самохвальная болтавня, без объяснения сути, как они сделали. И в конце дописка, что включение добавляет накладные расходы на дисковое пространство, и по этому, по умолчанию не включено.
И раз уж вы так безапелляционно заявляете, что так можно, то не могли бы вы своими словами по-русски объяснить, как именно?
| | |
|
|
| 1.6, Аноним (6), 12:12, 01/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Только tar и ssh. По многим причинам эта парочка превосходит любые другие варианты.
| | |
| |
| 2.8, Аноним (8), 12:32, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Плюс башпортянка, плюс крон вместо таймеров системд (даже если системд уже установлен).
| | |
| |
| 3.43, Аноним (43), 08:36, 02/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> плюс крон вместо таймеров системд
пару раз этот системд таймер не сработал без ошибок
был крайне удивлен
| | |
|
| 2.35, OpenEcho (?), 21:32, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Только tar и ssh.
И как там с инкрементальным, на 20 летний баг не нарывались еще?
| | |
|
| 1.7, Фрол (?), 12:26, 01/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Да господи, дедупликация не работает.
И никогда не работала.
Все, что делает дедупликация - поднимает CPU и роняет io + память.
Выигрыша по обьему нет.
Это по опыту эксплуатации как блочных так и объектных хранилок
И уж совсем хороша дедупликация на лентах, хорошей обаной удачи с этим.
| | |
| |
| 2.11, Вася (??), 13:17, 01/04/2025 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Вот конкретно тут -- работает и работает хорошо.
Первый снапшот -- 10 GB добавилось в репозиторий.
Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB.
Именно так оно у меня годами уже и работает, делая снапшоты по 4 раза в день. При сотнях ГБ сохраняемых данных размер репозитория не сильно больше.
Фрол, такое впечатление что твой коммент вызван травмой от ZFS, а не от пользования restic.
| | |
| |
| 3.21, Фрол (?), 17:23, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
> Первый снапшот -- 10 GB добавилось в репозиторий.
Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB.
Сара пришла домой от врача и жалуется мужу:
- Изя, ты представляешь?! Я десять лет думала, что это оргазм, а оказалось, что это астма!
Так и у тебя.
| | |
| |
| 4.29, OpenEcho (?), 20:10, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Последующие -- только новые или изменённые файлы.
Не совсем так. Измененные **части** файла только, а не весь файл. На виртуалках особенно заметно.
BTW, Пасиб за анекдот :)
| | |
|
| 3.22, Аноним (22), 17:49, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Ты путаешь дедупликацию и инкрементальный бэкап.
Дедупликация -- это когда у тебя один и тот же файл в разных директориях (или в одной, но с разными названиями), например. И вместо того, чтобы все их хранить в архиве, хранится только одна версия. Звучит полезно, но как часто такое нужно? Я единственный кейс могу придумать, когда данные разных пользователей (например фото/видео), почему-то, бэкапятся в один бэкап (что мне уже кажется антипаттерном).
А инкрементальный бэкап просто записывает изменения в оригинальном архиве, а не весь каждый раз -- технология стара как Юникс. Вон, что пишет Гопатыч:
> 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. | | |
| |
| 4.27, Аноним (48), 19:22, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Звучит полезно, но как часто такое нужно?
Очень нужно для файлового бэкапа большого количества одинаковых виртуалок. Штука действительно не очень востребованная на каждом локалхосте (и не локал тоже), и я даже соглашусь, что это костыль, но вот поди ж ты в прошлом году у клиента воспользовался, экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось.
| | |
| |
| 5.30, OpenEcho (?), 20:15, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось.
Не только на виртуалках, если виндовая сетка с folder redirection с раб.станций на сервак, то получится очень даже прилично отсечь дубликаты, бэкапируя сервачило.
Гит репы, тоже самое, когда народ натащил одинаковых зависимостей и у всех по копии
| | |
| |
| 6.31, Аноним (48), 20:34, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Про виндовые сетки не знаю, бог миловал, а вот с гитом пришлось повозиться. Если коротко, то бэкапить гит проще всего гитом через git clone --mirror […] git push --mirror.
| | |
|
|
| 4.32, OpenEcho (?), 20:51, 01/04/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> which introduced the dump and restore utilities
Что то я не припомню чтоб 'dump' был инкрементальным.
тар, да, есть инкременталка, пока не нарвешься на баг который никто не фиксит
| | |
| |
| 5.34, Аноним (34), 21:30, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
 >> which introduced the dump and restore utilities
> Что то я не припомню чтоб 'dump' был инкрементальным.
[CODE]
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.
[/CODE]
Но есть нюанс - как обычно, в пингвичике решили что все это устарело и ненужно, пользуйтесь таром.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511651 (ну и поддержки снапшотов в ext4 тоже нема).
| | |
|
| 4.33, _ (??), 21:06, 01/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>Я единственный кейс могу придумать
Самый оргазм - это образа VM-ок с дедупом бэкапить. Их то _все_ с нескольких шаблонов раскатывают, в результате экономия "чумачечия!"(С) (*)
Для всего остального я профита не нашёл и тупо отключил. :)
(*) голубошляпые пушат как жЫть по-новому, и этот метод фэйзят в "голубой туман" :( А с новым дедуп ничего не даст, дешевле тоже выключить :( Покупайте сторидж спЭйс, больше спэйса! :)))
| | |
| 4.38, Аноним (38), 03:42, 02/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Ничего он не путает. Дедупликация это когда одни и те же (совпадающие) блоки переиспользуются.
А уж используете вы дедупликацию для инкрементальности, для компрессии, или для экономии трафика, уже дело десятое.
| | |
|
|
| 2.41, Аноним (41), 06:19, 02/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
 Ну вот, похоже никто не смог оценить первоапрельскую шутку Фрол-а.
Если серьезно. Дедупликация, к примеру, в zpaq, не просто работает. Она радикально сокращает затраты места при хранении бекапов БД аля sqlite. Т.е. например объем бекапов хомяка юзера, активно использующего мессенджеры вроде Signal или SimpleX.
| | |
| |
| 3.45, Фрол (?), 11:14, 02/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Еще про 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 копируй, там, говорят, экономия места еще выше.
| | |
| |
| 4.46, Аноним (38), 13:08, 02/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Я думаю, что никто в самом деле не будет пытаться "восстановить" что бы то ни было из бэкапа.
Бэкапы это если случайно нужный файл удалил, или система скрашилась с концами. Всё равно скорее всего придётся переустановить систему и разложить файлы из бэкапа по местам вручную.
| | |
| |
| 5.47, Фрол (?), 14:39, 02/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Ну я ж говорю, для таких, как вы, резервное копирование в /dev/null - лучший выбор.
Не всем так везет, с некоторых disaster recovery plan требуют, чтоб под рукой (и желательно км так в 300 от) всегда был актуальный набор медиа, с которого можно за сутки на голом железе развернуть копию ДЦ. Без всяких там переустановок забутстрапиться и развернуть.
| | |
|
| 4.50, Аноним (41), 20:39, 02/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Соглашусь, что написал недостаточно понятно. zpaq был приведен в качестве показательного примера, наглядно демонстрирующего эффективность дедупликации как таковой, при должных настройках. Как универсальное средство бэкапа он естественно не подходит, но может использоваться в составе.
Последнее предложение из предыдущего коммента относилось к бэкапу хомяка restic-ом, в нем эффект от дедупликации тоже заметен.
| | |
|
|
|
| |
| 2.39, Аноним (38), 03:44, 02/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Хакер и солонка это глупая метафора, потому что в столовой есть "бай дизайн", капча. Роботы не едят в столовой.
Если бы в столовой ели роботы, да ещё по 10к заказов в секунду, а в интернете так и есть, то всем сразу стала бы очевидна нелепость аналогии.
| | |
|
| 1.40, Аноним (38), 04:05, 02/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>При сборке образов для GitHub Container Registry учтены рекомендации SLSA (Supply-chain Levels for Software Artifacts).
Балканизация интернета наступает.
| | |
|
