lvm или zfs для частых снапшотов.

ZFS

lvm

zfs

lvm

btrfs

Гироскутер в подарок?

ага, и вейп жижу еще, годовой запас.

там стоит KVM, в нем виртуалка древней 1C 7.7

1C файловая или база в MS SQL? Вообще говоря, снапшоты ни средствами LVM, ни средствами ZFS не смогут гарантировать Вам консистентность базы 1C. IMHO, стоит подумать о штатных средствах бекапа (либо MS SQL, либо 1C) изнутри виртуалки...

Протестируй, сравни, сделай выводы и отпишись.

ZFS

Нет там MSSQL и невозможно сделать. База слишком изуродована. А консистентность на паре сотен копий, снимающихся через 15 минут, практически гарантированная. Не каждый же день восстанавливают убитую базу.

А зачем так часто?

А зачем так часто?

А лень человеку отзеркалировать хранилище, а бэкапть по нормальному расписанию.

Как правильно зеркалировать хранилище не рейдов и баз?

У постгреса можно сделать select pg_start_backup('ololo'); перед снапшотом, потом select pg_stop_backup();. У других субд я думаю тоже есть нечто подобное.

Ну потому что сам по себе рейд тоже точка отказа. Лучше снапшотить, чем ждать когда сам рейд покажет мастер-класс.

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

ZFS, но прочитать это. Непосредственно для 1C там нет рекомендаций, нужно recordsize выставить корректно относительно того, как именно база данных со стораджем работает. Для того чтобы избежать лишний RMW.

У других субд я думаю тоже есть нечто подобное.

Угу. Я нечто подобное и имел ввиду. Только вот, как выяснилось, у автора темы файловая версия 1C. И тут снапшоты мало помогут. Если, конечно, там не два клиента по одному разу в день пишут в базу...

Нет там MSSQL и невозможно сделать. База слишком изуродована.

Я не знаком с 1C, но разве там нет штатных средств бекапа (выгрузка базы или что-то вроде этого)? IMHO, это на порядок надежнее и удобнее снапшотов...

Оно требует монопольный режим.

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

Сможете сделать архив базы 1с не выгоняя пользователей без mssql?

Что значит без mssql ? Вы не очепятались ? Если Вы имели в виду из, то смогу.

файловая наверна.

Файловый бэкап для работающих баз - это зло, ибо вы в случае краха никогда не приведете базу в актуальное состояние (если это конечно не локалхост).

Файловый бэкап для работающих баз - это зло

Да. Но проблема в том, что ТС задал совсем другой вопрос, и не хочет, похоже, твоего ответа.

Люди вообще очень склонны что-то там себе напридумывать, и задавать вопрос о частностях этого конструкта, вместо того, чтобы описать — что реально хотят получить.

«Где лучше снэпшоты: lvm или zfs?» вместо того, что действительно нужно было бы спрашивать: «Как бы мне лучше бэкапить файловую базу 1C с минимальным даунтаймом»?

Одним из правильных ответов было бы:

1. Приводишь базу в непротиворечивое состояние: заканчиваешь текущие коммиты, временно фризишь новые запросы,
2. Делаешь снэпшот ФС,
3. Размораживаешь базу,
4. Неспеша бекапишь снимок файлов.
5. PROFIT

Да согласен с Вами.

А ваши 5 пунктов Я сведу у одному:

1) Репликация, причем SQL Server это делает просто и надежно

P.S. И вообще касаемо именно MSSQL там есть куча способов выполнить данную задачу. Уж не хочу разжигать, но это на данный момент самая удобная и вменяемая СУРБД. Рядом Oracle.

Лучше гетероскутер.

Насколько часто снапшоты планируешь делать?

При снапшотех извне через столько слоёв абстракций в бэкапе будут неконсистентные данные 100500% ( об этом уже сказали)

Какие вы все простые, не переводится база в mssql никак, на 8.3 конфигурацию год будут пилить.

Тут люди явно не понимают, что такое изуродованная вхлам 1с 7.7

Раз в 30 минут. Там нет других способ снимать. В MSSQL не работает она никак, т.к. реализация в ней черезжопная и надо переписывать кучу кода, чем никто не будет заниматься, т.к. код пилится по 8.3, но это надолго. Сделать выгрузку средствами самой 1С можно только выгнав всех пользователей и зайдя в монопольный режим.

К тому же там очень часто (несколько раз в день) убивают приложение по время активной работы, а проблема с разрушенным 1Sjornal возникает раз в полгода, еще два раза были проблемы из-за сраного intel raid. Но тут так описывают, как-будто писец все снапшоты будут битыми.

