forum.lissyara.su

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

Собственно, вопрос: как с этим обходиться и как делать копирование в автомате.
Можно бы сделать свой скрипт копирования и запросить список открытых файлов, ставя занятый файл на паузу в отдельный поток, но как-то это криво...

а что в файлах?

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

снэпшот делай и бэкапь
хотя все равно фигня будет

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

снэпшот от бэкапа в этом смысле не отличается ничем...

А с чего они одинаковые будут?!
И какой смысл бэкапить файлы в которые идет запись?

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

kuksha писал(а):Блин, да никто одинаковости не ждёт...
Неприятность в том, что во время бэкапа я не всегда могу быть уверен, что в файлы не ведётся запись.
Теоретически у нас и ночью народ работает в конторе удалённо: ночной снапшот снял, а в нём какой-то файл кривым оказался...

Вы странного хотите...
Запись не идет только в single-user mode
Full-backup (раз в неделю) + инкрементальный (каждый день)

Ну или ZFS

guest, я такие советы сам могу давать...
Есть что по теме сказать?
ZFS осваивать только начали - в чём она может помочь пока не видим, если натолкнёте - только спасибо скажем

kuksha писал(а):Блин, да никто одинаковости не ждёт...
Неприятность в том, что во время бэкапа я не всегда могу быть уверен, что в файлы не ведётся запись.
Теоретически у нас и ночью народ работает в конторе удалённо: ночной снапшот снял, а в нём какой-то файл кривым оказался...

Это нужна объектная ФС.
Посылается месадж - объекты сами себя бэкапят

kuksha писал(а):guest, я такие советы сам могу давать...

если можете, зачем ерунду пишите? (Без обид)

По теме, подумайте крепко как работает FS и что Вы хотите на live-FS, вопросы уйдут.
Про lsof - попробуйте и быстро убедитесь что подход нереальный, попробуйте изобрести новую FS со своим срезом (snapshot),
а-ля ZFS, хранение копий в самой FS и тд и тп.

Есть что по теме сказать?
ZFS осваивать только начали - в чём она может помочь пока не видим, если натолкнёте - только спасибо скажем

zfs snapshot

kuksha писал(а):Блин, да никто одинаковости не ждёт...
Неприятность в том, что во время бэкапа я не всегда могу быть уверен, что в файлы не ведётся запись.
Теоретически у нас и ночью народ работает в конторе удалённо: ночной снапшот снял, а в нём какой-то файл кривым оказался...

Вы-бы объяснили какого результата вы хотите добиться. Может тогда получите более внятный ответ. А то у вас на данный момент просто нытье по поводу того как оно есть, но нет толком поставленного вопроса на который можно было-бы ответить.

как раз понятно чего он хочет:
открытые на запись файлы должны бэкапиться после того как их закроют
этакий отложенный бэкап

Ну да, Neus почти точно сформулировал - хочется отсутствия заведомо битых файлов, которые появляются таким способом.

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

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

почему почти?
вот смотри
-------------/------|------\----------->t
/\ это начало и конец записи, | это начало бэкапа
в UFS в бэкап не попадет изменение от | до \ , т.е. файл будет недоизмененный, это такая физика процесса, ничего не поделаешь
в случае с zfs, в бэкап не попадут изменения файла между /\

но тебя и zfs не устроит
тебе надо написать свой бэкапер работающий по такому алгоритму:
начинаем бэкап
если в процессе бэкапа натыкаемся на открытый файл - отращиваем тред ожидающий закрытие файла и бэкапящий его после закрытия
ждем завершения тредов и заканчиваем бэкап
вуаля!

С СУБД такое не прокатит. но их и не бэкапят средствами ФС

Насчёт "почти" - Neus, да согласен.

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

Спасибо всем, кто помог разобраться!

kuksha писал(а): Печально, что мы не ошиблись: штатные средства копирования во фрюхе (и снэпшоты в том числе) действительно несут вероятность появления таких вот "подарочков"...

"это такая физика процесса, ничего не поделаешь" относится к любой обычной ФС на любой ОС
в ФС HAMMER можно мастер-слэйв репликацию соорудить штатными средствами - этаткий realtime backup получится

Если не секрет, в какой системе штатные средства делают ту фигню какую вы хотите?

Ну, как-бы стандартное решение подобной задачи - это "закрываем все открытые файлы и только тогда начинаем бакап". И пусть весь мир подождет.

FiL писал(а):Ну, как-бы стандартное решение подобной задачи - это "закрываем все открытые файлы и только тогда начинаем бакап". И пусть весь мир подождет.

Вы от вопроса не уходите, пример в студию где сие работает?
_КТО_ и _КАК_ будет лочить или _закрывать_ открытые файлы, что будет с демонами и сервисами
использующими эти файлы, как, например, закрыть логи и как будет работать ядро и система без логов?

Кто и как - ну, например, админ. Переведя систему в single user mode. А демоны и сервисы будут ждать пока бакап не закончится и системя не будет переведена в multiuser.

Фигню придумал