Comments 30
1. Оформление выглядит крайне вырвиглазно
2. Бекапы складывать на том же сервере, где находится БД — так себе затея.
2. Бекапы складывать на том же сервере, где находится БД — так себе затея.
Без сомнения, в данном случае за хранение бекапов отвечает заказчик. На объекте есть только мобильный интернет, который включается именно для таких случаев
Рабочее место “Касса” — одновременно сервер всей системы.
Разве за такое не четвертуют сразу, не дожидаясь появления пушных зверей?
пожелание заказчика ради экономии, ну и надежда на авось и так сойдет, все варианты ему озвучены были
Я же понимаю, что бекапы идут на тот же физический жесткий диск, что и БД?
Кстати, насчет планировщика, я заметил, что иногда с ним бывают проблемы, если задача выполняется чаще раза в день. Пропуски или двойное выполнение, редко но бывает.
Мы используем nnCron, тут хватит даже Lite.
Но главное, что надо разобраться почему завис процесс и его нельзя было вырубить.
Кстати, насчет планировщика, я заметил, что иногда с ним бывают проблемы, если задача выполняется чаще раза в день. Пропуски или двойное выполнение, редко но бывает.
Мы используем nnCron, тут хватит даже Lite.
Но главное, что надо разобраться почему завис процесс и его нельзя было вырубить.
в данном случае да, там компьютер моноблок с touch экраном
как-то так, можно правда ещё батник написать который охранник просто запускает когда флешку вставляет
Зачем делаете nbackup уровня 0? Лучше уж тогда gbak, после него копия будет сжатой и проверенной на ошибки.
Я делаю ночью nbackup уровня 0, а в течение дня каждый час уровня 1. На одной БД nbackup ведет себя очень нестабильно, иногда снимая копию уровня 1 больше часа.
Я делаю ночью nbackup уровня 0, а в течение дня каждый час уровня 1. На одной БД nbackup ведет себя очень нестабильно, иногда снимая копию уровня 1 больше часа.
у меня довольно не большая БД, клиент забирает(будет забирать) бекапы вручную, парить ему мозг несколькими файлами, решил излишним
Ну у меня тоже 2 БД примерно по 2ГБ. Вот только бэкап от gbak весит мегов 600, а nbackup уровня 0 слепит точную копию БД исходного размера. Экономия места приличная получается.
Время снятия копии посредством nbackup — примерно минута, gbak — чуть дольше (минут 5), но она и целостность страниц проверяет, и сжимает на лету.
Время снятия копии посредством nbackup — примерно минута, gbak — чуть дольше (минут 5), но она и целостность страниц проверяет, и сжимает на лету.
Дельфи, Файрберд, Надежность — выберите любые два
А чем плох Delphi и Firebird? Наговнокодить можно на любом языке и любой СУБД. Сам много лет использовал Delphi и Firebird. И разработанные системы работаю до сих пор без нареканий и проблем.
а что не так?
А. Дельфи — слишком низкий порог входа приводит к избытку идиотских вопросов на форумах, а синтаксис и возможности языка — равны С++ без шаблонов. Синдром CheckBox28Click
Средняя квалификация коммунити в итоге весьма «впечатляет»
Б. Файрберд — хорошая СУБД для рабочих групп, но с ньюананасами —
1. Недуракоустойчивая. Можно сделать невосстановимый бэкап gbak, например (я даже сначала не поверил такому нонсенсу).
2. MVCC без лога приводит к тому, что при транзакциях нужно делать много изменений по всему файлу данных.
Соответственно, при сбое питания или внезапном ресете шанс похерить базу возрастает многократно.
Умножаем теперь А. на Б. и получаем Ннадежность
P.S. Автор топика, возможно, еще не знает, как на самом деле устроен nbackup, что на него полагается. Я даже не знаю, как пояснить. Упрощая — это эмуляция лога в БД, которая лог не использует. В целом — вполне можно получить бэкап, с которого не восстановишься.
Средняя квалификация коммунити в итоге весьма «впечатляет»
Б. Файрберд — хорошая СУБД для рабочих групп, но с ньюананасами —
1. Недуракоустойчивая. Можно сделать невосстановимый бэкап gbak, например (я даже сначала не поверил такому нонсенсу).
2. MVCC без лога приводит к тому, что при транзакциях нужно делать много изменений по всему файлу данных.
Соответственно, при сбое питания или внезапном ресете шанс похерить базу возрастает многократно.
Умножаем теперь А. на Б. и получаем Н
P.S. Автор топика, возможно, еще не знает, как на самом деле устроен nbackup, что на него полагается. Я даже не знаю, как пояснить. Упрощая — это эмуляция лога в БД, которая лог не использует. В целом — вполне можно получить бэкап, с которого не восстановишься.
Знаю только то что из мануала прочитал:
Несколько слов о внутренних механизмах
На заметку: то, что здесь будет описано, не является необходимыми знаниями для использования nbackup. Это описание дает грубое представление о том, что происходит при работе программы nbackup с параметром -B:
Прежде всего, основной файл базы данных блокируется установкой внутреннего флага состояния. С этого момента абсолютно все изменения в базе данных записываются во временный файл, называемый файлом разницы (difference file) или файлом дельты.
После этого создается резервная копия. Это не обычная копия файла базы данных — восстановление из полученной копии необходимо производить также при помощи nbackup.
По завершении резервирования содержимое файла дельты объединяется с основным файлом базы данных. После этого база данных разблокируется (флаг возвращается в «нормальное» состояние) и файл дельты удаляется.
Именно. Только я предпочитаю читать в исходниках, а не в мануалах.
А резюме такое — после бекапа Птички обязательно надо делать тестовое восстановление и срочно орать «бадуга» если оно не проходит.
Собственно, скрипт надо прилично так дописать.
P.S А еще nbackup архивирует данные вместе с мусором (старые версии MVCC), который не успел убрать Garbage Collector. Да, это именно та же технология, за которую ругают Яву, дотнет и тп. Только для дисковых операций в СУБД это в сотни раз медленнее.
А резюме такое — после бекапа Птички обязательно надо делать тестовое восстановление и срочно орать «бадуга» если оно не проходит.
Собственно, скрипт надо прилично так дописать.
P.S А еще nbackup архивирует данные вместе с мусором (старые версии MVCC), который не успел убрать Garbage Collector. Да, это именно та же технология, за которую ругают Яву, дотнет и тп. Только для дисковых операций в СУБД это в сотни раз медленнее.
>1. Недуракоустойчивая. Можно сделать невосстановимый бэкап gbak, например (я даже >сначала не поверил такому нонсенсу).
Только для тех, кто сидит на версиях до 2004 года. Начиная с 1.5 появился переключатель -no_validity, который восстанавливает в любом случае.
>2. MVCC без лога приводит к тому, что при транзакциях нужно делать много изменений >по всему файлу данных.
>Соответственно, при сбое питания или внезапном ресете шанс похерить базу возрастает >многократно.
В Firebird используется механизм Careful Writes, внедренный в в 80-х годах в InterBase. Именно благодаря этому механизму InterBase работал на системах залпового огня MLPRS для хранения, в которых вся система перегружалась из-за магнитного удара.
Только для тех, кто сидит на версиях до 2004 года. Начиная с 1.5 появился переключатель -no_validity, который восстанавливает в любом случае.
>2. MVCC без лога приводит к тому, что при транзакциях нужно делать много изменений >по всему файлу данных.
>Соответственно, при сбое питания или внезапном ресете шанс похерить базу возрастает >многократно.
В Firebird используется механизм Careful Writes, внедренный в в 80-х годах в InterBase. Именно благодаря этому механизму InterBase работал на системах залпового огня MLPRS для хранения, в которых вся система перегружалась из-за магнитного удара.
* Необходимо добавить обработку кодов возврата иначе о том, что что-то пошло не так, узнаете внезапно.
* Желательно проверять размер получившегося бекапа на адекватность.
* Хорошо слать отчёт на почту, особенно если что-то не так.
* Можно добавить сжатие, лучше многопоточное, например через 7zip.
* А после этого добавить автоматическую очистку старых бекапов.
И будет вполне себе велосипед.
* Желательно проверять размер получившегося бекапа на адекватность.
* Хорошо слать отчёт на почту, особенно если что-то не так.
* Можно добавить сжатие, лучше многопоточное, например через 7zip.
* А после этого добавить автоматическую очистку старых бекапов.
И будет вполне себе велосипед.
разве 3 строчки в cmd это уже статья на хабре? не в обиду… просто вспомнил какой раньше была жесткой редактура хабра.
Прекрасно это всё. Только до краха сервера или винтов на нём. Как я понял, бэкапы складываются там же, да небось ещё и на том же винте? Если это так, то всё плохо.
из замечаний:
1. Нет бэкапа на альтернативный носитель. В идеале, второй винт + облако.
2. Бэкапы никак не контролируются. Т.е. они только создаются, а подчищать кто будет?
из замечаний:
1. Нет бэкапа на альтернативный носитель. В идеале, второй винт + облако.
2. Бэкапы никак не контролируются. Т.е. они только создаются, а подчищать кто будет?
если база не большая, могли бы хоть настроить бекап в какую нибудь бесплатную mega.nz
Для создания бекапов Firebird, есть прекрасная утилита «Time To Backup»,
бесплатна для пользователей экс-СССР.
http://www.sqlly.com/timetobackup.html
Серверная часть есть под Win и Linux, на Win работает как сервис, консоль только на Win.
Есть планировщик запуска, нотификация на емейл, сжатие бекапов, проверка бекапа на рестор, автоименование файлов по шаблонам (дата/время/инкремент).
бесплатна для пользователей экс-СССР.
http://www.sqlly.com/timetobackup.html
Серверная часть есть под Win и Linux, на Win работает как сервис, консоль только на Win.
Есть планировщик запуска, нотификация на емейл, сжатие бекапов, проверка бекапа на рестор, автоименование файлов по шаблонам (дата/время/инкремент).
Sign up to leave a comment.
Как я делаю бекапы. СУБД FireBird