Bareos incremental backup

1. да

2. да

https://en.m.wikipedia.org/wiki/Comparison_of_backup_software

И какая же колонка в этой табличке по-твоему отвечает за эту функцию?

По теме - BareOS этого не умеет, насколько я знаю.

Такая функция обычно есть в энтерпрайз-версиях бэкапного софта, но и там рекомендуют подумать 10 раз, прежде чем ее включать.

И какая же колонка в этой табличке по-твоему отвечает за эту функцию?

Versioning

По теме - BareOS этого не умеет, насколько я знаю.

Вроде умеет, см. Always Incremental Backup Scheme

Такая функция обычно есть в энтерпрайз-версиях бэкапного софта

В платном софте это лучше проработано. Но есть и немало бесплатного софта с таким функционалом (например borg, restic, duplicati).

Но и там рекомендуют подумать 10 раз, прежде чем ее включать.

Буду благодарен, если поделитесь опытом/знаниями/пониманием - в чём риски.

Я, в простых схемах (например: ежемесячный полный бэкап + ежедневные инкрементальные к полному) больших рисков не вижу.

Скорость восстановления? Обычно, не очень критична.

Возможность повреждения промежуточных инкрементов? Если не очень экономить на железе, то маловероятна.

На локалхосте тыкал restic, нраица. Content-addressable storage, лишнего по идее храниться не должно.

Не знаю, конечно, насколько оно готово для энтерпрайза. У отсутствия дублирования есть свои очевидные минусы.

Хотя никто ведь не мешает бэкапить в разные репозитории, организовать их ротацию и все такое прочее.

скорость восстановления зависит от размерами промежуточного бекапа и варианта системы.
вариантов два:

1. диференциальный - промежуточный бекап собирает файлы измененные с полной копии. минус в большем размере пром.бекапа, плюс для восстановления надо распаковать только два архива: полный и дифференциальный.
2. инкрементальный - промежуточный бекап собирает файлы, измененные с прошлого инкрементального бекапа, плюс - меньший размер пром.бекапа, минус для распаковки нужно распаковать полный + все инкрементальные бекапы до необходимого.

инкрементальный при размере современных носителей имхо применяется в исключительно редких случаях.

при современных объемах документации распаковка измененных документов на фоне распаковки полного архива практически незаметна. что тоже не в поддержку инкремента.

тем более никто не будет влезать в бекапы частей файла. для адекватного дифа необходимо знать структуру файла.
без знаний структуры файла бекап части файла становится бессмысленным.

Ему не просто инкрементальный бэкап нужен, который все умеют. Ему нужен инкрементальный бэкап части файла. Дельта-бэкап. Например, в 10GB файле изменились 2 Кб - чтобы только эти 2 Кб и забэкапились.

А большинство СРК тупо бэкапят весь изменившийся файл целиком, включая и BareOS. Для Бакулы есть платный плагин, но это в ее энтепрайз-версии.

Буду благодарен, если поделитесь опытом/знаниями/пониманием - в чём риски.

На курсах по IBM TSM говорили не включать subfile backup, либо делать это очень избирательно. Причины подзабыл, а гуглить лень :)

Хотя это было еще до того, как дедупликация поперла в массы.

Например, в 10GB файле изменились 2 Кб - чтобы только эти 2 Кб и забэкапились.

Именно это и нужно. У пользователей большие файлы и они в документ только одну цифру добавили файл изменился. Как бы не хочет его весь бэкапить они весят по 2Гб и таких файлов очень много

Проверил на restic - так и работает (бэкапится только дельта). Borg, насколько помню, тоже так работает. BareOS - не знаю.

Вы бэкапите компьютеры пользователей или серверы?

https://bugs.bareos.org/view.php?id=295#history

Закрыли с «won’t fix».

Вы бэкапите компьютеры пользователей или серверы?

Бэкапим данные из nextcloud.

У restic или Borg есть веб морда для восстановления файла? Объяснить пользователя как из консоли достать файл очень сложно

Вроде nextcloud сам умел такое в вэбморде. Или вы о чем-то другом?

