Как развернуть базу 1с из sql бэкапа

Какие могут быть сложности при восстановлении бэкапа базы 1С?

При восстановлении бэкапа (архивной копии) например базы 1С, которая работает на сервере под управлением MS SQL Server, может возникнуть следующая интересная проблема. У Вас есть архивная копия базы и Вы пытаетесь ее загрузить в новую пустую конфигурацию, которая только что была создана с помощью мастера управления списком информационных баз 1С на сервере 1С и сервере баз данных. Для управления база данных работающих на системе Microsoft SQL Server часто используется утилита под названием Microsoft SQL Server Management Studio. С помощью которой можно через пользовательский интерфейс, не используя скрипты/консольные команды, развернуть архив базы.

Путь к восстановлению бэкапа

Окно восстановления базы Закладка Основная

В списке серверов выбираем необходимый нам сервер БД, дальше базу данных. Щелкнув по наименованию нужной базы выбираем — Tasks — Restore Database. У нас откроется окно восстановления базы Restore Database — . На закладке General укажем откуда нам необходимо восстановить базу (из файла бэкапа или из другой базы, работающей на сервере), и в какую базу восстановим архив. Перейдя на закладку Options установим флаг — Overwrite an existing database (WITH REPLACE). Жмем кнопку ОК для запуска процесса восстановления.

SQL Managment Studio Ошибка при попытке восстановить базу

И получаем ошибку: «Error — Exclusive access could not be obtained because the database is in use».

Все что нам нужно сделать это установить флаг «close existing connections to destination database» на закладке Options в группе «Server connections», которая позволяет разорвать соединение с устанавливаемое сервером 1С. Но данный флаг может быть недоступен. Обойти это ограничение можно следующим образом.

Весь тот же путь к восстановлению базы мы проходим щелкнув правой кнопкой мыши по разделу Databases находящийся в разделе с сервером дерева объектов в левой части экрана. И выбрав непосредственно «Restore database. «. Далее открывается знакомое нам окно восстановления и мы сразу же переходим на закладку Options, где будет доступен флаг для завершения всех соединений с данной базой, непосредственно перед восстановлением архивной копии, сервером баз данных. И после этого на основной закладке мы можем выбрать в какую из существующих баз нам нужно восстановить архивную копию.

Восстановление базы данных 1С Бухгалтерия 8.3 из бэкапа

Основная ИБ «полетела», удалили базу 1С, или понадобился отчет по остаткам из архива – как восстановить базу 1С? Очень просто, если вы пользовались нашими рекомендациями и формировали резервные копии (бэкапы) «1С:Бухгалтерия 8.3»

Напомним, что Закон о бухучете* предписывает хранить документы бухгалтерского учета не менее пяти лет после отчетного года, так что и формировать бэкапы, и восстановить базу 1С из бэкапа – наша законная обязанность.

Как восстановить базу 1С из архива формата dt

Допустим, что у вас на рабочем ПК имеются резервные копии вашей базы, формат dt. Создаем пустую папку с говорящим названием, чтобы сразу было понятно, когда она создана и что в ней хранится.

Запускаем программу, в окне нажимаем «Добавить» для того чтобы включить в список ту самую созданную (пустую) папку. В нее будем загружать бэкап, чтобы восстановить базу 1С из резервной копии.

В окне «Добавление информационной базы/группы» выбираем первый пункт – «Создание новой информационной базы». Указываем имя восстанавливаемой ИБ, выбираем тип расположения, нажимаем «Далее».

Указываем маршрут до той пустой папки, которая была создана в начале, нажимаем «Далее»:

Вариант аутентификации, т.е. определения пользователя, и основного режима запуска оставим «Выбирать автоматически», поле «Версия 1С:Предприятия» оставим без заполнения:

В режиме конфигуратора запускаем пустую, но уже подключенную ИБ.

Выбрать из главного меню «Администрирование» — «Загрузить информационную базу. »:

Далее указываем системе на резервную копию, из которой будем реанимировать ИБ.

Появится варнинг о том, что данные будут перезаписаны, но, поскольку речь идет о том, чтобы восстановить базу 1с из архива в пустую, специально созданную ИБ, то ничего страшного. Соглашаемся, нажав «Да».

По итогам операции появится уведомление о том, что:

• ИБ загружена успешно;
• конфигуратор закрыт,

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

