Мгновенный бекап

какой-то другой способ быстро скопировать маленький файл?

Git диффы шпарит. Через него должно быть быстрее.

Правильный ответ: открыть соединение заранее.

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

Огласи настоящую задачу, короче.

Григорий Остер, залогиньтесь.

Григорий Остер

Промазал :)

Вопрос, как сделать копирование максимально быстрым.

неправильный вопрос, правильный: «как сделать копирование максимально надёжным»

Правильный ответ: открыть соединение заранее.

Как это можно сделать в скрипте?

Огласи настоящую задачу, короче.

Это бекап off-chain data сервиса lnd (lightning network) Не думаю, что это многим будет о чем-то говорить. У сервиса встроенная система бекапа в файл на локальный диск.

неправильный вопрос, правильный: «как сделать копирование максимально надёжным»

Надежным это само собой, но мне надо сделать его максимально быстрым.

У сервиса встроенная система бекапа в файл на локальный диск.

В Linux нет принципиальной разницы между локальным и удаленным диском.

Ок, хорошо. Какое решение лучше подойдет для моей задачи, чтобы использовать удаленную файловую систему как локальную? Повторю, мне важно, чтобы изменение файла сразу отражалось на HDD другого сервера.

DRBD

Для адекватного ответа недостаточно входных данных. Пока что это выглядит как какой-то костыль. Я лишь отметил, что если

У сервиса встроенная система бекапа в файл на локальный диск

то можно примонтировать удаленный диск (SSHFS, NFS) и будет уже удаленный бекап. Но его консистентность вызывает вопросы.

aquadon, спасибо за ответы.

Для адекватного ответа недостаточно входных данных. Пока что это выглядит как какой-то костыль.

Да, так и есть, сама софтинка еще молодая, работаю с тем, что есть.

то можно примонтировать удаленный диск (SSHFS, NFS)

Прочитал, они мне оба понравились. Не понимаю какой выбрать :) С одной стороны NFS лучше, т.к. не нагружает проц, но мне не нравится, что там авторизация происходит по IP, а статического IP у клиента нет. Используя DDNS можно частично решить проблему, но обновление DNS записей может занять время и бекап не будет работать.

С одной стороны NFS лучше, т.к. не нагружает проц, но мне не нравится, что там авторизация происходит по IP, а статического IP у клиента нет.

Подними VPN, заодно зашифруешь.

NFS в Hard режиме твой выбор, ИМХО.

Смотря насколько далеко ты готов зайти. Идеальное техническое решение: написать своё приложение с шарингом сжатых диффов по пиринговому протоколу.

Нет.

Идеальное решение для ОП - не написать свой Syncthing.

Идеальное решение для ОП - понять, что консистентность он проигрывает в хлам, и замутить протокол, в котором он никогда не останется ни с половиной бэкапа, ни с рассинхроном бэкапа. Никаких файлов, никакой такой лабуды, куда большее время ожидания со стороны генерирующего софта. Возможно что-то из области СУБД подойдёт из коробки.

Сейчас же это звучит так, как будто при отключении питания ТС потеряет данные и локально, и удаленно.

ТС, на сколько записей допустимо в твоей задаче удалённому бэкапу отстать от локального? Если на 0, то вся твоя схема на файлах никуда не годна.

замутить протокол?

почему бы просто не писать временный файл, а при успешной его записи делать mv tmp real.

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

Если такой возможности нет и костылей не избежать, то вполне сойдёт простое клиент-сервер приложение, которое будет держать постоянное соединение. Клиент пусть кидает содержимое файла, благо это несколько килобайт, ну и с временной меткой, естественно. Гит, как выше предлагали, тоже сойдёт, но, мне кажется, он будет отрабатывать не так быстро, как хотелось бы.

Храни файл на zfs, дергай снапшоты,пересылай снапшоты на другую машину. Как результат - всегда можно откатиться на требуемый снапшот и иметь бэкап. Или используй версионную фс, типа nilfs2(хз стабильная ли она вообще).

Ну вот смотри.

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

Приложение начинает писать tmp на диск, закончило fwrite, сбрасывает кеши, и тут вдруг пропадает питание. Мы загружаемся, отбрасываем tmp, используем real. Где-то далеко по таймауту TCP отваливается наш собеседник, но он так и не получил отмашки, что у нас все дошло до диска, откатывает транзакцию и понимает, что когда мы опять будем в сети, мы будем ни сном, ни духом о ней.

Классно? Да, но при такой схеме и степени продуманности обычно механизм транзакционности впекается в формат файла / СУБД и не нужно делать mv tmp real.

