forum.opennet.ru - "Выпуск системы резервного копирования Restic 0.18. Атака на CDC" (39)

"Выпуск системы резервного копирования Restic 0.18. Атака на CDC"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск системы резервного копирования Restic 0.18. Атака на CDC"	+/–
Сообщение от opennews (ok), 01-Апр-25, 10:17
Представлен выпуск системы резервного копирования Restic 0.18, позволяющей хранить резервные копии в зашифрованном виде в версионированном репозитории с поддержкой дедупликации. Система изначально рассчитана на то, что резервные копии сохраняются в окружениях не заслуживающих доверия, и попадание резервной копии в чужие руки не должно скомпрометировать систему. При создании резервной копии возможно определение гибких правил для включения и исключения файлов и каталогов (формат правил напоминает rsync или gitignore). Поддерживается работа в Linux, macOS, Windows и BSD-системах. Код проекта написан на языке Go и распространяется под лицензией BSD... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62996
Ответить \| Правка \| Cообщить модератору

Оглавление

Вот сюрпрайз-то какой Надо в каждый дублирующийся фрагмент добавлять соль, чтоб, YetAnotherOnanym (ok), 11:00 , 01-Апр-25, (4) –3
Дедупликация исключает возможность блокирования определения файла в хранилище Х, Аноним (5), 11:39 , 01-Апр-25, (5) +2

нети в борге уже сделали это давноthe chunk size fingerprinting attack is not ne, penetrator (?), 19:29 , 01-Апр-25, (28)

Возможно, я не очень хорошо знаю английский, но кажется в том, что вы процитиров, Аноним (5), 21:53 , 01-Апр-25, (37)

вот ссылка на полный текстhttps github com borgbackup borg wiki CDC-issues-rep, penetrator (?), 17:05 , 02-Апр-25, (49)

Только tar и ssh По многим причинам эта парочка превосходит любые другие вариан, Аноним (6), 12:12 , 01-Апр-25, (6) –2

Плюс башпортянка, плюс крон вместо таймеров системд даже если системд уже устан, Аноним (8), 12:32 , 01-Апр-25, (8)

Какой софт, такая и степень доверия, уж извините , Krtek (?), 14:43 , 01-Апр-25, (17) +3
пару раз этот системд таймер не сработал без ошибокбыл крайне удивлен, Аноним (43), 08:36 , 02-Апр-25, (43) +1

Ссылку на баг забыл приложить , Аноним (48), 16:26 , 02-Апр-25, (48)

Для подкроватного сервака сойдет, Аноним (9), 12:38 , 01-Апр-25, (9)

А для кладовочного, для балконного , Аноним (10), 12:49 , 01-Апр-25, (10)

tar ssh в качестве бэкапа и для этих подойдет, Аноним (9), 14:43 , 01-Апр-25, (18)

И как там с инкрементальным, на 20 летний баг не нарывались еще , OpenEcho (?), 21:32 , 01-Апр-25, (35)
Только zfs send receive и ssh , Илья (??), 06:40 , 02-Апр-25, (42) –1
Да И еще rsync , abu (?), 12:18 , 03-Апр-25, (51)

Да господи, дедупликация не работает И никогда не работала Все, что делает дед, Фрол (?), 12:26 , 01-Апр-25, (7) –2

Вот конкретно тут -- работает и работает хорошо Первый снапшот -- 10 GB добавило, Вася (??), 13:17 , 01-Апр-25, (11) +3

У тебя дедупликация и инкрементальное резервирование - это одно и то же , YetAnotherOnanym (ok), 13:49 , 01-Апр-25, (12) +1
Последующие -- только новые или изменённые файлы Т е репозиторий увеличится не, Фрол (?), 17:23 , 01-Апр-25, (21)

Не совсем так Измененные части файла только, а не весь файл На виртуалках , OpenEcho (?), 20:10 , 01-Апр-25, (29)