После всего проделанного закрываем конфигуратор, запускаем ИБ в обычном режиме. Работаем с энтузиазмом.

Можно ли восстановить базу 1С из бэкапа формат .zip?

Конечно, причем не только из зазипованных бэкапов можно восстановить базу данных 1С, но и из архивов формата .rar и любимого многими .7z. Находим ваш файл в указанных форматах, дважды щелкаем и проверяем содержимое – там обязательно должен присутствовать файл бэкапа, т.е. 1Cv8.1CD.

Далее процесс во многом аналогичен вышеописанному, за некоторыми деталями. Первым делом создаем пустую папку с говорящим названием и лучше датой, а потом – внимание! – не помещаем, а распаковываем в нее содержимое нашего архива. Надо, чтобы получилось нечто подобное:

Не исключено, что у вас могут и другие файлы появиться – это нестрашно, главное, чтобы файл 1Cv8.1CD был на месте. Далее просто подключите эту новую базу, как было расписано выше.

Как восстановить базу 1с sql

Теперь рассмотрим порядок действий, который поможет «починить» конфигурацию с помощью резервной копии базы «1С» на MS SQL. Входим в список программ, запускаем «SQL Server Menegement Studio», указав имя логин-пароль, командуем «Соединить»:

Открывается список баз, находим ту, которую желаем восстановить.

Щелкнув правой клавишей, выбираем последовательно «Задачи» — «Восстановить» — «База данных…»

Тут есть важный момент, даже три:

• в поле «Из базы данных» должна значится ваша БД;
• в поле «К моменту времени» должно быть проставлено «Самый последний»;
• в перечне «Выберите резервные наборы данных для восстановления» должен стоять флажок.

Все верно – нажимаем «ОК».

Запустится процесс восстановления базы, дождитесь его окончания. Если все пройдет успешно, то SQL Server Menegement Studio сообщит об этом:

Нажимаем «ОК». У нас получилось восстановить базу 1С SQL, можно приступать к работе, только не забывайте регулярно делать бэкапы и тестировать их на работоспособность.

• Файл базы данных 1С 8.3 поврежден – что делать?
• 1С Фреш синхронизация – настройка синхронизации данных с локальной базой
• Как скачать, установить и настроить тонкий клиент для 1С Фреш (1С Fresh)?
• Как добавить новую организацию в 1С 8.3 ЗУП?
• Как выгрузить базу данных из облака 1с Фреш (1 СFresh) на локальный компьютер?

ТОП ПРОДАЖ

• 1С:Бухгалтерия 8
• 1С:Управление нашей фирмой 8
• 1С:Управление торговлей 8
• 1С:Управление предприятием 2
• 1С:ЗУП 8
• 1C:Учет путевых листов и ГСМ
• 1С:Учет в управляющих компаниях
• Электронные поставки 1С

Облачные сервисы

• 1С:Фреш
• 1С:Готовое рабочее место
• 1С:ЭДО
• Маркировка товаров
• 1С:Отчетность
• 1C:Товары
• 1C-Ритейл Чекер

Пошаговая инструкция по процедуре восстановления базы SQL. SQL Server 2008

• 
• 
• 
• 
• 

1. Запустить утилиту SQL Server Management Studio (из состава MS SQL Server).
1. Подключиться к серверу под учетной записью администратора или владельца БД (можно использовать встроенную учетную запись «sa», пароль для которой задавался при установке SQL Server, либо выбрать вариант «Проверка подлинности Windows» в случае если текущий пользователь сеанса Windows обладает правами администратора в SQL Server, а также использовать любую другую учетную запись SQL Server или Windows, которая включена в роль «db_owner» восстанавливаемой базы при наличии таковой или серверную роль «dbcreator»):

1. Нажать правой кнопкой мыши на разделе «Database» и выбрать в меню «Restore — > Database» как показано на рисунке:





1. На странице «General» выполнить следующие действия:
   • В поле «To database» ввести имя для восстанавливаемой базы (если будет указано имя существующей базы, то это эквивалентно тому, что сначала полностью удалить существующую базу и затем восстановить из резервной копии новую базу, т.е. все данные существующей базы будут утеряны!);
   • Установить переключатель «From device» и указать путь к файлу резервной копии, нажав кнопку «…»;
   • Установить галочку «Restore» в нужной строке (которых может быть несколько, если один файл *.bak содержит несколько резервных копий базы):



