Comments 30
Любопытно, спасибо. Жаль, linux -> linux синхронизация пока не поддерживается, хотя обсуждается.
У меня как раз подходящая для подобного инструмента задачка есть. Бекап ~3 Тб, ~3 млн.файлов, с относительно небольшим количеством ежедневных изменений, но изменяемую часть от неизменяемой никак не отделить, для полного счастья - исходные файлы через fuse с объектного хранилища примонтированы, т.е. inotify не работают, чтение всего, кроме метаданных, очень медленное. rsync даже в сутки не укладывается, а хотелось бы за пару часов... Пока думаю попробовать Resilio Sync, хоть он и проприетарный, увы.
Лучше в место Resilio Sync(у меня на лям мелких файлов зависал) пробуй Syncthing
За это спасибо, уже гляжу. Раньше слышал про Syncthing, но почему-то считал, что это оболочка над тем же rsync - а там свой протокол и принцип работы, оказывается.
Плюс вариант многопоточный рсинк: делать список файлов и параллельно для каждого запускать рсинк. Кол-во запущенных рсинков можно контролировать. Это хорошо когда много небольших файлов. Для одного большого см ниже.
Ну и ваще киллер прога - bbcp. Она многопоточно может передавать файлы с хост на хост, т.е. тот же синк делать. Точнее, после ббцп запускать обычный рсинк с ключом del и папка засинкается. Ньюанс может быть в дате создания файлов, учтите это.
плюсану предыдущего оратора - syncthing намного лучше чем resilio sync, но на моём опыте он не такой "нежный" к ресурсам и вполне может занять диск на 100% и процессор (если слабый) на те же 100% не заботясь о том а требуется ли оставить чуточку ресурсов другим приложениям. впрочем это решается, ресурсы для юнита ограничить не проблема.
Я ведь правильно понимаю что как в rsync так и в новом алгоритме считается хэш для блока и если он совпадает локально и удалённо, то считается что и блоки совпадают? Но ведь хэши, пусть чрезвычайно редко, но могут совпасть и для отличающихся данных? Для видео это наверное не страшно, но разве это допустимо для сколь-нибудь важных данных?
Вероятность, что два случайных блока будут иметь одинаковый хэш, уже крайне мала. А какова вероятность, что в одном и том же блоке одного и того же файла между двумя последовательными синхронизациями окажутся разные данные с одинаковым хэшем?
А как ещё инкрементальный бекап реализовать, в любом случае?
Мне в детстве очень нравилась книга Перельмана "Живая математика". По-моему рассказ из этой книги под названием "Пари" очень подходит в данной ситуации.
Инкрементальный бэкап к этому не имеет отношения, его можно делать и без этого. Данный подход просто ускоряет передачу изменившихся файлов.
У всего есть свои разумные пределы. В данном случае вероятность того, что файл побьётся из-за каких-нибудь случайных электромагнитных помех или сбоев в системах хранения / передачи данных, гораздо больше. Как и вероятность того, что все серверы и резервные копии, имеющиеся в нашем распоряжении, в один день погибнут в результате разных стихийных бедствий. Плюс, если целостность совершенно критична - добавляются дополнительные инструменты её проверки, скажем, хранение CRC целых файлов, пересчитываемой при их изменении (и тут уже, подозреваю, количество нулей после запятой в вероятности, что при нашем изменении одновременно сохранится и CRC блока, и CRC файла, будет больше, чем объём всех данных человечества)
И как его делать без этого? Даже если выкинуть за борт ситуации, когда в файле на сотню гигабайт периодически меняется пара мегабайт и каждый раз такие файлы копировать целиком (что не всегда возможно). Полагаться только на время последнего изменения файла как однозначный критерий, что он остался прежним? Так это куда как более смелое предположение.
У всего есть свои разумные пределы.
Я согласен. Но тем не менее, какой-то червячок остаётся. Ведь математик из рассказа вроде бы тоже всё правильно рассчитал.
Полагаться только на время последнего изменения файла как однозначный
критерий, что он остался прежним? Так это куда как более смелое
предположение.
Нравится это кому-то или нет, но именно так и делается инкрементальный бэкап. Мы бэкапим изменённые файлы. А как уж там пересылается изменённый файл, как мы узнаём что он изменился, это уже дело техники.
Нравится это кому-то или нет, но именно так и делается инкрементальный бэкап.
Инкрементальный бекап может делаться разными способами. rsync по умолчанию сравнивает время изменения и размер файла, и только если они изменились - считает CRC блоков. rsync с опцией -c всегда считает CRC блоков, даже если дата и размер файла не изменились. Второй способ, очевидно, надёжнее первого, но Вы сначала усомнились даже в его применимости для важных данных, а потом говорите, что для инкрементального бекапа достаточно и первого.
Это делается не для надёжности, а для случаев когда дата изменения файла может не отражать реальность. К надёжности это не имеет отношения. Конечно же первого способа вполне достаточно и к повышению надёжности второй способ не ведёт. Второй способ просто ускоряет передачу изменённых файлов (создавая при этом небольшой риск ошибки), которые бы иначе передавались бы полностью.
Надёжность - это вероятность достижения ожидаемого результата без проблем. Ожидаемый результат бекапа - получение полностью идентичной копии данных. Полагаться на время изменения файла -> полагаться на CRC -> делать каждый раз полный, а не инкрементальный бекап, - последовательно повышает надёжность данного процесса. Вопрос в том, где практически целесообразно остановиться в каждом конкретном случае с учётом всех факторов (скорость сети, объём данных, ценность оных и пр.)
Давайте отделим мух от котлет. Понятно, что могут быть сбои в работе оборудования, ОС, которые могут привести к тому что дата изменения файла не будет обновлена. Впрочем точно также эти сбои могут повредить и любую другую часть данных. Это понятно, возможно от этих случаев тоже надо как-то защищаться. Но давайте отложим пока эти проблемы в сторону и предположим что оборудование, операционная система и софт работают корректно.
В этом случае использование даты изменения файла вполне надёжно и использование хеш-сумм никак не увеличивает надёжность. Зато использование хеш-сумм для ускорения передачи изменённых файлов эту надёжность снизит, так как возможны их совпадения даже при корректной работе оборудование и софта. Наверное это снижение действительно незначительно и им можно во многих случаях пренебречь. Но тем не менее, это снижение надёжности, а не её повышение.
А я и не предлагал не полагаться на дату файла, я сам на неё полагаюсь, потому что пересчитывать CRC нескольких терабайт каждые сутки позволить себе не могу. Но прекрасно понимаю, что это меня может подвести во вполне реальной ситуации (взять хотя бы злонамеренное повреждение файлов каким-нибудь зловредом, который специально оставит дату неизменной).
А вот вероятность совпадения CRC - скорее нереальна. Для 128-битной CRC, которую использует rsync, шанс, что два случайных блока будут иметь одинаковый CRC - 1/2^128, т.е. 38 нулей и одна тройка после запятой. Да, этот шанс может быть несколько выше из-за возможной корреляции CRC для данных с похожими паттернами (сорри, уровень погружения в матчасть не позволяет сформулировать корректнее). Но с другой - он будет ещё гораздо ниже, т.к. в нашем случае должны не просто совпасть CRC двух произвольных блоков, а CRC двух последовательных версий одного и того же блока.
В общем, мысль была в следующем. Либо уж мы защищаем такие сверхценные данные, от которых зависит судьба человечества, что страхуемся от события, которое, вероятно, за всю историю Вселенной никогда не произойдёт. Либо мы трезво оцениваем риски и полагаемся, если это практически необходимо, даже на дату изменения файлов, хотя понимаем, что это нас, вероятно, подведёт когда-нибудь в обозримой перспективе. Но делать и то, и другое одновременно - странно.
Кстати говоря, Ваш пункт 1 как раз больше подходит к тому самому пари.
В OpenZFS и BtrFS инкрементальная синхронизация сделана без этого :)
Когда мы на уровне ФС можем отслеживать изменения - нам вообще проще живётся :) Точно так же резервное копирование виртуальных машин, например, Proxmox делает без этого, если они не останавливались между сеансами и есть dirty-bitmap.
Ну или если мы используем inotify (но тут вопрос, насколько мы можем полагаться на то, что этот inotify без перерывов и сбоев работает всё время, поэтому периодический полный рескан надо бы делать всё равно).
Если файл изменился на Windows, то в систему Linux передаются только различия (дельта).
И как это поможет если (к примеру) в начале файла окажется один новый байт? Или наоборот, удалится один байт?
Увы, ни одна файловая система (насколько мне известно) не позволяет (бесплатно) вставлять или удалять кусочки файлов - придётся делать новый на основе старого и изменений, но без копирования части старого тут не обойтись, и не факт что это будет быстрее чем передача по сети с точки вставки или удаления.
Если же нет вставок или удалений - тогда всё ок, CDC шустрее чем фиксированные блоки.
И как это поможет если (к примеру) в начале файла окажется один новый байт? Или наоборот, удалится один байт?
На принимающей стороне эту проблему можно относительно дешево нивелировать установкой современных NVME SSD со скоростями чтения\записи, измеряемыми в гигабайтах (уже почти в десятках) в секунду - так что перезаписать один файл, даже в 40 Гб - дело считанных секунд. Интернет и даже локалка на такой скорости пока менее доступны, так что смысл в этом есть)
и каким образом он там окажется? каким системным вызовом вы собираетесь вставить 1 байт? в таком случаи если у вас локально файл переписался полностью на диске, то почему удалённо ему не измениться таким же родом? по-этому никто так не делает, а если надо вставлять что-то посреди файла, то в записываемых на диск блоках оставляют пустое место, о котором логика приложения ничего не знает. в таком случаи нет проблем синхронизировать пару блоков вместо целого файла
Для торрентов сделайте пожалуйста.
Господа программисты, а есть такой же по эффективности инструмент но для Linux -> Windows? Может быть, я неправильно свою задачу решаю, но у меня клиенты как правило на Windows а сервер Linux и хочется иметь что-то похожее как у Steam но для небольшой аудитории.
Есть 3 компа на Windows 10, территориально разнесенных (допустим Работа, Дом, Ноут). Нужно чтобы на всех трех были самые актуальные (свежие) общие папки, при том, что изменения в файлы могут вноситься на любом из трех. Случай, когда один и тот же файл будет одновременно открыт более чем на одном устройстве - маловероятен (ибо пользователь всего один). Контент разнородный - как проекты с исходниками (тысячи мелких файлов), так и видео на пару гигов. Какой софт посоветуете? Нужен не бекап, а именно корректная синхронизация трех машин. Лет 10 назад начал пользоваться bittorrentsync, все устраивало, но в течение года он как-то испортился, а потом и вовсе пропал.
Лучшее что есть - это упомянутый выше SyncThing. К тому же мультиплатформное - можно даже с Android/iPhone синхронизировать (правда iPhone пока бета и нужен бубен).
Synology drive меня устраивает на 95%
RSync на стероидах с поддержкой Windows