Ты путаешь дедупликацию и инкрементальный бэкап Дедупликация -- это когда у тебя, Аноним (22), 17:49 , 01-Апр-25, (22)

Очень нужно для файлового бэкапа большого количества одинаковых виртуалок Штука, Аноним (48), 19:22 , 01-Апр-25, (27)

Не только на виртуалках, если виндовая сетка с folder redirection с раб станций , OpenEcho (?), 20:15 , 01-Апр-25, (30)

Про виндовые сетки не знаю, бог миловал, а вот с гитом пришлось повозиться Если, Аноним (48), 20:34 , 01-Апр-25, (31)

Что то я не припомню чтоб dump был инкрементальным тар, да, есть инкременталк, OpenEcho (?), 20:51 , 01-Апр-25, (32) –1

CODE The following options are supported by dump -0-9 Dump levels A l, Аноним (34), 21:30 , 01-Апр-25, (34)

О блин, сорян , с fsarchiver перепутал нет уж спасибо, наступали уже https , OpenEcho (?), 21:42 , 01-Апр-25, (36)

Самый оргазм - это образа VM-ок с дедупом бэкапить Их то _все_ с нескольких шаб, _ (??), 21:06 , 01-Апр-25, (33)
Ничего он не путает Дедупликация это когда одни и те же совпадающие блоки пер, Аноним (38), 03:42 , 02-Апр-25, (38)

Ну вот, похоже никто не смог оценить первоапрельскую шутку Фрол-а Если серьезно , Аноним (41), 06:19 , 02-Апр-25, (41)

Еще про rsync ыспомни, как средство резервного копирования Из мануала zpaqОтличн, Фрол (?), 11:14 , 02-Апр-25, (45)

Я думаю, что никто в самом деле не будет пытаться восстановить что бы то ни бы, Аноним (38), 13:08 , 02-Апр-25, (46)

Ну я ж говорю, для таких, как вы, резервное копирование в dev null - лучший выб, Фрол (?), 14:39 , 02-Апр-25, (47)

Соглашусь, что написал недостаточно понятно zpaq был приведен в качестве показа, Аноним (41), 20:39 , 02-Апр-25, (50)

Хакер и солонка , Витюшка (?), 18:32 , 01-Апр-25, (24)

Хакер и солонка это глупая метафора, потому что в столовой есть бай дизайн , ка, Аноним (38), 03:44 , 02-Апр-25, (39)

Версия 2 0 Хакер и розетка , Аноним (44), 08:47 , 02-Апр-25, (44)

Балканизация интернета наступает , Аноним (38), 04:05 , 02-Апр-25, (40)

Сообщения [Сортировка по ответам | RSS]

4. Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 11:00 –3 +/–

> в системах, использующих дедупликацию, при наличии возможности добавлять свои файлы в резервную копию можно поступить проще и определить наличие интересующих файлов косвенным путём. После добавления проверяемого файла можно оценить изменение размера хранилища - если файл уже имеется в хранилище, то его повторное добавление из-за дедупликации не приведёт к должному увеличению размера
Вот сюрпрайз-то какой! Надо в каждый дублирующийся фрагмент добавлять соль, чтобы он отличался от других и при шифровании не совпадал с уже имеющимися. Это очень эффективная система дедупликации.

Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Аноним (5), 01-Апр-25, 11:39 +2 +/–

Дедупликация исключает возможность блокирования определения файла в хранилище. Хочешь больше безопасности - отключай дедупликацию и плати за место.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

6. Сообщение от Аноним (6), 01-Апр-25, 12:12 –2 +/–

Только tar и ssh. По многим причинам эта парочка превосходит любые другие варианты.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #9, #35, #42, #51

7. Сообщение от Фрол (?), 01-Апр-25, 12:26 –2 +/–