1. На странице «Options» установить галочку «Overwrite the existing database (whith replase)» и проверить пути в списке «Restire the database files as» (должны указывать на существующую папку на SQL-сервере, к которой предоставлены права на запись – пути по умолчанию обычно должны заканчиваться папкой DATA, а не просто MSSQL):



Нажать кнопку «ОК».

Примечание. После восстановления базы данных на другой версии SQL Server рекомендуется в свойствах базы данных переключить параметр «Уровень совместимости» на последнюю версию.

Кроме того, после переноса базы на любой новый SQL-сервер придется заново настроить авторизацию и регулярное резервное копирование в соответствии с инструкцией по установке сетевой версии соответствующей программы.

Резервное копирование 1С средствами MS SQL.

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

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

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

Базовая информация о хранении и обработке данных MS SQL

Данные в MS SQL обычно хранятся в файлах данных (далее ФД — сокращение не общеупотребимое, в данной статье будет еще несколько не очень распространённых сокращений) с расширениями mdf или ndf. Кроме этих файлов есть еще журналы транзакций (ЖТ), которые хранятся в файлах с расширением ldf. Нередко начинающие администраторы безответственно и легкомысленно относятся к ЖТ, как в отношении производительности, так и в отношении надёжности хранения. Это очень грубая ошибка. На самом деле, скорее наоборот, если есть надёжно функционирующая система резервного копирования и на восстановление системы можно выделить много времени, то можно хранить данные на быстром, но крайне ненадёжном могут попадать на диск до фиксации транзакции. То есть в общем случае, при активной работе ФД содержит разрозненные куски недописанных данных и незавершённых транзакций, для которых неизвестно, будут ли они отменены или зафиксированы. Есть специальная команда «

Чтобы справиться с этим хаосом нам как раз и нужен ЖТ. В него пишутся следующие события:

• Информация о старте транзакции и её идентификатор.
• Информация о факте фиксации или отмене транзакции.
• Информация обо всех изменениях данных в ФД (грубо говоря, что было и что стало).
• Информация об изменении самого ФД или структуры базы данных (увеличение файлов, уменьшение файлов, выделение и освобождение страниц, создание и удаление таблиц и индексов)

Вся эта информация пишется с указанием идентификатора транзакции в которой она произошла и в достаточном объёме чтобы понять как из состояния до этой операции перейти к состоянию после этой операции и наоборот (исключение — модель восстановления с неполным протоколированием).

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

select * from ::fn_dblog(null,null)

Из-за того, что жёсткие диски значительно эффективнее работают с последовательной записью, чем с хаотичным потоком команд на чтение и запись и из-за того, что команды SQL будут ждать момента окончания записи в ЖТ, возникает следующая рекомендация:

Если есть хоть малейшая возможность, то в продуктовой среде ЖТ должны располагаться на отдельных (от всего остального) физических носителях, желательно с минимальным временем доступа для последовательной записи и с максимальной надёжностью. Для простых систем вполне подойдёт RAID-1.

Если транзакция отменяется, то все уже внесённые изменения сервер вернёт в предыдущее состояние. Именно поэтому

Отмена транзакции в MS SQL Server обычно длится сопоставимо с суммарной длительностью операций изменения данных самой транзакции. Старайтесь не отменять транзакции или принимать решение об отмене как можно раньше.

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

Что происходит когда ЖТ дошёл до конца файла? Всё просто — если есть освобождённое место в начале, то он начнёт писать в свободное место в начале файла до занятого места. Как закольцованная магнитная лента. Если места в начале нет, то сервер обычно попытается расширить файл журнала транзакций, при этом для сервера выделенный новый кусок является новым виртуальным файлом журнала транзакций, которых в физическом файле транзакций может быть много, но это уже к резервному копированию относится мало. Если у сервера не получится расширить файл (закончилось место на диске или запрещено настройками расширять ЖТ), то текущая транзакция отменится с ошибкой 9002.

Упс. А что же надо сделать чтобы место в ЖТ всегда было? Вот тут мы подошли к системе резервного копирования и к моделям восстановления. Для отмены транзакций и для восстановления корректного состояния сервера в случае внезапного выключения необходимо хранить в ЖТ записи, начиная с момента старта самой ранней из открытых транзакций. Этот минимум пишется и хранится в ЖТ обязательно. Вне зависимости от погоды, настроек сервера и желания админа. Сервер не может допустить, чтобы этой информации не было. Поэтому, если открыть в одном сеансе транзакцию, а в других выполнять разные действия, то журнал транзакций может неожиданно закончиться. Самую раннюю транзакцию можно выявить командой