Если ты про буферы диска, то qemu-guest-agent умеет вызывать VSS.

Сможете сделать архив базы 1с не выгоняя пользователей без mssql?

УРБД это называется

http://www.mista.ru/articles1c/urbd.htm

Но там есть свои нюансы.

Но там есть свои нюансы.

И как я понял совсем маленькие, на тысячу человекочасов.

А анальная смазка где?

И как я понял совсем маленькие, на тысячу человекочасов.

Нет. Оно или сразу работает или сразу не работает. Процентов на 90% работает. Это внутренний механизм 1С.

Какие вы все простые, не переводится база в mssql никак

Я где-то сказал про mssql? «Файловую базу 1C».

У тебя что, нет механизма монопольно залочить файлы базы? Еще раз:

• переводишь в монопольный режим,
• делаешь снэпшот
• снимаешь монопольный режим

Это всё происходит быстро. А дальше уже неспеша бэкапишь.

переводишь в монопольный режим,

Раз в полчаса? Вы вообще в курсе что такое 7.7?

Зачем ты задаешь вопросы, если не слушаешь ответов и вообще самый умный?

Ответы тут явно за пониманием что такое 7.7, то mssql использовать, под который никто не делал конфигурацию, то средствами 1С делать, которые требуют перехода в монопольный режим, то снапшоты будут неконсистентными, как-будто каждый раз снятая база будет заливаться в рабочую. Мы проводили тестирование снапшотов, вероятность снятия сломанной базы во время активной записи меньше 1%, при условии вызова VSS, который вызывается qemu-guest-agent`ом.

Мне интересны были проблемы именно частых снапшотов LVM и ZFS, а не того что там внутри!

проблем нет, если не забывать удалять снапшоты.

Какие вы все простые, не переводится база в mssql никак, на 8.3 конфигурацию год будут пилить.

Хм, вообще-то, версия 7.7 тоже была не только файловой. И если уж такая специфичная конфигурация, кто мешает перевести базу в SQL, не поднимая версии 1C?

По поводу эксплуатации базы - сколько там пользователей, размер базы, какова суточная динамика использования? Неужели все 24 часа непрерывная работа идет? И нет возможности прерваться на несколько минут, чтобы уйти в монопольный режим на время снапшота?

Но тут так описывают, как-будто писец все снапшоты будут битыми.

Именно так и будет, если пользователи реально постоянно пишут в базу.

Раз в полчаса? Вы вообще в курсе что такое 7.7?

IMHO, лучше иметь нормальный бекап раз в сутки, чем 48 неконсистентных бекапов за то же время.

вероятность снятия сломанной базы во время активной записи меньше 1%, при условии вызова VSS, который вызывается qemu-guest-agent`ом.

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

Хм, вообще-то, версия 7.7 тоже была не только файловой. И если уж такая специфичная конфигурация, кто мешает перевести базу в SQL, не поднимая версии 1C?

Не работает данная конфигурация в MSSQL, очень много особенностей накопленных за 10 лет.

По поводу эксплуатации базы - сколько там пользователей, размер базы, какова суточная динамика использования? Неужели все 24 часа непрерывная работа идет? И нет возможности прерваться на несколько минут, чтобы уйти в монопольный режим на время снапшота?

Работает база с 8 утра до 21 вечера. Там проблема в том, что нужны более частые снапшоты, а не раз в сутки.

IMHO, лучше иметь нормальный бекап раз в сутки, чем 48 неконсистентных бекапов за то же время.

Твоё ИМХО не тестировало снапшоты, чтобы утвержать что 48 бекапов будут неконсистентными. Мы перед этим проводили тестирование на очень высокой нагрузке, за 200 снапшотов ни одного сбоя.

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

Аварийную базу грузят раз в год от силы, а не после каждого бекапы. Гораздо больше ущерба наносится тасккиллами и говнорейдом

Проблема в том, что за этот раз в год рвется пукан из-за того что бекапу сутки, а 1Sjournl укокошен говнорейдом или тасккилом.

Работает база с 8 утра до 21 вечера.

Т. е. 1 консистентный суточный бекап у Вас есть, это уже хорошо.

говнорейдом

Почему бы не начать с перевода базы на нормальную дисковую систему? На фоне всего остального (переписывание конфигурации) это вообще копейки...

По Вашему вопросу (ZFS или LVM) - надо смотреть время получения снапшота - чем оно меньше, тем меньше шансов нарваться. Подозреваю, что LVM тут предпочтительнее, но лучше Вам проверить это на своей конфигурации.

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