А теперь давай смотреть, что будет, если хоть один из наших пунктов нарушен.

Если приложение ТСа просто сохраняет что-то на диск, не заботясь о его консистентности в процессе записи, продолжая фигачить дальше, то твой mv - хорошая идея, но от всех проблем не спасет. Пример: вот ты грузишься после хардресета, у тебя на диске tmp и real. Сколько транзакций будет потеряно, если ты рестартанешь с real?

Если приложение ТСа ведет себя идеально, но про mv не знает? Hard reset между окончанием записи и успешным завершением mv - и ты теряешь транзакцию.

Если правильной (и сложной) синхронизации с остальным взаимодействием нет, и внешние ресурсы могут оказаться в заблуждении о том, что ты учел транзакцию, а ты перезагрузился и откатился, то пошел рассинхрон. От которого еще можно спастись костылями, но еще сложнее, чем предотвратить.

Если mv неатомарен, то вообще капец.

А теперь смотрим на задачу ТСа. У него так хрен бы знал что, а потом scp prod remote:bak процессом, не знающим даже когда читать этот prod. Толку от такого «бэкапа» - спокойный сон до обнаружения того, что он, естественно битый. Которое случится, когда что? Правильно, побьется prod. И во избежание вероятной депиляции его задницы мы обязаны в такой схеме отговаривать его от всего, что не является ни штатно реализованной схемой бэкапа в самом приложении, ни бэкапом из остановленного состояния.

ТС, не делай глупостей.

https://github.com/axkibe/lsyncd

а ты зацепился за потеряную транзакцию, давай спросим у тса, не плевать ли ему на пропуски состояний? главное, mv атомарен на уровне фс, ее кешей, кешей диска и всего такого.

Ну допустим ему плевать на пропуски. Сформулирую проще.

ТС пытается постоянно копировать грязную базу, ибо не имеет снаружи от программы представления о том, когда она консистентна. Он может снаружи хоть уmvкаться. Даже если он, не знаю, снапшоты ФС применит и тем самым решит проблему того, что файл меняется, в самом-самом идеале у него будет атомарная немного несвежая копия грязного снапшота базы.

Можешь оспорить? Я что-то упускаю?

я это не оспариваю, а лишь говорю, что, походу ему плевать на пропустить пару состояний.

А я из «Потенциально файл может меняться часто (например пару раз в секунду) и мне важно иметь актуальный бекап этого файла на другой машине. Вопрос, как сделать копирование максимально быстрым.» предполагаю, что ему не плевать и это именно что такой его способ избежать пропуска пары состояний.

)))

да сам заголовок треда в ступор может ввести - что есть мгновенно?

В теории для общего случая непрозрачного приложения - до окончания сигнализации конца записи приложению. Возможно даже еще до наступления пятницы.

В мире ТС - быстрее, чем он успеет заметить, т.е. много быстрее, чем сейчас =)

А если мы начали копировать файл, половину скопировали, и тут процесс его перезаписал — в бекапе будет каша?

бекап всегда делается в одно и тоже имя файла ?

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

Поднимаете Ceph, натягиваете CephFS, файл выкладываете на неё, и оригинальный файл делаете симлинком :-)

«если»? =) ты хотел сказать «как часто» =D

«если»? =) ты хотел сказать «как часто» =D

Я просто не в курсе, может, там какие-то нюансы есть. Если так, то, видимо, этот путь заведомо проигрышный и надо мутить что-то вроде очереди сообщений.

ФС со снепшотами. Перед копированием файла - делаешь снепшот, из снепшота копируешь файл, снепшот удаляешь. Как отследить событие записи файла - ну тебе или inotify прикручивать, или разбираться со своей программой.

Идея с log-structured FS действительно вкусная в теории, ведь позволяет получать консистентные версии файла безотносительно того, как та программа пишет на диск. Ещё бы была какая-нибудь стабильная log-structured fs, которая умела бы синхронизоваться…

Ну и от чего именно тут спасают снапшоты? =)

От изменения файла во время копирования.

Удваиваю cephfs. Страдать, так страдать по полной, ещё и потратив тонну денег.

Это если совсем по-хорошему. Если он сам пилит свою блокчейн-фигню, то так и надо было делать изначально.

И как ты узнаешь, в какой момент состояние на диске консистентно? Значит не спасает.

После изменения файла тут же сделать снепшот. Снепшот делается рассказать как? А потом из снепшота уже доставать файл.

Ты не знаешь, в какой момент данные консистентны => будешь снимать снапшоты каши.

А если оно консистентно всегда, то достаточно и mv.

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