Модель Bulk logged для баз 1С использовать почти бессмысленно, поэтому дальше мы её не рассматриваем. А вот выбор между Full и Simple расмотрим подробнее в следующей части.

Для любознательных — ссылки на русскоязычную документацию, которая более полно описывает работу журнала транзакций:

• Структура журнала транзакций
  • Логическая архитектура журнала транзакций
  • Физическая архитектура журнала транзакций
  • Контрольные точки и активная часть журнала
  • Журнал транзакций с упреждающей записью
  • Общие сведения о журналах транзакций
  • Модели восстановления и управление журналом транзакций
    • Обзор моделей восстановления
    • Выбор модели восстановления для базы данных
    • Модели восстановления системных баз данных
    • Усечение журнала транзакций
    • Управление размером файла журнала транзакций
    • Факторы, могущие вызвать задержку усечения журнала
    • Создание резервных копий журналов транзакций
    • Резервные копии заключительного фрагмента журнала
    • Применение резервных копий журнала транзакций

    Принцип действия резервного копирования в моделях восстановления Simple и Full

    По типу формирования резервные копии бывают трёх видов:

    • Full (Полная)
    • Differential (Дифференциальная, разностная)
    • Log (Резервная копия журналов транзакций, учитывая, то, насколько часто этот термин используется, будем сокращать до РКЖТ)

    Здесь надо не запутаться: полная модель восстановления и полная резервная копия — существенно разные вещи. Для того чтобы их не спутать, ниже я буду использовать английские термины для модели восстановления и русскоязычные для видов резервных копий.

    Полная и дифференциальная копия работают одинаково для Simple и Full. Резервная копия журналов транзакций полностью отсутствует в Simple.

    Полная резервная копия

    Позволяет восстановить состояние базы данных на некоторый момент времени (на тот в который начато формирование резервной копии). Состоит из постраничной копии используемой части файлов данных и активного куска журнала транзакций за то время пока формировалась резервная копия.

    Разностная резервная копия

    Хранит страницы данных, изменившиеся с момента последней полной резервной копии. При восстановлении нужно сначала восстановить полную резервную копию (в режиме NORECOVERY , примеры будут приведены ниже), потом можно к получившейся «заготовке» применить любую из последующих разностных копий, но, конечно только из тех, которые сделаны до следующей полной резервной копии. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии.

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

    РКЖТ

    Содержит копию ЖТ за некоторый период. Обычно с момента прошлой РКЖТ до момента формирования текущей РКЖТ. РКЖТ позволяет из восстановленной в режиме NORECOVERY копии на любой момент времени, входящий в период восстанавливаемой копии ЖТ, восстановить состояние на любой последующий момент времени, входящий в интервал восстанавливаемой резервной копии. При формировании резервной копии со стандартными параметрами, место в файле журнала транзакций высвобождается (до момента последней открытой транзакции).

    Очевидно, что РКЖТ не имеет смысла в модели Simple (тогда ЖТ содержит лишь информацию с момента последней незакрытой транзакции).

    При использовании РКЖТ возникает важное понятие — непрерывная цепочка РКЖТ. Эту цепочку может прервать либо потеря некоторых резервных копий этой цепочки, либо перевод базы данных в Simple и обратно.

    Внимание: набор РКЖТ по сути бесполезен, если он не является непрерывной цепочкой, причем момент начала последнего успешного полного или разностного резервного копирования должен быть внутри периода этой цепочки.

    Частые заблуждения и мифы:

    • «РКЖТ содержит данные журнала транзакций от момента предыдущего полного или разностного бэкапа». Нет, это не так. РКЖТ содержит и на первый взгляд бесполезные данные между предыдущей РКЖТ и последующим полным бэкапом.
    • «Полный или разностный бэкап должны приводить к освобождению места внутри журнала транзакций». Нет, это не так. Полный и разностный бэкап не трогают цепочку РКЖТ.
    • ЖТ нужно перидически чистить вручную, уменьшать, шринкать. Нет, не надо и даже наоборот — нежелательно. Если освобождать ЖТ между РКЖТ, то будет нарушена цепочка РКЖТ, нужная для восстановления. А постоянные уменьшения/расширения файла приведут к его физической и логической фрагментации.

    Как это работает в simple

    Пусть есть база данных в 1000 ГБ. Каждый день база прирастает на 2 ГБ, при этом меняется 10 ГБ старых данных. Сделаны следующие резервные копии

    • Полная копия F1 от 0:00 1 февраля (объём 1000 ГБ, сжатие для простоты картины не учитываем)
      • Разностная копия D1.1 от 0:00 2 февраля (объём 12 ГБ)
      • Разностная копия D1.2 от 0:00 3 февраля (объём 19 ГБ)
      • Разностная копия D1.3 от 0:00 4 февраля (объём 25 ГБ)
      • Разностная копия D1.4 от 0:00 5 февраля(объём 31 ГБ)
      • Разностная копия D1.5 от 0:00 6 февраля (объём 36 ГБ)
      • Разностная копия D1.6 от 0:00 7 февраля (объём 40 ГБ)
      • Разностная копия D2.1 от 0:00 9 февраля (объём 12 ГБ)
      • Разностная копия D2.2 от 0:00 10 февраля (объём 19 ГБ)
      • Разностная копия D2.3 от 0:00 11 февраля (объём 25 ГБ)
      • Разностная копия D2.4 от 0:00 12 февраля(объём 31 ГБ)
      • Разностная копия D2.5 от 0:00 13 февраля (объём 36 ГБ)
      • Разностная копия D2.6 от 0:00 14 февраля (объём 40 ГБ)

      При помощи этого набора мы можем восстановить данные на момент 0:00 любого из дней с 1 по 14 февраля. Для этого нам нужно взять полную копию F1 для недели 1-7 февраля или полную копию F2 для 8-14 февраля, восстановить её в режиме NORECOVERY и потом применить разностную копию нужного дня.

      Как это работает в full

      Пусть у нас есть такой же набор резервных полных и разностных резервных копий, как в предыдущем примере. В дополнение к этому есть следующие РКЖТ:

      • РКЖТ 1 за период с 12:00 31 января по 12:00 2 февраля (около 30 ГБ)
      • РКЖТ 2 за период с 12:00 2 февраля по 12:00 4 февраля (около 30 ГБ)
      • РКЖТ 3 за период с 12:00 4 февраля по 12:00 6 февраля (около 30 ГБ)
      • РКЖТ 4 за период с 12:00 6 февраля по 12:00 7 февраля (около 30 ГБ)
      • РКЖТ 5 за период с 12:00 8 февраля по 12:00 10 февраля (около 30 ГБ)
      • РКЖТ 6 за период с 12:00 10 февраля по 12:00 12 февраля (около 30 ГБ)
      • РКЖТ 7 за период с 12:00 12 февраля по 12:00 14 февраля (около 30 ГБ)
      • РКЖТ 8 за период с 12:00 14 февраля по 12:00 16 февраля (около 30 ГБ)
      1. Размер РКЖТ будет примерно постоянным.
      2. Резервные копии мы можем делать реже, чем разностные или полные, а можем и чаще, тогда они будут меньше по размеру.
      3. Теперь мы можем восстановить состояние системы на любой момент с 0:00 1 февраля, когда у нас есть самая ранняя полная копия по 12:00 16 февраля.

      В самом простом случае нам для восстановления понадобятся:

      1. Последняя полная копия до момента восстановления
      2. Последняя разностная копия до момента восстановления
      3. Все РКЖТ, от момена последней разностной копии до момента восстановления

      Пример. Для восстановления на 13:13:13 10 февраля нам понадобятся:

      • Полная копия F2 от 0:00 8 февраля
      • Разностная копия D2.2 от 0:00 10 февраля
      • РКЖТ 6 за период с 12:00 10 января по 12:00 12 февраля

      Сначала будет восстановлена F2, потом D2.2, потом РКЖТ 6 до момента 13:13:13 10 февраля. Но существенное преимущество Full модели в том, что у нас появляется выбор — использовать последнюю полную или разностную копию или НЕ последнюю. Например, если бы обнаружилось, что копия D2.2 была испорчена, а нам надо восстановить на момент до 13:13:13 10 февраля, то для модели Simple это бы значило, что мы можем восстановить данные только на момент D2.1. При Full — «DON’T PANIC», у нас есть следующие возможности:

      1. Восстановить F2, потом потом D2.1, потом РКЖТ 5, потом потом РКЖТ 6 до момента 13:13:13 10 февраля.
      2. Восстановить F2, потом РКЖТ 4, потом РКЖТ 5, потом потом РКЖТ 6 до момента 13:13:13 10 февраля.
      3. Или вообще восстановить F1 и прогнать все РКЖТ до РКЖТ 6 до момента 13:13:13 10 февраля.

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

      А теперь представим, что мы очень хитрые. И за пару дней до сбоя (13:13:13 10 февраля.) знаем, что сбой будет. Мы восстанавливаем на соседнем сервере базу данных из полной резервной копии, оставляя возможность донакатывать последующие состояния разностными копиями или РКЖТ, т. е. оставили в режиме NORECOVERY . И каждый раз сразу после формирования РКЖТ применяем её к этой резервной базе, оставляя в режиме NORECOVERY . Ого! Да ведь на восстановление базы данных у нас теперь уйдёт всего 10-15 минут, вместо того, чтобы восстанавливать огромную базу! Поздравляю, мы заново изобрели механизм доставки журналов, один из способов снижения времени простоев. Если так передавать данные не раз в период, а постоянно, то получится уже зеркалирование, причем если база-источник ждёт пока база-зеркало обновится, то это синхронное зеркалирование, если не ждёт, то асинхронное.

      Подробнее о средствах высокой доступности можно прочтитать в справке:

      • Высокий уровень доступности (компонент Database Engine)
        • Общие сведения о решениях с высоким уровнем доступности
        • зеркальное отображение базы данных
        • Доставка журналов
        • Высокий уровень доступности. Взаимодействие и совместная работа

        Прочие аспекты резервного копирования

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

        Файловые группы

        1С:Предприятие по сути не умеет работать с файловыми группами. Есть единственная файловая группа и всё. На самом деле программист или администратор базы данных MS SQL способен некоторые таблицы, индексы или даже куски таблиц и индексов положить в отдельные файловые группы (в простейшем варианте — в отдельные файлы). Это нужно либо для того, чтобы ускорить доступ к каким-то данным (положив на очень быстрые носители), либо наоборот, пожертвовав скоростью поместить на более дешёвые носители (например, малоиспользуемые но объёмные данные). При работе с файловыми группами есть возможность делать их резервные копии отдельно, также отдельно можно и восстанавливать, но нужно учесть, что все файловые группы придётся «догнать» до одного момента накатыванием РКЖТ.

        Файлы данных

        Если помещением данных в разные файловые группы управляет человек, то когда внутри файловой группы есть несколько файлов, то данные по ним распихивает MS SQL Server самостоятельно (при равном объёме файлов — постарается равномерно). С прикладной точки зрения это используется для распараллеливания операций ввода-вывода. А с точки зрения резервных копий есть другой момент. Для очень больших баз данных в эпоху «до SQL 2008» была типичной проблема выделить непрерывное окно для полной резервной копии, да и диск-приемник для этой резервной копии мог просто её не вместить. Самым простым способом в этом случае было делать резервную копию каждого файла (или файловой группы) в своё окно. Сейчас, с активным распространением сжатия резервных копий эта проблема стала меньше, но всё же этот прием можно иметь в виду.

        Сжатие резервных копий

        В MS SQL Server 2008 появилась супер-мега-ультра возможность. Отныне и навсегда резервные копии могут быть компрессированными при формировании на лету. Это уменьшает размер резервной копии БД 1С в 5-10 раз. А учитывая, что обычно производительность дисковой подсистемы является узким местом СУБД, то это даёт не только снижение стоимости хранения, но и еще мощное ускорение резервного копирования (хотя и повышается нагрузка на процессоры, но обычно процессорные мощности вполне достаточны на сервере СУБД).

        Если в версии 2008 эта возможность была только для Enterprise редакции (которая стоит очень дорого), то в 2008 R2 эта возможность отдана в версию Standard, что сильно радует.

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

        Один файл бэкапа — много внутренностей

        На самом деле резервная копия это не просто файл, это достаточно сложный контейнер, в котором может храниться много резервных копий. У этого подхода очень древняя история (я лично её наблюдаю с версии 6.5), но на текущий момент для администраторов «обычных» баз данных, особенно баз данных 1С, нет каких-либо серьёзных причин не использовать подход «одна резервная копия — один файл». Для общего развития полезно изучить возможность складывать в один файл несколько резервных копий, но использовать её скорее всего не придётся (или если и придётся, то разбирая завалы горе-администратора, который эту возможность неквалифицированно использовал).

        Несколько зеркальных копий

        В SQL Server есть еще одна замечательная возможность. Можно резервную копию формировать параллельно в несколько приемников. Как простейший пример, можно сваливать одну копию на локальный диск и одновременно складывать на сетевой ресурс. Локальная копия удобна, так как восстановление из неё существенно быстрее, удалённая копия зато гораздо лучше перенесёт физическое уничтожение основного сервера базы данных.

        Примеры систем резервного копирования

        Довольно теории. Пора практикой доказать, что вся эта кухня работает.

        Настройка типичного резервирования сервера через Планы обслуживания (MaintenancePlan)

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

        Пользуемся мастером создания плана обслуживания

        1. Запускаем SSMS, подключаемся к нужному серверу.
        2. Запускаем мастер:

        

        

        Задаём имя плана «Резервное копирование» и описание, указываем галочку «Separate schedules for each task», переходим дальше

        

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

        

        Начинаем настраивать полное резервное копирование:

        

        Настраиваем полное копирование всех пользовательских баз данных. Системные базы данных тоже желательно сохранять, но во-первых не все (имеет смысл только master и msdb, если вы специально не изменяете model), во-вторых, возможно, с другой периодичностью, в-третьих для master не нужно сохранять РКЖТ.

        

        Настраиваем детали копирования. Обратите внимание на следующие моменты:

        

        • удобнее для каждой БД делать отдельный подкаталог, если этих БД больше 2-3 на сервере;
        • если нет дополнительных средств проверки, то крайне желательно выставить галочку «Verify backup integrity». Хотя возможна ситуация, когда даже проверенная таким образом копия не восстановится, но такая проверка лучше, чем никакая;
        • вариант сжатия установлен «по настройкам сервера», очень желательно включить эту возможность на уровне сервера;
        • папку «C:\Backup» я использую только для примера.
      • Настраиваем расписание (например, раз в неделю по воскресеньям в полночь, примерно как в рассмотренном ранее примере):

        

        Аналогично настраиваем разностные резервные копии, но раз в день, кроме воскресенья. Тоже в полночь.

        

        РКЖТ. Ежедневно в 12:00 (остальное аналогично предыдущим).

        

        • Обратите внимание, что базы данных с моделью восстановления simple будут игнорироваться.
        • Обратите внимание, что галочку «Back up the tail. » ставить не следует. Она не предназначена для обычного резервного копирования журналов транзакций.
      • Настроим разумный горизонт хранения резервных копий в этой папке (например, 4 недели, предполагается, что резервные копии из этой папки копируются еще куда-то и хранятся существенно дольше):

        

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

        

        Проверяем, убеждаемся, что всё правильно .

        

        Вот в общем-то и всё. Резервное копирование, подходящее для большинства баз данных размером от 1-2 ГБ до 200-300 ГБ готово.

        

        Как проверить, что система работает?

        Проверяем, что нужные объекты созданы:

        

        Для каждого из заданий (Резервное копирование.Subplan_1, Резервное копирование.Subplan_2, Резервное копирование.Subplan_3, Резервное копирование.Subplan_4) проверяем, что они запускаются:

        

        Проверять лучше последовательно: запустить, дождаться завершения, закрыть уведомление, перейти к следующему.

      • Проверяем, что в целевой папке появились резервные копии.
      • Проверяем, что разностная копия существенно меньше полной.
      • Снова запускаем задание Резервное копирование.Subplan_3 (это РКЖТ) и проверяем, что второй сгенерированный файл РКЖТ в каждой базе имеет небольшой размер относительно первого (В MS SQL Server 2005 стоит перед повторным выполнением нужно подождать пару минут.)
      • Проверяем папку протоколов и читаем (у меня это папка C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log — та, которая была настроена на шаге 12). Читаем протоколы, убеждаемся, что ошибок нет.
    • .
    • PROFIT.

