Галактика в вопросах и ответах

спасибо за ответ, значит так и есть, бэкап горячий

У одного из клиентов база на Оракле разворачивалась из бэкапа в боевую готовность около 8 часов. Объем самой базы тогда был порядка 80 гиг, если я правильно запомнил со слов админа. К тому времени эксплуатация Галактики велась уже несколько лет.

Политика резервирования и восстановления - это вообще-то достаточно важный и ответственный момент в рамках функционирования Организации.
При разработке Политики и Стратегии "этого дела" должны быть учтены определенные факторы и требования со стороны Организации на предмет обеспечения нужных характеристик процесса и результата
Упомянутые требования определяют что и как должно быть сделано в вопросах создания резервных копий.

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

К примеру: если Организация не допускает простоя и потери информации в своей работе, то и мероприятия по обеспечению такого режима должны быть соответствующими - кластерные конфигурации, системы хранения высокой надежности, Data Gard, стендбай или иные технологии.

Как вариант "отвязки" рабочего процесса от процесса создания резервной копии БД можно рассмотреть стендбай сервер, с которого и делается резервная копия. При этом основной сервер в это время вполне себе реально может обслуживать пользователей - таким образом основной сервер не будет иметь простоев по причине создания резервных копий.

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

Так что вопрос создания резервных копий приходится решать индивидуально в каждой организации, учитывая пожелания, наличие технических средств и понимание важности этого процесса со стороны руководства

P.S. все вышесказанное об БД на ORACLE, хотя и в части иных СУБД наверняка имеются соотвествующие средства.

budv писал(а):у нас в организации (внедрение еще не закончено) базу из бэкапа (оракл) разворачивают от 18 часов и более

Ужасы какие-то.
БД - 47Gb, час - забрать с ленты, час - развернуть. Это, конечно, если восстановление на тот же сервер и с ним всё в порядке.

Быстрый способ бэкапа или переноса на другую машину СУБД Oracle + БД:
1.Останавливаем службы Oracle и переводим их в ручной режим запуска.
2. Сохраняем ветки реестра, кот. относятся к Oracle
- HKLM\SW\Oracle;
- SysWOW64\SW\Oracle (для Win64);
- службы Oracle: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services - напр. экземпляр Oracle и Listener.
3. Сохраняем папки и файлы Oracle и БД, не забывая по каким путям они находились (напр. C:\Program Files\Oracle; D:\Oracle).
4. Сохраняем значения переменной среды Path, кот. относятся к Oracle.

На новой машине или на этой же после переустановки Windows:
1.Копируем папки и файлы Oracle по таким же путям КАК БЫЛО РАНЬШЕ.
2.Заносим сохраненные значения в переменную среды Path.
3.Импортируем данные реестра.
4.Перегружаемся и запускаем службы Oracle.

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

Начинающий путь писал(а):Хотелось бы увидеть еще документ "Резервное копирование и восстановление базы данных (MSSQL)"

Может будет интересна статья на Хабре

Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server
В ходе проведения презентаций о бэкапах и восстановлении баз данных SQL Server, обычно задаются два типа вопросов. Первые задаются прямо по ходу презентации из зала, вторые задаются уже после, в приватной беседе. Эти, «приватные» вопросы, зачастую более интересны и я попробую дать ответы на наиболее сложные и интересные из них, вместо того чтобы писать ещё одну статью о том как вы должны делать бэкапы, или почему вы должны делать бэкапы, или даже почему вы должны проверять свои бэкапы (но вы и вправду должны проверять свои бэкапы).
Читать полностью