Да господи, дедупликация не работает.
И никогда не работала.
Все, что делает дедупликация - поднимает CPU и роняет io + память.
Выигрыша по обьему нет.
Это по опыту эксплуатации как блочных так и объектных хранилок
И уж совсем хороша дедупликация на лентах, хорошей обаной удачи с этим.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #41

8. Сообщение от Аноним (8), 01-Апр-25, 12:32 +/–

Плюс башпортянка, плюс крон вместо таймеров системд (даже если системд уже установлен).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #17, #43

9. Сообщение от Аноним (9), 01-Апр-25, 12:38 +/–

Для подкроватного сервака сойдет

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #10

10. Сообщение от Аноним (10), 01-Апр-25, 12:49 +/–

А для кладовочного, для балконного?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #18

11. Сообщение от Вася (??), 01-Апр-25, 13:17 +3 +/–

Вот конкретно тут -- работает и работает хорошо.
Первый снапшот -- 10 GB добавилось в репозиторий.
Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB.
Именно так оно у меня годами уже и работает, делая снапшоты по 4 раза в день. При сотнях ГБ сохраняемых данных размер репозитория не сильно больше.
Фрол, такое впечатление что твой коммент вызван травмой от ZFS, а не от пользования restic.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #12, #21, #22

12. Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 13:49 +1 +/–

У тебя дедупликация и инкрементальное резервирование - это одно и то же?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

17. Сообщение от Krtek (?), 01-Апр-25, 14:43 +3 +/–

Какой софт, такая и степень доверия, уж извините.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

18. Сообщение от Аноним (9), 01-Апр-25, 14:43 +/–

tar + ssh в качестве бэкапа и для этих подойдет

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

21. Сообщение от Фрол (?), 01-Апр-25, 17:23 +/–

> Первый снапшот -- 10 GB добавилось в репозиторий.
Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB.
Сара пришла домой от врача и жалуется мужу:
- Изя, ты представляешь?! Я десять лет думала, что это оргазм, а оказалось, что это астма!
Так и у тебя.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #29

22. Сообщение от Аноним (22), 01-Апр-25, 17:49 +/–

Ты путаешь дедупликацию и инкрементальный бэкап.
Дедупликация -- это когда у тебя один и тот же файл в разных директориях (или в одной, но с разными названиями), например. И вместо того, чтобы все их хранить в архиве, хранится только одна версия. Звучит полезно, но как часто такое нужно? Я единственный кейс могу придумать, когда данные разных пользователей (например фото/видео), почему-то, бэкапятся в один бэкап (что мне уже кажется антипаттерном).
А инкрементальный бэкап просто записывает изменения в оригинальном архиве, а не весь каждый раз -- технология стара как Юникс. Вон, что пишет Гопатыч:
> 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.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #27, #32, #33, #38

24. Сообщение от Витюшка (?), 01-Апр-25, 18:32 +/–

Хакер и солонка.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

27. Сообщение от Аноним (48), 01-Апр-25, 19:22 +/–

> Звучит полезно, но как часто такое нужно?
Очень нужно для файлового бэкапа большого количества одинаковых виртуалок. Штука действительно не очень востребованная на каждом локалхосте (и не локал тоже), и я даже соглашусь, что это костыль, но вот поди ж ты в прошлом году у клиента воспользовался, экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30

28. Сообщение от penetrator (?), 01-Апр-25, 19:29 +/–

нет
и в борге уже сделали это давно
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.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #37

29. Сообщение от OpenEcho (?), 01-Апр-25, 20:10 +/–

> Последующие -- только новые или изменённые файлы.
Не совсем так. Измененные **части** файла только, а не весь файл. На виртуалках особенно заметно.
BTW, Пасиб за анекдот :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

30. Сообщение от OpenEcho (?), 01-Апр-25, 20:15 +/–

> экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось.
Не только на виртуалках, если виндовая сетка с folder redirection с раб.станций на сервак, то получится очень даже прилично отсечь дубликаты, бэкапируя сервачило.
Гит репы, тоже самое, когда народ натащил одинаковых зависимостей и у всех по копии

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #31

31. Сообщение от Аноним (48), 01-Апр-25, 20:34 +/–

Про виндовые сетки не знаю, бог миловал, а вот с гитом пришлось повозиться. Если коротко, то бэкапить гит проще всего гитом через git clone --mirror […] git push --mirror.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от OpenEcho (?), 01-Апр-25, 20:51 –1 +/–

> which introduced the dump and restore utilities
Что то я не припомню чтоб `dump` был инкрементальным.
тар, да, есть инкременталка, пока не нарвешься на баг который никто не фиксит

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #34

33. Сообщение от _ (??), 01-Апр-25, 21:06 +/–

>Я единственный кейс могу придумать
Самый оргазм - это образа VM-ок с дедупом бэкапить. Их то _все_ с нескольких шаблонов раскатывают, в результате экономия "чумачечия!"(С) (*)
Для всего остального я профита не нашёл и тупо отключил. :)
(*) голубошляпые пушат как жЫть по-новому, и этот метод фэйзят в "голубой туман" :( А с новым дедуп ничего не даст, дешевле тоже выключить :( Покупайте сторидж спЭйс, больше спэйса! :)))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

34. Сообщение от Аноним (34), 01-Апр-25, 21:30 +/–

>> 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 тоже нема).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #36

35. Сообщение от OpenEcho (?), 01-Апр-25, 21:32 +/–

> Только tar и ssh.
И как там с инкрементальным, на 20 летний баг не нарывались еще?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

36. Сообщение от OpenEcho (?), 01-Апр-25, 21:42 +/–

> The following options are supported by dump:
О блин, сорян , с fsarchiver перепутал...
> пользуйтесь таром.
нет уж спасибо, наступали уже...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648048

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

37. Сообщение от Аноним (5), 01-Апр-25, 21:53 +/–

Возможно, я не очень хорошо знаю английский, но кажется в том, что вы процитировали, присутствует только самохвальная болтавня, без объяснения сути, как они сделали. И в конце дописка, что включение добавляет накладные расходы на дисковое пространство, и по этому, по умолчанию не включено.
И раз уж вы так безапелляционно заявляете, что так можно, то не могли бы вы своими словами по-русски объяснить, как именно?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #49

38. Сообщение от Аноним (38), 02-Апр-25, 03:42 +/–

Ничего он не путает. Дедупликация это когда одни и те же (совпадающие) блоки переиспользуются.
А уж используете вы дедупликацию для инкрементальности, для компрессии, или для экономии трафика, уже дело десятое.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

39. Сообщение от Аноним (38), 02-Апр-25, 03:44 +/–

Хакер и солонка это глупая метафора, потому что в столовой есть "бай дизайн", капча. Роботы не едят в столовой.
Если бы в столовой ели роботы, да ещё по 10к заказов в секунду, а в интернете так и есть, то всем сразу стала бы очевидна нелепость аналогии.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #44

40. Сообщение от Аноним (38), 02-Апр-25, 04:05 +/–

>При сборке образов для GitHub Container Registry учтены рекомендации SLSA (Supply-chain Levels for Software Artifacts).
Балканизация интернета наступает.

Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от Аноним (41), 02-Апр-25, 06:19 +/–

Ну вот, похоже никто не смог оценить первоапрельскую шутку Фрол-а.
Если серьезно. Дедупликация, к примеру, в zpaq, не просто работает. Она радикально сокращает затраты места при хранении бекапов БД аля sqlite. Т.е. например объем бекапов хомяка юзера, активно использующего мессенджеры вроде Signal или SimpleX.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #45

42. Сообщение от Илья (??), 02-Апр-25, 06:40 –1 +/–

Только zfs send/receive и ssh!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

43. Сообщение от Аноним (43), 02-Апр-25, 08:36 +1 +/–

> плюс крон вместо таймеров системд
пару раз этот системд таймер не сработал без ошибок
был крайне удивлен

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #48

44. Сообщение от Аноним (44), 02-Апр-25, 08:47 +/–

> Роботы не едят в столовой
Версия 2.0: Хакер и розетка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

45. Сообщение от Фрол (?), 02-Апр-25, 11:14 +/–

Еще про 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 копируй, там, говорят, экономия места еще выше.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #46, #50

46. Сообщение от Аноним (38), 02-Апр-25, 13:08 +/–

Я думаю, что никто в самом деле не будет пытаться "восстановить" что бы то ни было из бэкапа.
Бэкапы это если случайно нужный файл удалил, или система скрашилась с концами. Всё равно скорее всего придётся переустановить систему и разложить файлы из бэкапа по местам вручную.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #47

47. Сообщение от Фрол (?), 02-Апр-25, 14:39 +/–

Ну я ж говорю, для таких, как вы, резервное копирование в /dev/null - лучший выбор.
Не всем так везет, с некоторых disaster recovery plan требуют, чтоб под рукой (и желательно км так в 300 от) всегда был актуальный набор медиа, с которого можно за сутки на голом железе развернуть копию ДЦ. Без всяких там переустановок забутстрапиться и развернуть.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

48. Сообщение от Аноним (48), 02-Апр-25, 16:26 +/–

Ссылку на баг забыл приложить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

49. Сообщение от penetrator (?), 02-Апр-25, 17:05 +/–

вот ссылка на полный текст
https://github.com/borgbackup/borg/wiki/CDC-issues-reported-...
если засунуть в AI чат то он переведет вполне сносно, и может даже объяснит если понадобится

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

50. Сообщение от Аноним (41), 02-Апр-25, 20:39 +/–

Соглашусь, что написал недостаточно понятно. zpaq был приведен в качестве показательного примера, наглядно демонстрирующего эффективность дедупликации как таковой, при должных настройках. Как универсальное средство бэкапа он естественно не подходит, но может использоваться в составе.
Последнее предложение из предыдущего коммента относилось к бэкапу хомяка restic-ом, в нем эффект от дедупликации тоже заметен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

51. Сообщение от abu (?), 03-Апр-25, 12:18 +/–

Да. И еще rsync.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

4. Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 11:00	–3 +/–
> в системах, использующих дедупликацию, при наличии возможности добавлять свои файлы в резервную копию можно поступить проще и определить наличие интересующих файлов косвенным путём. После добавления проверяемого файла можно оценить изменение размера хранилища - если файл уже имеется в хранилище, то его повторное добавление из-за дедупликации не приведёт к должному увеличению размера Вот сюрпрайз-то какой! Надо в каждый дублирующийся фрагмент добавлять соль, чтобы он отличался от других и при шифровании не совпадал с уже имеющимися. Это очень эффективная система дедупликации.
Ответить \| Правка \| Наверх \| Cообщить модератору

5. Сообщение от Аноним (5), 01-Апр-25, 11:39	+2 +/–
Дедупликация исключает возможность блокирования определения файла в хранилище. Хочешь больше безопасности - отключай дедупликацию и плати за место.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #28

6. Сообщение от Аноним (6), 01-Апр-25, 12:12	–2 +/–
Только tar и ssh. По многим причинам эта парочка превосходит любые другие варианты.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #8, #9, #35, #42, #51

7. Сообщение от Фрол (?), 01-Апр-25, 12:26	–2 +/–
Да господи, дедупликация не работает. И никогда не работала. Все, что делает дедупликация - поднимает CPU и роняет io + память. Выигрыша по обьему нет. Это по опыту эксплуатации как блочных так и объектных хранилок И уж совсем хороша дедупликация на лентах, хорошей обаной удачи с этим.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #11, #41