Настройка резервирования сервера скриптами TSQL, примеры некоторых возможностей

Сразу возникает вопрос, а чего еще надо? Вроде ж только что всё настроили и всё работает как часы? Зачем маяться со всякими скриптами? Планы обслуживания не позволяют:

• Использовать зеркальное резервирование
• Использовать настройки сжатия отличные от настроек сервера
• Не позволяет гибко реагировать на возникающие ситуации (никаких возможностей по обработке ошибок)
• Не позволяет гибко использовать настройки безопасности
• Планы обслуживания очень неудобно развёртывать (и поддерживать одинаковыми) на большом количестве серверов (даже, пожалуй, уже на 3-4)

Ниже приведены типичные команды резервного копирования

Полная резервная копия

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

BACKUP DATABASE [mydb] TO DISK = N'C:\Backup\mydb.bak' WITH INIT, FORMAT, STATS = 1, CHECKSUM

Разностная резервная копия

Аналогично — разностная копия

BACKUP DATABASE [mydb] TO DISK = N'C:\Backup\mydb.diff' WITH DIFFERENTIAL, INIT, FORMAT, STATS = 1, CHECKSUM

РКЖТ

Резервная копия журнала транзакций

BACKUP LOG [mydb] TO DISK = N'C:\Backup\mydb.trn' WITH INIT, FORMAT

Зеркальное резервирование

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

BACKUP DATABASE [mydb] TO DISK = N'C:\Backup\mydb.bak', MIRROR TO DISK = N'\\safe-server\backup\mydb.bak' WITH INIT, FORMAT

Важный момент, который часто упускается: у пользователя, от имени которого запускается процесс MSSQL Server должен быть доступ к ресурсу «\\safe-server\backup\», иначе копирование завершится с ошибкой. Если MSSQL Server запущен от имени системы, то доступ нужно давать пользователю домена «имя_сервера$», но лучше всё-таки корректно настроить запуск MS SQL от имени специально созданного пользователя.

Если не указать MIRROR TO , то это будет не 2 зеркальных копии, а одна копия, разбитая на 2 файла, по принципу чередования. И каждая из них в отдельности будет бесполезна.

Ссылки

Полезнее всего для понимания работы резервного копирования ознакомиться со следующими статьями:



На закладке Options настраиваем, где будут лежать файлы восстановленной базы данных. Если базу данных восстанавливаем поверх существующей, то нужно установить флажок WITH REPLACE



1. Жмем OK

А вот вариант TSQL:

RESTORE DATABASE mydb FROM DISK = N'C:\Backup\mydb.bak'

Для самых хитрых и ленивых есть очень полезная возможность создать вариант TSQL из настроенного окна восстановления:

Восстановление полной копии и разностной

RESTORE DATABASE mydb FROM DISK = N'C:\Backup\mydb.bak' WITH NORECOVERY; RESTORE DATABASE mydb FROM DISK = N'C:\Backup\mydb.diff' WITH RECOVERY;

Восстановление полной копии, разностной и нескольких журналов транзакций

RESTORE DATABASE mydb FROM DISK = N'C:\Backup\mydb.bak' WITH NORECOVERY; RESTORE DATABASE mydb FROM DISK = N'C:\Backup\mydb.diff' WITH NORECOVERY; RESTORE DATABASE mydb FROM DISK = N'C:\Backup\log1.trn' WITH NORECOVERY; RESTORE DATABASE mydb FROM DISK = N'C:\Backup\log2.trn' WITH RECOVERY;

Восстановление до определённой точки

RESTORE DATABASE mydb FROM DISK = N'C:\Backup\mydb.bak' WITH NORECOVERY; RESTORE DATABASE mydb FROM DISK = N'C:\Backup\mydb.diff' WITH NORECOVERY; RESTORE DATABASE mydb FROM DISK = N'C:\Backup\log1.trn' WITH STOPAT = '2013-02-12 21:45:00'; RESTORE DATABASE mydb FROM DISK = N'C:\Backup\log2.trn' WITH STOPAT = '2013-02-12 21:45:00';

Обратите внимание, если указанное время STOPAT назначено после создания последней резервной копии журналов, база данных остается в невосстановленном состоянии, как если бы инструкция RESTORE LOG работала с параметром NORECOVERY.

Факультативно рекомендую посмотреть самостоятельно

• Восстановление с использованием «хвоста» журнала транзакций ( WITH TAIL )
• Восстановление в состояние standby (но важно понимать, что обычно 1С не сможет работать с БД, доступной только для чтения)
• Восстановление сбойных страниц, восстановление файлов (факультатив)

Все эти возможности можно посмотреть в MSDN: