Архивирование smeta.ru

**olhovik** Чт Фев 01, 2007 9:08

Hi All
Имеется локальная smeta.ru Настроен бэкап ежедневный в обед. Но появились проблемы:
1. При запущенной программе не проходит бэкап, это так задуманно? Есть способ обойти? Принудительно выбросить пользователя из базы то же вариант, но как реализовать?
2. Постоянно слетают настройки(раз в неделю в среднем), приходится заново регистрировать базу. Где хранятся настройки?
3. Не нашёл кнопочки провести бэкап и выключить компьютер, где искать? Из комстроки можно бэкап запустить?
4. Далее я собираюсь базу на выделенный сервер поставить, какова стратегия архивации при этом и какие подводные камни? Судя по тому, что при запущенной программе архив не создаётся - расскажите про способы борьбы с забывчивыми пользователями, как их отключать?

Ваша реклама

**Semenov** Чт Фев 01, 2007 14:01

Настроен бэкап ежедневный в обед. Но появились проблемы:
1. При запущенной программе не проходит бэкап, это так задуманно?

Перед тем, как сделать бэкап, утилита пытается проверить базу на наличие повреждений, что возможно только при отсутствии подключений к ней (особенность баз interbase/firebird);
бэкап производится только если база не содержит повреждений, чтобы избежать вожможных проблем в процессе восстановления

Есть способ обойти?

резервирование базы можно планировать в нерабочее время, например, как это рекомендуется при установке программы (в 3 часа ночи)

Принудительно выбросить пользователя из базы то же вариант, но как реализовать?

Этот вариант не реализован (бывают моменты, когда работу пользователя прерывать нежелательно, и пр.)

3. Не нашёл кнопочки провести бэкап и выключить компьютер, где искать?

не реализовано

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

http://forum.smeta.ru/viewtopic.php?t=495

продолжение следует...

**olhovik** Чт Фев 01, 2007 16:33

Semenov писал(а):
продолжение следует...

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

А попробуйте скопировать базу FAR'ом, а потом заархивировать :arrow:

300-400 Мб получится

**Слава** Чт Фев 01, 2007 17:18

Никеров Александр писал(а):А попробуйте скопировать базу FAR'ом, а потом заархивировать 300-400 Мб получится

Если вы это сделаете при активном подключении к базе - получите поломаную копию базы

Милослав!
Пробовал - работает. Нормальная база получается. Потом из неё объекты доставал не один раз.
Сначала копируем, потом архивируем.

**Kir** Чт Фев 01, 2007 19:58

Никеров Александр писал(а):Милослав!
Пробовал - работает. Нормальная база получается. Потом из неё объекты доставал не один раз.
Сначала копируем, потом архивируем.

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

**DarkGuest** Пт Фев 02, 2007 1:21

Слава писал(а):
Никеров Александр писал(а):А попробуйте скопировать базу FAR'ом, а потом заархивировать 300-400 Мб получится

Если вы это сделаете при активном подключении к базе - получите поломаную копию базы

И не факт, что при отключенных пользователях проблем не будет. ХЗ, что за настройки с кэшированием записи у используемой версии InterBase и у самой Windows.
То, что проблем не было при "копировании в лоб" - не означает, что их нет на самом деле. Возможно, что Вы просто не обращались к поврежденным страницам, или Вы просто не заметили, что из-за неверной ссылки в индексе были использованы вовсе не те данные.

Операции Backup/Restore для файлов баз InterBase настоятельно рекомендуется не только с целью сохранности в виде резервных копий. Это - необходимая профилактическая операция (выполняется перестройка индексов, сборка мусора, отбрасываются старые версии записей и т.д. и т.п.)

Backup - и никаких гвоздей! (а после еще и архивнуть RAR - ом можно - для компактности)

**Mikle** Пт Фев 02, 2007 8:44

Никеров Александр писал(а):Милослав!
Пробовал - работает. Нормальная база получается. Потом из неё объекты доставал не один раз.
Сначала копируем, потом архивируем.

Маша все время переходила дорогу на красный свет светофора и все было нормально. Но однажды ей не повезло ....

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

**Semenov** Пт Фев 02, 2007 9:45

И не факт, что при отключенных пользователях проблем не будет. ХЗ, что за настройки с кэшированием записи у используемой версии InterBase и у самой Windows.

