Много лет уже пользуюсь для резервного копирования диска Цэ c windows программой Veeam Agent (бесплатная для домашнего использования версия, есть версия и для других ОС).
Вообще у Veeam четыре “места назначения” для резервных копий, но в бесплатной лицензии доступно, по сути, только две: На локальный жесткий диск (другой) или на сетевую папку (NFS?).
Суть вопроса вот в чем:
Механизм работы программы основан на создании “базового архива” (полная копия) и несколько инкрементальных архивов к нему. То есть сегодня первый раз запустили резервное копирование диска Цэ и в эту копию попал весь диск Цэ. Завтра создастся уже небольшой файл, в который войдет только то, что изменилось на диске на уровне блоков с последнего копирования и так далее.
Допустим я ограничиваю (для примера) максимально возможную дату “откатиться” в пять дней. На шестой день создастся шестой файл только изменений, а первый файл изменений “интегрируется” в общий (самый первый) архив и таким образом опять будет только пять вариантов версий ОС. Причем даже если файл самого первого (полного архива) был 80Гб, а инкрементальная копия в 7Гб - “сращивание” файлов происходит очень быстро и ( ! ) самое главное - даже на сетевой папке со скоростью сети в 10Мб/с.
Само “сращивание”, как мне кажется, достаточно очевидно. Интересно, что “очень быстро”. Но т.к. никаких цифр не приведено, то что означает это “очень быстро”, непонятно.
В свое время пользовался разными, в том числе и платными инструментами для резервного копирования, но всегда угнетала именно низкая скорость их работы, особенно по сети.
служба VeeamAgent следит за дисковыми операциями, запоминает что изменилось и эти изменения записывает в инкрементную часть бэкапа. При необходимости достать из архива нужный файл из нужной даты, берет full бэкап и последовательно на него накатывает все изменения из инкрементных кусочков.
2.2 ГБ за 5 минут, очень даже похоже на ваши 7 Гб за 15 минут.
А медленно по сети банально потому, что VeeamAgent не может по частям писать сетефой файл, ну нет такого функционала в SMB протоколе.
Вот и получается, когда все это на локальной машине, агент может читать/записывать по частям файлы. А по сети только целиковые.
я слышу в первый раз в жизни, то могу лишь предположить, как это может происходить:
например, так: берется сохраненная дата из последней резервной записи и после этого архивируется все то, что позже этой даты.
Другой вариант: тем или иным способом подсчитываются контрольные коды для файлов/каталогов и архивируется то, у чего эти контрольные коды не совпали.
Veeam Agent оперирует блоками, на сколько я понимаю.
Меня не механизм организации резервной копии интересует, а механизм модификации файла Full Backup.
Как я выше писал, предполагаю что нечто подобное используется при работе 1С с файловой БД, расположенной в сетевой папке. Там же бывает файл БД более 10Гб, а скорость работы (применение изменений в файле) достаточно высокая на медленном LAN. Хотя могу и ошибаться…
Ну, рассуждая логически, самый простой способ - Full Backup есть просто архив со всеми файлами. Инкрементный бэкап есть архив, куда входят только новые и измененные файлы. Слияние - просто добавление файлов из инкремента в Full Backup с заменой имеющихся. А уж как это реализуется в Veeam Agent - это только разработчикам известно ))
Мне так кажется, что там ни какого сращивания не происходит. При первом бэкапе, создаётся внутренняя таблица адресов расположения файлов. Это основа бэкапа. Далее, в следующую дату, идёт проверка изменения размера конкретного файла (ну или к примеру даты создания, она же будет новая при изменении). Таким образом находятся все изменённые файлы и новые, и только они входят в следующий маленький бэкап и меняется при этом опять внутренняя таблица адресов. При восстановлении процесс обратный согласно таблице адресов расположения. По этому, скорость создания следующих бэкапов будет зависить только от колличества сканируемых файлов + скорости записи новых и изменённых файлов.
Если речь про виндовую софтину, то в винде у файлов имеется архивный атрибут, который присваивается каждому файлу при его создании или изменении. Таким образом когда создается полный архив, у всех файлов этот атрибут снимается (самим “архиватором”). При создании инкрементных архивов выбираются только файлы, у которых этот атрибут присутствует, архивируются, атрибут снимается. И так далее. Самый простой способ.
ЗЫ: я так делал, когда писал синхронизатор локальной копии сайта с сервером - после первой полной загрузки в последующем загружались только файлы с архивным атрибутом.
вы разве никогда не видели основного бекапа и инкрементов к нему? - Обычно это независимые файлы, скажем основной бекап создается 11 сентября И БОЛЬШЕ НЕ МЕНЯЕТСЯ, а далее 12-ого, 13-ого, 14-ого сохраняются только файлы изменений, не затрагивая основной файл.
Ваша система необычна тем, что основной архив имеет дату изменения последней архивации… интересно посмотреть, как меняется размер основного файла… может система просто пристегивает к нему файл изменений, а не встраивает их в изначальный архив…
я бы даже добавил, что “встраивание” последних изменений в основной файл маловероятно, потому что тогда не ясно, зачем хранить эти изменения отдельно и еще… это нарушало бы историю архивации и затрудняло бы извлечения “слепка” файловой системы, скажем, за 12 число
Не последних изменений, а изменений сверх возможной даты “отката”.
То есть если смотреть на мой скриншот:
Завтра будет создан файл инкремента с датой 20.09.2023, а в основной файл (71Гб) будет “интегрирован” файл бэкапа от 11.09.2023г (6.8Гб). И таким образом “точек отката” останется тоже количество.
Размер основного файла изменяется, но не постоянно растет, а то прибавляется, то убавляется. Но всегда примерно 71Гб (у меня).
