Реализация блочного копирования большого файла?

Question

[Kentaurus13]

Добрый вечер.
я делаю бекап файлового сервера средствами Veeam Endpoint Backup, на выходе получаю большой файл .vbk(чуть больше 2Тб) и какое-то количество маленьких файлов .vib на отдельном диске файлового сервера.
Хотелось бы копировать эти файлы на NAS и второй сервер.
На текущий момент копирование реализовано средствами robocopy
Проблема в том, что каждый раз при создании полного синтетического бекапа приходится целиком перекачивать большой файл .vbk

Есть ли средства блочного копирования данного файла(копировать только обновленные части файла)?
Первое что приходит на ум - DFS, но там довольно большие накладные расходы на VSS(во всяком случае были в 2008R2, может что-то поменялось?) и её нельзя подружить с NAS.

Есть ли какие-то решения данной задачи?
Заранее спасибо.

Comments

[Владимир Мартьянов]

Вы хотите инкрементный бэкап, судя по всему. Поищите по этому термину, может найдется что-то под вашу задачу.

Answer 1

[Виталий Пухов]

Вообще есть, но есть ли гарантия того что к примеру не произшло "смещение" в каком ни будь заголовке файла, которое сводит "на нет" всю идею блочного копирования. Писал подобное приложение когда после скачивания GTA 5 со стороннего сервера (с моим интернетом ушло больше недели) оказалось, что какие то файлы повреждены (вероятно отключем света во время загрузки), перекачивать конечно не вариант, пришлось химичать. То же самое приложение пригодно и для вашего случая (по крайней мере для "потестить"), оно сканирует папку со всем ее содержимым и каждый файл разбивает на блоки около 1 мб, для каждого блока вычисляет чексумму, которую сохраняет в файл "отчета", после на основе данного отчета вычисляется каких блоков не хватает в той папке и какие блоки нужно заменить и генерирует "патч", который просто "накатывается" поверх содержимого той папки с которой делали отчет. В моем случае патч для GTA 5 оказался меньше 2 мб для 50Гб папки. Если интересно могу переделать для вашей задачи, к примеру в режим консоли.
Так же в теории (не проверял и не очень представляю как проверить) может тоже самое делать bittorent sync.

Comments

[АртемЪ]

Виталий Пухов А почему смещение в заголовке должно свести "на нет" всю идею блочного копирования?

[Виталий Пухов]

АртемЪ: потому как не зная смещения нельзя определить откуда начинать "искать" блоки и получится, что все блоки начиная с момента смещения будут уже новые (что не так, ибо их просто сдвинули) и копировать придется все. Можно конечно попытаться "найти" это смещение, но это достаточно трудоемкая задача, особенно когда объем файлов под 2 Тб.

[АртемЪ]

"потому как не зная смещения нельзя определить откуда начинать "искать" блоки" - неправда.
Как же тогда работает дедупликация?
Обычно метод скользящего окна применяется, и там разницы нет где внесены изменения - в начале файла, в середине, или в конце.

[Виталий Пухов]

АртемЪ: чтото я про этот метод забыл, действительно, можно его приспособить и тогда смещение не будет иметь никакого значения.Есть что доработать еще в софте) Спасибо. Изначально его не применял так как цель была немного иная у приложения, там было целью исправление сбойных частей файла, но файлы подразумевались одинаковые.

[Виталий Пухов]

АртемЪ: хотя трудоемкость алгоритма этот метод увеличит значительно, сравнивать каждый раз оба расположения по сети мягко говоря не очень хорошая идея, в том виде, в котором оно сейчас, "проверяется" папка только 1 раз, далее файл патча можно использовать как "отчет о состоянии" на последний момент времени, а отчет весит много меньше объема данных (для 50 Гб около 1 мб данных отчета).

[АртемЪ]

Виталий Пухов: Ну не обязательно сравнивать оба расположения по сети.
Применяем на одной стороне, строим список хэшей, передаем хэши на другую сторону, применяем там, и передаем только ту информацию для которой нет совпавших хэшей.

[АртемЪ]

Вроде был такой проект опенсорсный, с подобным функционалом, сейчас поищу.

[Виталий Пухов]

АртемЪ: и получается как раз та программа ссылку на которую я дал:) Она как раз этим и занимается. отчет это и есть список хэшей. кстати тоже опенсорс.

[АртемЪ]

Виталий Пухов: Ну программа довольно интересная. Надо будет посмотреть.
Она умеет работать с командной строки?

[Виталий Пухов]

АртемЪ: не делал, но добавить займет пару минут.

[АртемЪ]

Виталий Пухов: Было бы неплохо. Тогда ее можно использовать в скриптах.

[Виталий Пухов]

АртемЪ: на днях допишу тогда

[Виталий Пухов]

АртемЪ: возможно даже сегодня

[АртемЪ]

Попробовал потестировать - при создании отчета по большой папке (70гб) вылетает с ошибкой.
Для папки размером 10гб (два файла по 4,7гб) отчет создала, но при создании патча кушает 1,5гб памяти и много думает, за 3 часа так патч и не создала.

[Виталий Пухов]

АртемЪ: Память она конечно кушает прилично, когда делал думал о том чтобы максимально снять нагрузку с диска в ущерб памяти, попробую поправить. Но при 70 гб падать не должна, это как слону дробина, возможно в какую то подпапку или файл нет доступа. Кстати коммандную строку добавил, опубликую тогда уже после того как снижу потребление памяти.

Answer 2

[Сергей Ковалёв]

Я бы порекомендовал Bittorrent Sync, если бы NAS его поддерживал.

Answer 3

[umraf]

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

Так же разницу между большими бинарными файлами можно сделать с помощью xdelta. Задачу впрямую не решает, но вдруг пригодится.