По этому поводу можно не волноваться: если файл удалось переименовать, то гарантированно к нему нет подключенных процессов с правом записи в файл - смело копируйте, interbase не узнает, что его переименовали, и никто не сможет подключиться к базе пока вы ее копируете. Но вы правильно заметили - в этом случае вы получите точную копию базы со всеми накопившимися к этому моменту повреждениями. А по поводу кэширования записи у самой Windows - в Microsoft работают достаточно квалифицированные специалисты, чтобы позаботиться о достоверности копии файла несмотря на всевозможные процессы кэширования (за исключением разве что прямого доступа к секторам винчестера через порты ввода-вывода, но это не наш случай)

Backup - и никаких гвоздей! (а после еще и архивнуть RAR - ом можно - для компактности)

IB_Backup создает уже достаточно сильно сжатые копии базы (до 10 раз)

Kir писал(а):
Александр, не делайте так. Не копируйте базу при подключенных пользователях.

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

Mikle писал(а):
Александр, мораль сей басни такова: не делайте так - сбой произойдет обязательно

Согласен, но это оптимальный вариант при подключенных пользователях. Особенно когда их много и находятся далеко от сервера, и всё хотят "работать", а не тратить время на "ненужное" копирование базы.

**DarkGuest** Сб Фев 10, 2007 16:39

Semenov писал(а):...можно не волноваться: если файл удалось переименовать, то гарантированно к нему нет подключенных процессов с правом записи в файл - смело копируйте, interbase не узнает, что его переименовали, и никто не сможет подключиться к базе пока вы ее копируете...

1. Вах, какие ужасные советы. Прямо от Григория Остера.

Карл Маркс, Капитал писал(а):...do not use external proprietary backup utilities or file-copying tools such as WinZip, tar, copy, xcopy, etc., on a database which is running. Not only will the backup be unreliable, but the disk-level blocking used by these tools can corrupt a running database.

Т.е. Вы советует не просто копировать рабочую базу, а предварительно попробовать переименовать ее?

2. Вы уверены, что Win линейки NT гарантирует блокирование доступа к файлу в описанном Вами случае? Совершенно зря. (читайте К.Маркса. Тьфу, MSDN).
Не поверите - такие веселые сисадмины встречаются - у них и файлы переименовываются, и exe/dll - модули удаляются (загруженные)...

Тов. Киселев просто обязан провести контрольное занятие с последующим зачетом по поводу того, что нужно делать, чтобы разрушить файл БД.

Впрочем - покореженная клиентом база - хлеб для саппорта.

Semenov писал(а):...доступа к секторам винчестера через порты ввода-вывода...

Это как так? :shock:

**DarkGuest** Сб Фев 10, 2007 16:45

Никеров Александр писал(а):...но это оптимальный вариант при подключенных пользователях. Особенно когда их много и находятся далеко от сервера, и всё хотят "работать", а не тратить время на "ненужное" копирование базы.

Бэкап штатными средствами не требует отключения пользователей. (Ну, может быть, "подтормозит" их работу.)
Другое дело, что понимать под штатными средствами... :roll:

**Semenov** Пн Фев 12, 2007 9:31

DarkGuest писал(а):
Semenov писал(а):...можно не волноваться: если файл удалось переименовать, то гарантированно к нему нет подключенных процессов с правом записи в файл - смело копируйте, interbase не узнает, что его переименовали, и никто не сможет подключиться к базе пока вы ее копируете...

1. Вах, какие ужасные советы. Прямо от Григория Остера.

Карл Маркс, Капитал писал(а):...do not use external proprietary backup utilities or file-copying tools such as WinZip, tar, copy, xcopy, etc., on a database which is running. Not only will the backup be unreliable, but the disk-level blocking used by these tools can corrupt a running database.

Т.е. Вы советует не просто копировать рабочую базу, а предварительно попробовать переименовать ее?

Мои советы относятся исключительно на знаниях и опыте работы с серверами interbase/firebird и их базами данных. Копирование переименованного файла БД в данном случае гарантирует, что к ней не было подключений, а также что их не будет в процессе копирования. "Карл Маркс", т.е. MSDN, дает общие советы по работе со ВСЕМИ серверами БД при наличии активных подключений, не акцентируя внимания на особенностях работы каждого из них.

Имя:
Пароль: