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

"Выпуск системы резервного копирования 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.ru/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

Да господи, дедупликация не работает И никогда не работала Все, что делает дед, Фрол (?), 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. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." –3 +/–

Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 11:00

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

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

5. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." +2 +/–

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

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

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

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

Сообщение от 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ообщить модератору

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

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

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

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

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

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

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

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

6. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." –2 +/–

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

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

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

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

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

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

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

17. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." +3 +/–

Сообщение от Krtek (?), 01-Апр-25, 14:43

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

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

43. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." +1 +/–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

42. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." –1 +/–

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

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

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

7. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." –2 +/–

Сообщение от Фрол (?), 01-Апр-25, 12:26

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

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

11. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." +3 +/–

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

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

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

12. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." +1 +/–

Сообщение от YetAnotherOnanym (ok), 01-Апр-25, 13:49

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

32. "Выпуск системы резервного копирования Restic 0.18. Атака на ..." –1 +/–

Сообщение от OpenEcho (?), 01-Апр-25, 20:51

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

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

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

Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Фрол (?), 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ообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Партнёры:

Хостинг:

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

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

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

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


	28. "Выпуск системы резервного копирования Restic 0.18. Атака на ..."	+/–
	Сообщение от 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ообщить модератору


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


	49. "Выпуск системы резервного копирования Restic 0.18. Атака на ..."	+/–
	Сообщение от penetrator (?), 02-Апр-25, 17:05
	вот ссылка на полный текст https://github.com/borgbackup/borg/wiki/CDC-issues-reported-... если засунуть в AI чат то он переведет вполне сносно, и может даже объяснит если понадобится
	Ответить \| Правка \| Наверх \| Cообщить модератору

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


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


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


	43. "Выпуск системы резервного копирования Restic 0.18. Атака на ..."	+1 +/–
	Сообщение от Аноним (43), 02-Апр-25, 08:36
	> плюс крон вместо таймеров системд пару раз этот системд таймер не сработал без ошибок был крайне удивлен
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	48. "Выпуск системы резервного копирования Restic 0.18. Атака на ..."	+/–
	Сообщение от Аноним (48), 02-Апр-25, 16:26
	Ссылку на баг забыл приложить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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

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


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


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


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


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


	22. "Выпуск системы резервного копирования Restic 0.18. Атака на ..."	+/–
	Сообщение от Аноним (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.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


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


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


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


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


	34. "Выпуск системы резервного копирования Restic 0.18. Атака на ..."	+/–
	Сообщение от Аноним (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ообщить модератору


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


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


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


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