nextcloud в базовой поставке с versioning бэкапит ЕМНИП весь файл. Можно ли его заставить бэкапить именно diff-ами - не уверен...

Я про «достать старую версию файла». Да, получилось невнятно, надо было цитату вставить.

потому что он работает крайне узколобо и в редких случаях :(
для адекватного subfile backup нужно знать структуру файла или файл должен быть простым, тот же plain text исходников программы для которого можно простыми действиями выявить и запротоколировать изменения.
к примеру изменение нескольких буковок внутри zip-контейнера docx кардинально изменит весь сжатый файл.

к примеру изменение нескольких буковок внутри zip-контейнера docx кардинально изменит весь сжатый файл.

В gzip есть решение при необходимости:

   --rsyncable  
   When you synchronize a compressed file between two computers, this option allows rsync to transfer only files that were changed in the archive  instead  of the entire archive.  Normally, after a change is made to any file in the archive, the compression algorithm can generate a new version of the archive that does not match the previous version of the archive. In this case, rsync transfers the entire new version of the archive to the remote  computer.   With  this option, rsync can transfer only the changed files as well as a small amount of metadata that is required to update the archive structure in the area that was changed.

хых, zip с docx я привел лишь для примера того, что сложный файл простому/тупому дифу поддается крайне редко.

интересно как это реализуется :) для rsync закладываются якоря в сжатый файл ??

интересно как это реализуется :) для rsync закладываются якоря в сжатый файл ??

Очень просто, никаких якорей и какого либо дополнительного кода. Самое распространенное применение для gzip, это gzip single-file. Изменился файл, значит передаем и не парим мозг :)

тут вопрос аккурат про subfile backup «в 10GB файле изменились 2 Кб - чтобы только эти 2 Кб и забэкапились».
по файлово кажный дурак может.

В приведенном вами мане написано:
this option allows rsync to transfer only files that were changed in the archive instead of the entire archive
передается измененный файл целиком.

мной ?? :) чет я вообще не понимаю что с кем на счет чего…

Опаньки, звиняйте :)

У restic или Borg есть веб морда для восстановления файла?

Нет. Более того, это не многопользовательские системы.

Бэкапим данные из nextcloud.

Объяснить пользователя как из консоли достать файл очень сложно

Я вижу некоторые подводные камни в идеи «дать веб-интерфейс управления бэкапами пользователям - пусть сами файлы в nexcloud восстанавливают». Я именно nexcloud не знаю, поэтому пофантазирую, а Вы уже смотрите, так ли это или нет:

• Леночка восстановила поверх текущей версии реестра файл месячной данности. Текущую версию перед этим не сохранила. Все, чем можно помочь - восстановить бэкап, который был сделан прошлой ночью.
• Вася скопировал себе бэкап с файлами руководства (к которым у него, по нормальному, нет доступа)
• метаданные не восстанавливаются вместе с файлами, из-за чего, восстановленный файл месячной давности виден как изменённый сегодня
• пользователям дали доступ, но имена файлов отличаются (например, вместо ‘Договор № 1/12/22 c "ООО «Ромашка».docx’ лежит file0000013213.docx) и пользователи не могут найти то, что им нужно.
• реальная структура файлов отличается от виртуальной, и пользователь, ожидающий увидеть файлы, разложенные по папкам, видит все файлы лежащие в одном месте, и т.д.
• сделали миграцию на объектное хранилище (S3), которое не бэкапится BareOS’ом - а пользователи уже привыкли и просят вернуть удобный инструмент

Я хочу сказать, что нужно использовать встроенное (или доступное через плагин) версионирование - и давать пользователям доступ только к нему, а бэкап - делать самому и пользователям к нему не давать.

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

И восстанавливать они могут только те файлы, к которым у них был доступ, и только туда, куда разрешено в СРК. Все в рамках созданных пермишенов.

Только это масштабы серьезных СРК, а не restic/borg.

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

И восстанавливать они могут только те файлы, к которым у них был доступ, и только туда, куда разрешено в СРК. Все в рамках созданных пермишенов.

Только эти СРК тоже могут не учитывать специфики nextcloud’a. Кстати, есть в теме спецы по nextcloud’у?

Только это масштабы серьезных СРК, а не restic/borg.

А bareos?

NextCloud никогда не видел, но BareOS же справляется…

BareOS внешне похож на коммерческие СРК (архитектурой и тем, что с ленточками умеет работать). Так что по масштабам это почти энтерпрайз.

BareOS внешне похож на коммерческие СРК

Так он же, ЕМНИП, от Бакулы отпочковался.

Прям как и Nextcloud от ownCloud.

Хотя от Bacula ещё и BURP происходит (но всего лишь как хобби).

При архивировании, в принципе, есть два пути: просто файлы по отдельности жать или solid archive. Т.е. пакуя файлы, в зависимости от того имеют ли эти файлы по отдельности какой-то смысл или нет, можно упаковать эффективнее (solid) или чуть менее эффективно, зато с быстрым разархивированием файла. И solid можно по-разному оптимизировать. Предполагаю, что rsyncable - это точно не solid gzip. А zip, вроде, вообще не solid.

открою страшную тайну, в solid-сжатии есть еще третий путь - непрерывно-блочное сжатие, когда весь файл представляет собой не один кусок непрерывного сжатия , а разделен на несколько отдельных блоков непрерывного сжатия. смотри параметры рар и 7зип, ими вполне можно управлять отношением «скорость распаковки»/сжатие.
оптимизировать solid нельзя, у него теже параметры что и у обычного сжатия. можно лишь оптимизировать поток файлов, идущий ему на вход, сортировать к примеру по расширению. опять же смотри параметры рар и 7зип.

с точностью до наоборот - gzip не может не solid :) это труюниксвей сжиматель, внутри gzip может быть только один поток/файл который непрерывно сжат.
мне кааатца, что это какой-то програмный костыль для ублажения алгоритмов rsync с потоком tar.
поиграйся - мож чего выяснишь.

Это я и имел ввиду под оптимизациями (у оптимизаций, в общем, есть разные критерии).

С одной стороны, когда для нескольких файлов перед gzip используется tar, то, да, gzip’у остаётся быть только solid, т.к. ему подаётся на вход просто поток без каких-либо различительных признаков. Но gzip может работать и не в solid режиме (хотя без ручного учёта метаданных с разархивированным будет не разобраться):

  -c  
   ... If there are several input files, the output consists of a sequence of independently compressed members. To obtain better compression, concatenate all input files before compressing them.

   In case of damage to one member of a .gz file, other members can still be recovered (if the damaged member is removed). However, you can get better compression by compressing all members at once:  

        cat file1 file2 | gzip > foo.gz  

  compresses better than  

        gzip -c file1 file2 > foo.gz

Нагуглил:

How does gzip –rsyncable work from a technical perspective? (06.08.2021) –> Rsyncable gzip (03.02.2005) –> About integration of rsync and Debian (14.05.2002)

gzip, like most compression algorithms has the property that a change in the source file at one point will cause cascading changes in the output file from that point onwards, and therefore make delta compression more or less useless.
[cut]
There is a patch called –rsyncable for gzip that fixes this behaviour: gzip files are basically broken up into blocks so that changes (including insertion or deletion) in the input file affect only the corresponding blocks in the output file. (The blocks are not of fixed size, but rather delimited by marker patterns at which a checksum hits a particular value, so they move as data is inserted or removed.)

я так понимаю то же самое блочное-непрерывное сжатие - т.е. внутри gzip-потока несколько отдельных кусков сжатия - океюшки :) теоретически интересно, практически применяется… наверное нигде…
во многих инструментах есть интересные задумки, которые так и не стали никому интресны в плане применения.
п.с.: давно уж и от tar и gzip отошел.

в плане вопроса темы все равно ничего не дает.

Dmit84 (чтото вспомнилось) а пробовал для выявления измененной части файла использовать имеющиеся програмки двоичных патчей ??
bsdiff bin_diff jojodiff xdelta