8. Сообщение от Аноним (8), 01-Апр-25, 12:32	+/–
Плюс башпортянка, плюс крон вместо таймеров системд (даже если системд уже установлен).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #17, #43

9. Сообщение от Аноним (9), 01-Апр-25, 12:38	+/–
Для подкроватного сервака сойдет
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #10

10. Сообщение от Аноним (10), 01-Апр-25, 12:49	+/–
А для кладовочного, для балконного?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #18

11. Сообщение от Вася (??), 01-Апр-25, 13:17	+3 +/–
Вот конкретно тут -- работает и работает хорошо. Первый снапшот -- 10 GB добавилось в репозиторий. Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB. Именно так оно у меня годами уже и работает, делая снапшоты по 4 раза в день. При сотнях ГБ сохраняемых данных размер репозитория не сильно больше. Фрол, такое впечатление что твой коммент вызван травмой от ZFS, а не от пользования restic.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #12, #21, #22

12. Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 13:49	+1 +/–
У тебя дедупликация и инкрементальное резервирование - это одно и то же?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

17. Сообщение от Krtek (?), 01-Апр-25, 14:43	+3 +/–
Какой софт, такая и степень доверия, уж извините.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

18. Сообщение от Аноним (9), 01-Апр-25, 14:43	+/–
tar + ssh в качестве бэкапа и для этих подойдет
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

21. Сообщение от Фрол (?), 01-Апр-25, 17:23	+/–
> Первый снапшот -- 10 GB добавилось в репозиторий. Последующие -- только новые или изменённые файлы. Т.е. репозиторий увеличится не ещё на 10GB, а на скажем 100MB. Сара пришла домой от врача и жалуется мужу: - Изя, ты представляешь?! Я десять лет думала, что это оргазм, а оказалось, что это астма! Так и у тебя.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #29

22. Сообщение от Аноним (22), 01-Апр-25, 17:49	+/–
Ты путаешь дедупликацию и инкрементальный бэкап. Дедупликация -- это когда у тебя один и тот же файл в разных директориях (или в одной, но с разными названиями), например. И вместо того, чтобы все их хранить в архиве, хранится только одна версия. Звучит полезно, но как часто такое нужно? Я единственный кейс могу придумать, когда данные разных пользователей (например фото/видео), почему-то, бэкапятся в один бэкап (что мне уже кажется антипаттерном). А инкрементальный бэкап просто записывает изменения в оригинальном архиве, а не весь каждый раз -- технология стара как Юникс. Вон, что пишет Гопатыч: > 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.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #27, #32, #33, #38

24. Сообщение от Витюшка (?), 01-Апр-25, 18:32	+/–
Хакер и солонка.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #39

27. Сообщение от Аноним (48), 01-Апр-25, 19:22	+/–
> Звучит полезно, но как часто такое нужно? Очень нужно для файлового бэкапа большого количества одинаковых виртуалок. Штука действительно не очень востребованная на каждом локалхосте (и не локал тоже), и я даже соглашусь, что это костыль, но вот поди ж ты в прошлом году у клиента воспользовался, экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22 Ответы: #30

28. Сообщение от penetrator (?), 01-Апр-25, 19:29	+/–
нет и в борге уже сделали это давно 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.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #37

29. Сообщение от OpenEcho (?), 01-Апр-25, 20:10	+/–
> Последующие -- только новые или изменённые файлы. Не совсем так. Измененные части файла только, а не весь файл. На виртуалках особенно заметно. BTW, Пасиб за анекдот :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21

30. Сообщение от OpenEcho (?), 01-Апр-25, 20:15	+/–
> экономия вышла значительная, порядка 300ГБ таким образом дедуплицировалось. Не только на виртуалках, если виндовая сетка с folder redirection с раб.станций на сервак, то получится очень даже прилично отсечь дубликаты, бэкапируя сервачило. Гит репы, тоже самое, когда народ натащил одинаковых зависимостей и у всех по копии
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27 Ответы: #31

