7.7 Стратегия резервного копирования 1Сv7.7+MS SQL 2000

Тема в разделе "Общие вопросы "1С:Предприятие 7.7"", создана пользователем |R|U|D|E|N|, 9 янв 2011.

  1. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    Добрый день, посетители форума.
    Прошу не пинать сильно, т.к ответа на свой вопрос в поиске по вашему форуму я не нашел.


    Вопрос не столько технический сколько организационный.

    Есть сервер под упровлением Win2k3 Enterprise sp1. На сервере стоит стоит 1Сv7.7 а под ней MS SQL 2000 sp4. Необходимо выполнять резервное копирование всего этого хозяйства.
    На SQL-Сервере 8 баз, размером от 500-3000Мб. Конфигурация 1с всех баз в сумме весит около 300мб.
    Пользователи работают с 1с только днем!

    В сети, для бекапа остальных серверов и рабочих станций используется Acronis True Image Ent. Server ECHO 9.7.Может это как то поможет делу...

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

    На тикущий момент, вижу несколько вариантов.

    1. Создовать каждую ночь резервные копии sql-баз средствами Enterprise Manager и Acronis'ом бекапить конфиг 1с + несколько раз в день бекапить журнал транзакций.

    2. Каждую ночь выполнять выгрузку информационных баз средствами конфигуратора(скрипта). Мне кажется что это не эффективно и дольше по времени.

    3. Ночью останавливать SQL-Сервер и Acronis'ом бекапить каталог SQL-сервера со всеми базами + каталог с конфигурацией 1с.

    Навернека возможны и другие варианты...

    Какой же из вариантов по Вашему наиболее эфективен, в плане 100% востановления после сбоя?
  2. Itsys
    Offline

    Itsys Опытный в 1С

    Регистрация:
    3 янв 2010
    Сообщения:
    1.394
    Симпатии:
    0
    Баллы:
    26
    Первый вариант вполне нормальный. Только делаем немного по другому, бекап SQL кладется в папку БД, а потом папка архивируется, таким образом получается цельный слепок и БД и конфигурации.
  3. r-d-v2008
    Offline

    r-d-v2008 Опытный в 1С

    Регистрация:
    16 сен 2010
    Сообщения:
    272
    Симпатии:
    0
    Баллы:
    26
    Действительно первый вариант удобнее единственое что могу добавить это можно использовать программу Backup32 создает бекапы всего в том числе и баз SQL
  4. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    Согласен, первого способа вполне достаточно. Он можно сказать почти класический)

    Но мне намного проще использовать акронис(3-й вариант). Создал задание в котором бекапятся каталог с sql-базами и каталог с конфигурацией 1c. На выходе я получаю так же один файл(архив .tib) хорошенько сжатый и при этом старые архивы автоматически удаляются. И бекапы он делает на любой сервер в сети.
    И главное доверяю я ему даже больше чем sql-бекапам.


    Вопрос только в том, что если скуль упадет и будет необходимость воссоздать базы заново помогут ли мне мои копии базы скуля?

    Тойсть востановить базы из собственных бекапов скуля не проблемма. А как востановить базы если у меня в бекапах acronisa фактически только файлы баз скуля. Смогу я востановить базы?
  5. Itsys
    Offline

    Itsys Опытный в 1С

    Регистрация:
    3 янв 2010
    Сообщения:
    1.394
    Симпатии:
    0
    Баллы:
    26
    Да, файлы баз SQL всегда можно приатачить к базе или создать на основе их новую, только надо иметь оба файла, насколько я помню.
  6. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    В этом случае (если у вас бэкапится и файл данных и журнал транзакций), вы сможете восстановить БД к состоянию на момент бэкапа, т.е. приаттачите распакованные из архива файлы.

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

    Смотрите сами, какое время восстановления и какой объем потерянной информации для вас допустим.
  7. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    Спасибо мужчины!
    Очень Вы мне помогли.

    Получил ответы на все волнующие меня вопросы. Буду думать.

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


    Сейчас хочу попробывать Acronis recovery for MS SQL server. Очень мощьный, промышленный софт. Можно бекапить сразу все базы вместе, востанавливать по отдельности, сжимать как хочешь и прочих возможностей масса.

    Но пока остановлюсь на 3-м варианте.

    Всем огромное спасибо!
  8. Itsys
    Offline

    Itsys Опытный в 1С

    Регистрация:
    3 янв 2010
    Сообщения:
    1.394
    Симпатии:
    0
    Баллы:
    26
    Так можно же одним планом несколько баз бекапить...
  9. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    Интиресно.
    А бекапя несколько баз, он помещает их в один файл или каждую базу в отдельый?
    Тойсть при таком плане, возможно востановление только одной базы например а не всех сразу?
  10. BVB_berserk
    Offline

    BVB_berserk Опытный в 1С

    Регистрация:
    30 янв 2009
    Сообщения:
    162
    Симпатии:
    0
    Баллы:
    26
    Каждый в отдельный файл бэкапа, восстанавливать базы можно независимо друг от друга. Более того, возможно настроить различные оповещения, если вдруг при выполнении плана обслуживания произойдут сбои. MS SQL интересная тема, умеет многое, надо только знать все его возможности :)
  11. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    Думал что тема для меня уже закрыта но...

    Резко изменилось требование к бекапам!

    Если до этого я планировал останавливать сеть и спокойно бекапить и скуль и конфиг 1с то сейчас мне поставленно требование не останавливать сервер не на минуту..

    Со скулем я разобрался. бекапить буду c помощью Acronis recovery fog sql - очень мощьный софт мне очень понравился.


    Вопрос заключается в том как бекапить конфиг 1с не прикращая обращения к серверу??
    Тойсть с большей вероятностью несколько клиентов будут висеть + вечно висящие сессии в терминале.
    Как быть в такой ситуации?

    Я так понемаю для успешного востановления необходимо чтоб бекапы скуля и конфига 1с были сделанны в одно время? И откатывать их надо тоже вмесе?
  12. Itsys
    Offline

    Itsys Опытный в 1С

    Регистрация:
    3 янв 2010
    Сообщения:
    1.394
    Симпатии:
    0
    Баллы:
    26
    Работающие пользователи на работу бекапа влиять не должны, т.к. данные в папке с базой не меняются. Бекапы должны быть не в одно время, а в период чтобы база данных соответствовала ее конфигурации, т.е. между моментом бекапа БП SQL и бекапом папки с файлами не должны вноситься изменения в конфигурацию базы данных.
  13. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    А если будут внесены изминения, как это скажется на процедуре востановления?

    И что Вы посоветуете в случае если мне нужна хоть не 100% но 99% уверенность в последующем востановлении?
  14. Itsys
    Offline

    Itsys Опытный в 1С

    Регистрация:
    3 янв 2010
    Сообщения:
    1.394
    Симпатии:
    0
    Баллы:
    26
    Если изменения не затрагивают структуру таблиц, то ничего страшного не произойдет, если затрагивает, после восстановления надо будет сделать проверку логической целостности.

    Поставьте создание бекапа SQL в 3 часа ночи, а файлов в 4, врят ли в это время кто-то будет менять конфигурацию. А еще лучше прописать в какой-нибудь регламент вписать, что изменять конфигурацию с 3 до 4 ночи нельзя.
  15. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    Понял Вас. Тойсть это не очень критично, тем более что я уверен, конфигурацию менять некто не будет.
    Я могу просто бекапить конфиг акронисом как группу файлов?
  16. dianofob
    Offline

    dianofob (-_-)y-.o0O

    Регистрация:
    3 июл 2009
    Сообщения:
    711
    Симпатии:
    0
    Баллы:
    26
    Поделюсь своими соображениями, я настаривал бэкап базы средствами sql сервера, в связи с тем что часто меняется конфигурация, несколько раз в день проводится фул бэкап, и каждые полчаса диференциальные. Несколько раз фул бэкап - в связи с тем что после изменения структуры базы перестают создаваться дифференциальные. На шедулере стоят батники которые жмут бэкапы.
    Файлы конфигурации так же можно батником поставить на планировщик, а можно и просто его запускать перед изменениями конфигурации (честно говоря просто так автоматом бэкапить их не вижу смысла).
    Кроме того рекомендую делать в ручную фул бэкап перед изменением структуры базы средствами sql сервера, + бэкап конф, в противном случае базу можно не поднять вообще.
    Ну и плюс на касеты производятся ежедневные бэкапы акронисом, папок с базой, ее бэкапами и конфой. Не знаю что и как настраивал наш админ, но акронис бэкапит базу без остановки sql-сервера.
  17. TopicStarter Overlay
    |R|U|D|E|N|
    Offline

    |R|U|D|E|N|

    Регистрация:
    9 янв 2011
    Сообщения:
    17
    Симпатии:
    0
    Баллы:
    1
    Ваших ответов мне вполне достаточно для организации автоматизированного бекапа!

    Спасибо Вам всем!

Поделиться этой страницей