31. Сообщение от Аноним (48), 01-Апр-25, 20:34	+/–
Про виндовые сетки не знаю, бог миловал, а вот с гитом пришлось повозиться. Если коротко, то бэкапить гит проще всего гитом через git clone --mirror […] git push --mirror.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #30

32. Сообщение от OpenEcho (?), 01-Апр-25, 20:51	–1 +/–
> which introduced the dump and restore utilities Что то я не припомню чтоб `dump` был инкрементальным. тар, да, есть инкременталка, пока не нарвешься на баг который никто не фиксит
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22 Ответы: #34

33. Сообщение от _ (??), 01-Апр-25, 21:06	+/–
>Я единственный кейс могу придумать Самый оргазм - это образа VM-ок с дедупом бэкапить. Их то _все_ с нескольких шаблонов раскатывают, в результате экономия "чумачечия!"(С) () Для всего остального я профита не нашёл и тупо отключил. :) () голубошляпые пушат как жЫть по-новому, и этот метод фэйзят в "голубой туман" :( А с новым дедуп ничего не даст, дешевле тоже выключить :( Покупайте сторидж спЭйс, больше спэйса! :)))
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22

34. Сообщение от Аноним (34), 01-Апр-25, 21:30	+/–
>> 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 тоже нема).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #32 Ответы: #36

35. Сообщение от OpenEcho (?), 01-Апр-25, 21:32	+/–
> Только tar и ssh. И как там с инкрементальным, на 20 летний баг не нарывались еще?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

36. Сообщение от OpenEcho (?), 01-Апр-25, 21:42	+/–
> The following options are supported by dump: О блин, сорян , с fsarchiver перепутал... > пользуйтесь таром. нет уж спасибо, наступали уже... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648048
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #34

37. Сообщение от Аноним (5), 01-Апр-25, 21:53	+/–
Возможно, я не очень хорошо знаю английский, но кажется в том, что вы процитировали, присутствует только самохвальная болтавня, без объяснения сути, как они сделали. И в конце дописка, что включение добавляет накладные расходы на дисковое пространство, и по этому, по умолчанию не включено. И раз уж вы так безапелляционно заявляете, что так можно, то не могли бы вы своими словами по-русски объяснить, как именно?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #28 Ответы: #49

38. Сообщение от Аноним (38), 02-Апр-25, 03:42	+/–
Ничего он не путает. Дедупликация это когда одни и те же (совпадающие) блоки переиспользуются. А уж используете вы дедупликацию для инкрементальности, для компрессии, или для экономии трафика, уже дело десятое.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22

39. Сообщение от Аноним (38), 02-Апр-25, 03:44	+/–
Хакер и солонка это глупая метафора, потому что в столовой есть "бай дизайн", капча. Роботы не едят в столовой. Если бы в столовой ели роботы, да ещё по 10к заказов в секунду, а в интернете так и есть, то всем сразу стала бы очевидна нелепость аналогии.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #44

40. Сообщение от Аноним (38), 02-Апр-25, 04:05	+/–
>При сборке образов для GitHub Container Registry учтены рекомендации SLSA (Supply-chain Levels for Software Artifacts). Балканизация интернета наступает.
Ответить \| Правка \| Наверх \| Cообщить модератору

41. Сообщение от Аноним (41), 02-Апр-25, 06:19	+/–
Ну вот, похоже никто не смог оценить первоапрельскую шутку Фрол-а. Если серьезно. Дедупликация, к примеру, в zpaq, не просто работает. Она радикально сокращает затраты места при хранении бекапов БД аля sqlite. Т.е. например объем бекапов хомяка юзера, активно использующего мессенджеры вроде Signal или SimpleX.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #45

42. Сообщение от Илья (??), 02-Апр-25, 06:40	–1 +/–
Только zfs send/receive и ssh!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6