ГлавнаяРазноеБэкап и восстановление 1с базы в ms sql

Создание и восстановление резервной копии базы данных в Microsoft SQL Server 2008 R2. Бэкап и восстановление 1с базы в ms sql


Резервное копирование 1С средствами MS SQL — Ваш личный специалист

Рассмотрим в этой статье резервное копирование баз 1С средствами SQL-сервера.

Введение

В этой статье описано самое обычное резервное копирование ИБ 1С при помощи инструментов MS SQL Server (не ниже 2008), объяснено почему следует делать именно так, а не иначе, и развеяно несколько мифов. В статье достаточно много ссылок на документацию MS SQL. В этой статье будет скорее обзор вариантов и механизмов резервного копирования, чем полное руководство к действию. Но для тех, кто сталкивается с этой задачей впервые, даны простые и пошаговые инструкции, которые применимы к простым ситуациям. Статья предназначена не для гуру администрирования, гуру и так всё это знают, но предполагается, что читатель способен сам установить MS SQL Server и заставить это чудо враждебной техники создать в своих недрах базу данных, которую в свою очередь он же способен заставить хранить данные 1С.

Метод Плюсы Минусы Итог
Выгрузка в dt Очень компактный формат. Долго формируется, требует монопольного доступа, не сохраняет часть малозначительных данных (таких как настройки пользователей в ранних версиях), долго разворачивается. Это не столько способ резервного копирования, сколько способ переноса данных из одной среды в другую. Идеален для узких каналов.
Копирование файлов mdf и ldf Очень понятный способ для начинающих админов. Требует освобождения файлов базы данных от блокировки, а это возможно, если база отключена (команда take offline контекстного меню), отсоединена (detach) или просто остановлен сервер. Очевидно, что пользователи в это время работать не смогут. Этот способ имеет смысл применять тогда и только тогда, когда уже произошла авария, чтобы при попытках восстановления хотя бы иметь возможность вернуться к тому варианту, с которого началось восстановление.
Резервное копирование средствами ОС или гипервизора Удобный способ для сред разработки и тестирования. Не всегда дружит с целостностью данных. Ресурсоёмкий способ. Может ограниченно применяться для разработки. В продуктовой среде практического смысла не имеет.
Резервное копироавние средствами MS SQL Не требует простоев. Позволяет восстановить целостное состояние на произвольный момент, если заранее об этом побеспокоиться. Отлично автоматизируется. Экономный по времени и другим ресурсам. Не очень компактный формат. Не все умеют пользоваться этим способом в необходимой мере. Для продуктовых сред — основной инструмент.

 Основные сложности при использовании резервного копирования встроенными средствами MS SQL возникают из-за элементарного непонимания принципов работы. Это объясняется отчасти великой ленью, отчасти отсутствием простого и понятного разъяснения на уровне «готовых рецептов» (хм, скажем так, мне не встречалось), да еще и усугубляется ситуация мифосоветами «недогуру» на форумах. Что делать с ленью я не знаю, а вот объяснить основы резервного копирования попробую.

Что и зачем сохраняем?

Давным-давно в далёкой галактике существовал такой продукт инженерно-бухгалтерской мысли, как 1С:Предприятие 7.7. Видимо из-за того, что первые версии 1С:Предприятия разрабатывались для использования популярного формата файлов dbf, его SQL-версия не хранила в базе данных достаточно информации для того, чтобы считать резервное копирование MS SQL полноценным, да еще и при каждом изменении структуры нарушались условия работы полной модели восстановления, поэтому приходилось идти на разные ухищрения, чтобы заставить систему резервного копирования исполнять свою основную функцию. Но, с тех пор, как появилась версия 8 администраторы баз данных наконец-то смогли расслабиться. Штатные средства резервного копирования позволяют создать полную и целостную систему резервных копий. Не входит в резервное копирование только журнал регистрации и некоторые мелочи типа настроек положения форм (в старых версиях), но это потеря этих данных на функциональности системы в не сказывается, хотя безусловно резервные копии журнала регистрации делать правильно и полезно.

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

Резервное копирование — это последний рубеж обеспечения сохранности системы. Если администратору базы данных приходится восстанавливать продуктовую систему из резервных копий, значит, с большой вероятностью было допущено множество грубых ошибок в организации работ. Нельзя относиться к резервному копированию, как к основному способу обеспечения целостности данных, нет, это скорее ближе к системе пожаротушения. Система пожаротушения необходима. Она должна быть настроена, проверена и работоспособна. Но если она сработала, то это само по себе является серьёзным ЧП с массой негативных последствий.

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

  • Обеспечьте физическую безопасность серверов: пожары, затопления, плохое электропитание, уборщицы, строители, метеориты и дикие животные — все они только и ждут за углом, чтобы уничтожить вашу серверную.
  • Ответственно относитесь к угрозам информационной безопасности.
  • Квалифицированно вносите изменения в систему и заранее максимально убедитесь, что эти изменения не приведут к ухудшениям. Кроме плана внесения изменений желательно иметь и план «что делать, если всё пойдёт не так».
  • Активно используйте технологии повышения доступности и надёжности системы вместо того, чтобы потом разгребать последствия аварий. Для MS SQL следует обратить на следующие возможности:
  • Использование кластеров MS SQL (хотя, если честно, я считаю, это одним из наиболее дорогих и бесполезных способов занять администратора БД для систем не требующих 24х7)
  • Зеркалирование базы данных (в синхронном и асинхронном режиме в зависимости от требований доступности, производительности и стоимости)
  • Доставка журналов транзакций
  • Репликация средствами 1С (распределённые базы данных)

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

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

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

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

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

В ФД хранятся данные страницами по 8 килобайт (которые объединены в экстенты по 64 килобайт, но это не существенно). MS SQL не гарантирует, что сразу после выполнения команды изменения данных, эти изменения попадут в ФД. Нет, просто страница в памяти помечается как «требующая сохранения». Если у сервера достаточно ресурсов, то вскоре эти данные окажутся на диске. Причем, сервер работает «оптимистично» и если эти изменения происходят в транзакции, то они вполне могут попадать на диск до фиксации транзакции. То есть в общем случае, при активной работе ФД содержит разрозненные куски недописанных данных и незавершённых транзакций, для которых неизвестно, будут ли они отменены или зафиксированы. Есть специальная команда «CHECKPOINT«, которая указывает серверу, что нужно «прямо сейчас» сбросить все несохранённые данные на диск, но область применения этой команды достаточно специфична. Достаточно сказать, что 1С её не использует (я не сталкивался) и понимать, что во время работы обычно ФД не находится в целостном состоянии.

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

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

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

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

select * from ::fn_dblog(null,null)

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

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

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

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

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

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

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

  • Simple (Простая) — хранится только необходимый для жизни остаток ЖТ.
  • Full (Полная) — хранится весь ЖТ с момента последнего резервного копирования журнала транзакций. Обратите внимание, не с момента полного бэкапа!
  • Bulk logged (С неполным протоколированием) — часть (очень небольшая обычно часть) операций записываются в очень компактном формате (по сути только запись, что изменена такая-то страница файла данных). В остальном идентична Full.

С моделями восстановления связано несколько мифов.

  • Simple позволяет снизить нагрузку на дисковую подсистему. Это не так. пишется ровно столько же, сколько при Bulk logged, только считается свободным гораздо раньше.
  • Bulk logged позволяет снизить нагрузку на дисковую подсистему. Для 1С это почти не так. По сути одна из немногих операций, которая может без дополнительных плясок с бубном подпадать под минимальное протоколирование — загрузка данных из выгрузки в формате dt и реструктуризация таблиц.
  • При использовании модели Bulk logged какие-то операции не попадают в резервную копию журнала транзакций и она не позволяет восстановить состояние на момент этой резервной копии. Это не совсем так. Если операция относится к минимально протоколируемым, то в резервную копию попадут текущие страницы с данными и будет возможность «проиграть» журнал транзакций до конца (хотя и нельзя на произвольный момент времени, если есть минимально протоколируемые операции).

Модель 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 ГБ)
  • Полная копия F2 от 0:00 8 февраля (объём 1014 ГБ)
    • Разностная копия 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 минут, вместо того, чтобы восстанавливать огромную базу! Поздравляю, мы заново изобрели механизм доставки журналов, один из способов снижения времени простоев. Если так передавать данные не раз в период, а постоянно, то получится уже зеркалирование, причем если база-источник ждёт пока база-зеркало обновится, то это синхронное зеркалирование, если не ждёт, то асинхронное.

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

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

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

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

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)

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

Пользуемся мастером создания плана обслуживания
  • Запускаем SSMS, подключаемся к нужному серверу.
  • Запускаем мастер:
  • Задаём имя плана «Резервное копирование» и описание, указываем галочку «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 файла, по принципу чередования. И каждая из них в отдельности будет бесполезна.

Ссылки

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

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

Так, так, так. Вы думаете что резервное копирование работает? А вы уверены? А вы уверены, что то, что формируется резервным копированием при аварии можно будет использовать для восстановления? Давайте проверим, а заодно научимся восстанавливать данные. Проверка возможностей восстановления — это обязательный этап настройки резервного копирования.

Проверяем резервную копию без восстановления

Файл лежит на диске. Но может быть это вовсе и не резервная копия? Как проверить:

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

Здесь, правда, как с анализами в больнице: если результат анализа положительный, то болезнь есть, если отрицательный, то это еще не гарантирует, что болезни нет. Вот и тут также: если RESTORE VERIFYONLY ругается на ваш файл, то он некорректный. Но если не ругается, то это еще не окончательная гарантия, что он восстановится. Особенно это актуально для предыдущих версий MS SQL Server.

Восстановление полной копии в новую базу данных

Это, пожалуй, самая частая операция с файлами резервных копий. Делать её можно как скриптом, так и интерактивно. Давайте сначала интерактивно:

  1. Выбираем Restore Database из контекстного меню:
  2. Выбираем базу данных, в которую надо восстановить файл, и сам файл
  3. На закладке Options настраиваем, где будут лежать файлы восстановленной базы данных. Если базу данных восстанавливаем поверх существующей, то нужно установить флажок WITH REPLACE
  4. Жмем 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.

Заключение

Приведённой информации достаточно для ликбеза по резервным копиям, но недостаточно для практических навыков. Читайте, изучайте, тренируйтесь (в «песочнице», естественно). Всё вышеперечисленное применимо далеко не только к 1С:Предприятияю.

prof-advance.ru

Создание и восстановление резервной копии базы данных в Microsoft SQL Server 2008 R2

В данной статье будет рассказано как вручную сделать полную резервную копию базы данных в SQL Server 2008 R2 с помощью программы «Среда Microsoft SQL Server Management Studio».

 

 

0. Оглавление

  1. Создание резервной копии
  2. Восстановление базы данных из резервной копии
  3. Восстановление резервной копии в другую базу данных (копирование данных)

1. Создание резервной копии

На самом деле все довольно просто. Запускаем оснастку «Среда Microsoft SQL Server Management Studio» («Пуск» — «Все программы» — «SQL Server 2008 R2» — «Среда Microsoft SQL Server Management Studio» ) и вводим данные для авторизации.

После чего в Обозревателе объектов раскрываем вкладку «Базы данных» и кликнем правой кнопкой мыши по той базе данных, для которой необходимо сделать резервную копию. В появившемся контекстном меню выберем «Задачи» (Tasks) — «Создать резервную копию» (Back Up…) .

Запустится окно «Резервная копия базы данных» (Back Up Data Base) . Убедимся, что тип резервной копии стоит «Полная» (Full), при необходимости зададим имя и описание, а также укажем назначение резервной копии. По умолчанию выбран путь на жестком диске компьютера в папку Backup основного расположения баз SQL-сервера. Для того чтобы изменить место размещения копии, сначала нажмем «Удалить» (Remove), чтобы удалить существующее назначение, а затем «Добавить» (Add…) для добавления нового.

Здесь зададим расположение и имя файла резервной копии и нажмем «ОК» . Таких мест назначений можно задать несколько. В этом случае резервная копия будет разбита на равные части, каждая часть в указанном файле.

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

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

2. Восстановление базы данных из резервной копии

Восстановление происходит по аналогичной схеме. В «Среде Microsoft SQL Server Management Studio» выбираем базу из которой сделана резервная копия, кликаем по ней правой кнопкой мыши, в контекстном меню выбираем «Задачи» (Tasks) — «Восстановить» (Restore) — «База данных…» (Database…).

Откроется окно «Восстановление базы данных» (Restore Database). Здесь, в качестве источника укажем «С устройства» (From device) и выберем файл резервной копии (созданных в пункте 1).

Установим флаг «Восстановить» (Restore) напротив выбранной резервной копии. При необходимости, на вкладке «Параметры» (Options), можно указать дополнительные параметры восстановления, о значении которых можно прочитать здесь.

После того, как все настройки сделаны, жмем «ОК» и дожидаемся сообщения об успешном восстановлении базы данных.

3. Восстановление резервной копии в другую базу данных (копирование данных)

Если же необходимо загрузить данные в базу данных, отличную от той из которой была сделана резервная копия, то при загрузке помимо действий, описанных в пункте 2, необходимо на вкладке «Параметры» (Options) задать имена файлов этой базы данных и установить флаг «Перезаписывать существующую базу данных» (WITH REPLACE).

Смотрите также:

tavalik.ru

Резервное копирование и восстановление базы данных MS SQL Server 2008, 2008 R2, 2012 и 2014

Введение в резервное копирование и восстановление базы данных MS SQL Server 2008, 2008 R2, 2012 и 2014

Обширный функционал Bacula Enterprise Edition, помимо прочего, позволяет быстро и просто создавать бэкапы БД под Windows. Например, речь идет об инструменте, с помощью которого можно осуществлять резервное копирование MS SQL Server. Сделать бэкап MS SQL пользователь может, создавая резервные копии специфических баз данных MS SQL больших объемов, используемых платформой Windows, при меньших затратах на ПО сторонних производителей, с возможностью восстановления данных до определенного момента времени (PITR-восстановление) на сетевой и локальный диск.

Скрипт Bacula Systems для создания бэкапов MS SQL Server характеризуется крайней эффективностью, достигаемой за счет реализации современной, высоконадежной архитектуры. Более того, ПО позволяет сделать бэкап MS SQL Server, использовать самые различные возможности по созданию резервных копий MS SQL.

Скрипт бэкапа MS SQL Bacula Systems функционирует независимо от VSS. Это значит, что инструмент резервного копирования MS SQL не использует снапшоты VSS для создания бэкапов. Поэтому пользователь может задать следующее значение “Enable VSS = no” в Bacula FileSet. Эффективное создание бэкапов MS SQL Server и их восстановление с помощью данного решения достигаются за счет использования Microsoft API для SQL Server. Благодаря этому Bacula Systems может поддерживать работу механизмов обеспечения защиты и все типы проверки подлинности, реализованные в Microsoft SQL Server.

Резервное копирование журнала транзакций MS SQL и восстановление MS SQL на момент времени: ПО Bacula Enterprise Edition позволяет восстанавливать блоки данных MS SQL или конкретные настройки до определенного момента времени. Благодаря реализации моделей полного восстановления и восстановления с неполным протоколированием вы сможете восстанавливать MS SQL, используя PITR-восстановление, либо использовать LSN для восстановления системы до конкретного состояния. Вы можете восстанавливать определенное состояние базы данных MS SQL на любой конкретный момент времени с точностью до секунды. В случае бэкапа журнала транзакций MS SQL, при восстановлении состояние БД будет восстанавливаться из различных выбранных бэкапов.

Краткий обзор функций
 автоматического бэкапа и восстановления MS SQL с Bacula Enterprise

Компания Bacula Systems создала плагин для резервного копирования MS SQL Server для совместного использования с Bacula Enterprise Edition. Бэкап MS SQL Server с Bacula обладает следующими функциями:

  • Поддержка полного и дифференциального резервного копирования MS SQL
  • Поддержка инкрементального резервного копирования MS SQL
  • Резервное копирование MS SQL на сетевой и локальный диск
  • Резервное копирование MS SQL по расписанию
  • Создание бэкапов на уровне базы данных MS SQL Server
  • Возможность включать/исключать БД из процедуры создания бэкапов
  • Поддержка создания бэкапов БД «только для чтения»
  • Восстановление MS SQL бэкапов на диск
  • Отправка потока резервной копии напрямую в Storage Daemon
  • Восстановление MS SQL на момент времени

Обзор и настройка резервного копирования MS SQL 2008, 2008 R2, 2012 и 2014

В данном документе представлены решения для Bacula Enterprise Edition 8.4 и более поздних версий, которые не поддерживаются ранними версиями ПО. Резервное копирование базы MS SQL был протестировано и поддерживается MS SQL 2003 R2, MS SQL 2008 R2, MS SQL 2012, MS SQL 2005, MS SQL 2008, MS SQL 2014. Возможна работа резервного копирования MS SQL от Bacula с SQL Express.

Глоссарий резервного копирования MS SQL 2008, 2008 R2, 2012 и 2014

  • MS SQL означает Microsoft SQL Server.
  • Журнал транзакций (transaction log). Любая база данных MS SQL Server имеет журнал транзакций, в который записываются все транзакции и модификации БД, выполненные в ходе таких транзакций. Журнал транзакций – важный элемент БД. В случае отказа системы журнал транзакций может потребоваться для восстановления БД до рабочего состояния. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms190925.aspx.
  • Дифференциальное резервное копирование базы данных MS SQL Server. Дифференциальный бэкап основан на последнем полном бэкапе БД. В ходе выполнения дифференциального бэкапа захватываются только те данные, которые были изменены с момента создания последнего полного бэкапа. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en- us/library/ms175526.aspx.
  • Полное резервное копирование базы данных MS SQL Server. В ходе полного бэкапа БД создается резервная копия всей базы данных. Бэкап включает часть журнала транзакций с целью восстановления полной БД из резервной копии. Полные бэкапы БД содержат БД на момент завершения создания резервной копии. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en- us/library/ms186289.aspx.
  • Бэкап «только для копирования» (CopyOnly). Бэкапы «только для копирования» представляют собой бэкапы MS SQL, независящие от обычной последовательности создания традиционных резервных копий SQL Server. Иногда полезно создавать бэкапы для особых нужд, не влияя на общий процесс резервного копирования и восстановления БД. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms191495.aspx.
  • VDI (Интерфейс виртуального устройства) – это технология Microsoft, позволяющая создавать именованный канал между программами.
  • <glob> стандартные маски задают наборы строк с подстановочными знаками. Например, стандартная маска production* будет включать строки production1 и production2.
  • <str> строка
  • <bytes> целое число.
  • LSN Каждая запись в журнале транзакций MS SQL Server обозначается с помощью уникального регистрационного номера транзакции (LSN). Более подробную информацию вы найдете по ссылке https://technet.microsoft.com/en-us/library/ms190411%28v=sql.105%29.aspx.

Резервное копирование MS SQL Server 2008, 2008 R2, 2012 и 2014

Полное резервное копирование баз данных MS SQL Server 2008, 2008 R2, 2012 и 2014

В ходе полного резервного копирования базы данных MS SQL сохраняются файлы БД и журнал транзакций, что позволяет полностью защитить базу MS SQL на случай отказа носителя. В случае повреждения одного или более файлов восстановление базы MS SQL из бэкапа позволит восстановить все совершенные транзакции. Также будет произведен откат всех транзакций, находившихся в процессе выполнения. В данном режиме производится создание бэкапов БД master и mbdb.

Дифференциальное резервное копирование баз данных MS SQL Server 2008, 2008 R2, 2012 и 2014

Дифференциальный бэкап базы MS SQL Server основан на самом последнем полном бэкапе базы данных MS SQL. В ходе создания дифференциального бэкапа MS SQL захватываются только те данные, которые были изменены с момента создания последнего полного бэкапа MS SQL. Для функции дифференциального бэкапа MS SQL крайне важна последовательность бэкапов. Если по какой-то причине полный бэкап, на который ссылается MS SQL, не доступен, дифференциальные бэкапы базы данных MS SQL Server нельзя будет использовать. Резервное копирование MS SQL от Bacula использует определенные методы для решения данной проблемы. Поэтому, в случае возникновения сложностей, статус дифференциального бэкапа БД может быть автоматически повышен до полного бэкапа.

Резервное копирование журнала транзакций MS SQL 2008, 2008 R2, 2012 и 2014

Функция создания бэкапа журнала транзакций MS SQL реализуется на инкрементальном уровне с помощью ПО Bacula. БД MS SQL должна быть сконфигурирована с помощью моделей полного восстановления и восстановления с неполным протоколированием. Если MS SQL использует простую модель восстановления, файл журнала транзакций будет «урезаться» после каждой контрольной точки, и бэкап журнала транзакций не позволит реализовать восстановление до выбранной конкретной точки, т.е. PITR-восстановление. Можно будет восстановить базу данных MS SQL полностью, но нельзя будет выбрать контрольную точку. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms189275.aspx.

Настройка резервного копирования MS SQL и конфигурирование БД

Необходимо всегда создавать резервную копию БД master. Если БД master будет так или иначе повреждена, например, в результате отказа носителя, возможно, не получится запустить инстанс MS SQL. В таком случае, необходимо восстановить БД master, и только потом восстановить из резервной копии саму БД. Возможно создание только полных бэкапов базы MS SQL. Более подробную информацию вы найдете по ссылке https://technet.microsoft.com/en-s/library/aa213839%28v=sql.80%29.aspx.

Восстановление базы MS SQL из бэкапа

Вы можете использовать все стандартные способы запуска процедуры восстановления базы MS SQL из бэкапа. Однако вы должны убедиться в том, что, в случае восстановления дифференциальных данных, будет также восстановлен полный предыдущий бэкап базы MS SQL. В таком случае восстановление происходит автоматически, если вы запускаете его в консоли bconsole с помощью вариантов восстановления 5 или 12. В сгенерированной файловой структуре вам необходимо отметить восстановление полных БД или инстансов БД.

Варианты восстановления базы MS SQL из бэкапа

ПО Bacula Enterprise Edition позволяет пользователям использовать множество вариантов восстановления MS SQL и применять самые различные способы «отката» БД. Наиболее часто используемые варианты восстановления описаны ниже:

  • параметр Where: В случае с Bacula Enterprise Edition, данный параметр позволяет администратору восстанавливать БД в конкретном месте.
  • параметр Replace: Используется для того, чтобы определить, как ПО Bacula должно вести себя с текущей БД при восстановлении. Резервное копирование MS SQL от Bacula также позволяет использовать еще несколько опций при восстановлении, например:
  • Instance: Поскольку MS SQL использует несколько инстансов, бэкап базы MS SQL от Bacula позволяет выбирать, какой из инстансов следует восстанавливать. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа. По умолчанию, используется инстанс с именем “MSSQLSERVER”.
  • Database. Данная опция указывает имя БД для восстановления и она использует значение, заданное в момент создания БД. Данный параметре является опциональным. По умолчанию резервное копирование баз данных SQL Server использует параметр Where для определения имени новой БД. Если обоим параметрам Where и Database назначены валидное имя БД, то параметр Database будет использоваться.
  • User. Имя пользователя, используемое для подключения к инстансу базы данных MS SQL. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа.
  • Password. Пароль, используемый для подключения к инстансу базы данных MS SQL. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа.
  • Domain. Домен, используемый для подключения к инстансу базы данных MS SQL. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа.
  • Recovery. Параметр позволяет определить, будет ли произведен откат БД к предыдущему состоянию при восстановлении или нет. По умолчанию при восстановлении БД будет произведет откат к предыдущему состоянию.
  • Stop_before_mark. Условие WITH STOPBEFOREMARK = <point> используется для того, чтобы указать, что запись в журнале транзакций, которая находится непосредственно перед флагом, и является точкой восстановления. Точкой восстановления может служить дата и время, номер LSN или имя флага mark_name.
  • Stop_at_mark. Условие WITH STOPATMARK =<point> используется для того, чтобы показать, что помеченная транзакция является точкой восстановления. STOPATMARK перемещается вперед к флагу и включает повтор помеченной транзакции. Точкой восстановления может служить дата и время, номер LSN или имя флага mark_name.
  • Stop_at=<datetime>. Условие WITH STOPAT = <datetime> используется для того, чтобы указать, что точкой восстановления является дата/время.
  • Restrict_user. Условие WITH RESTRICT_USER используется для ограничения доступа к восстановленной БД. По умолчанию используется значение no.

В программе BWeb Management Suite, созданной Bacula Systems, настройка резервного копирования MS SQL находятся на вкладке восстановления.

Рисунок 1: Вкладка восстановления БД при использовании программы BWeb Management Suite

Восстановление MS SQL на момент времени

Данный вопрос относится только к тем БД SQL, которые используют модели полного восстановления и восстановления с неполным протоколированием. В случае модели восстановления с неполным протоколированием, если бэкап журнала содержит изменения, сделанные во время операций массовой обработки данных, то невозможно будет выполнить восстановление на какой-либо момент времени в пределах этого бэкапа. БД должна быть восстановлена до конца журнала транзакций, бэкап которого был создан. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms179451.aspx.

Восстановление MS SQL на момент времени можно совершать непосредственно из плагина бэкапа MS SQL. Также можно восстанавливать файлы локально и выполнять операции из консоли управления Microsoft SQL Server Mangement Console, чтобы иметь возможность использовать больше возможностей.

LSN

LSN номера используются для создания последовательности восстановления MS SQL с целью отслеживания момента времени, до которого данные были восстановлены. При восстановлении MS SQL из бэкапа данные восстанавливаются до LSN номера, соответствующего моменту времени, в который был выполнен бэкап. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms190925.aspx.

LSN номер записи в журнале, в момент которой возникло конкретное событие по созданию бэкапа и восстановлению, можно просмотреть одним из следующих способов:

  • При выводе описания заданий по созданию бэкапа с помощью ПО Bacula
  • В названии файла журнала
  • В таблице msdb.backupset
  • В таблице msdb.backupfile

При выполнении задания по созданию бэкапа базы MS SQL при выводе описания задания отобразится следующая информация о LSN номерах:

Номер First LSN соответствует последнему LSN номеру последнего бэкапа журнала транзакций. Таким бэкапом может являться самый первый полный бэкап или последний бэкап (инкрементальный).

Номер Last LSN соответствует последней транзакции, зарегистрированной в журнале.

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

Число в названии, в нашем случае 42000162001, соответствует последнему LSN номеру предыдущего задания (по созданию полного или инкрементального бэкапа).

Рисунок 2: Первый номер LSN, последний номер LSN и номера LSN в названии файлов

 Как показано в примере на рисунке 2, если администратору необходимо восстановить базу данных MS SQL в состояние, соответствующем LSN номеру 14, можно выполнить следующие действия:

  • В меню восстановления БД используйте опцию 5
  • Выберите директорию БД “/@mssql/db29187”
  • Выберите последний файл полного бэкапа “data.bak” (LSN: 10)
  • Выберите инкрементальный бэкап “log-10.trn”
  • Задайте параметр stop_at_mark равный “lsn:14”
  • Запустите задачу по восстановлению бэкапа

Или, если последний полный бэкап MS SQL Server не доступен, однако доступен предыдущий полный бэкап, то:

  • Используйте опцию восстановления 3, выберите соответствующие значения jobids
  • Выберите директорию БД “/@mssql/db29187”
  • Выберите файл полного бэкапа “data.bak” (LSN: 2)
  • Выберите инкрементальные бэкапы “log-2.trn”, “log-3.trn”, “log-10.trn”
  • Задайте параметр stop_at_mark равный “lsn:14”
  • Запустите задачу по восстановлению бэкапа
Сценарии восстановления MS SQL
Описание Where Database Пример
Восстановить файлы на диск Путь   where=c:/tmp
Восстановить исходную БД     where=/
Восстановить с новым именем Имя   where=newdb
Восстановить с новым именем   Имя database=newdb
Восстановить с новым именем и переместить файлы   Имя

where=c:/tmp

database=newdb

Таблица 1: Сценарии восстановления MS SQL

 2.3.1 Восстановление базы MS SQL с исходным именем

Чтобы восстановить БД с исходным именем, параметр Where должен быть не задан (пустое значение), либо должно быть задано значение “/”, а параметру Replace должно быть присвоено значение Always, или же сначала необходимо удалить исходную БД.

Восстановление бэкапа MS SQL с новым именем

Чтобы восстановить бэкап базы данных MS SQL с новым именем, возможно, сначала потребуется переместить файлы БД на диск. Все зависит от того, существует ли еще исходная БД.

Если исходная БД более не доступна, то параметр where, либо поле “Plugin Options” может содержать название новой БД. Резервное копирование MS SQL от Bacula автоматически создаст БД с новым именем.

Если исходная БД все еще пока требуется, параметр where будет использоваться для перемещения файлов на диск, и необходимо будет задать название новой БД с помощью меню “Plugin Options”. В дереве восстановления необходимо выбрать файл layout.dat.

Используя каталог My Catalogue

Запустите задачу восстановления MS SQL:

Используя каталог My Catalogue, запустите задачу восстановления базы MS SQL:

Восстановление MS SQL на локальный диск

Если указать where=c:/path/, файлы будут восстановлены на локальный диск, и администратор базы данных MS SQL сможет использовать процедурное расширение TSQL для консоли управления Microsoft SQL Server Mangement Console для восстановления БД. Команды SQL, необходимые для восстановления БД, перечислены в описании Job output как показано на рисунке ниже.

Восстановление базы данных MS SQL «master»

Инструкции по восстановлению БД “master” подробно изложены на странице: https://technet.microsoft.com/en-us/library/aa213839%28v=sql.80%29.aspx

База данных MS SQL в состоянии восстановления

По завершению восстановления MS SQL, если опциональному параметру Recovery было присвоено значение No, восстановленная БД будет находиться в состоянии «восстановления». Чтобы завершить процесс восстановления, необходимо запустить процедуру отката БД. Для этого используйте следующую команду SQL:

 

www.backup-solutions.ru

Восстановление базы 1С SQL-Server - КомпЛайн

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

Итак, начнем. Рассмотрим следующую ситуацию: есть сервер с запущенной и работающей на нем связкой 1С+SQL.

Во время работы SQL вдруг выключилось питание сервера. Результат плачевный: база находится в состоянии suspect, и когда 1с пытается к ней зацепиться, выдается ошибка, что мол соединиться невозможно т.к. база помечена suspect for recovery.

Этот режим в принципе означает, что MSSQL Server попытается восстановить базу своими средствами. Я не стал ни чего трогать и оставил все на ночь, в надежде, что к утру база восстановится, но и утром было то же самое, и к базе, стало быть, ни как не подобраться.

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

1) Главный принцип при этих манипуляциях  – не навредить. Останавливаем SQL server и делаем копии  файлов *.mdf и *.ldf файлы от базы в отдельную папку.

2) В принципе, бывает, что состояние suspect возникает из-за того, что поменялись пути к файлам с базой (например, добавился новый диск в системе, который потом убрали, переименовали папку с базой и т.д.). Затем, конечно же, пути восстановили, но база все равно остается помеченной как suspect.

Что надо сделать:

3) Запустить SQL Server. 4) Попробывать подключить базу посредством Enterprise Manager: Правой кнопкой по Databases, в появившемся меню выбираем All tasks->Attach database, затем в появившемся диалогов окне выбираем файл с базой (*.mdf) и устанавливаем необходимые параметры. 5) или через Query Analyser примерно такой командой:a. sp_attach_db @dbname = 'DemoXMB', b. @filename1 = 'E:\Data\DemoXMB_Data.MDF', c. @filename2 = 'E:\Data\DemoXMB_Log.LDF'

6) Пути к базе, естественно нужно заменить на свои. Если база подключилась, то, можно сказать, отделались легким испугом, если же нет, то продолжим. 7) Если log-файл не поврежден (*.ldf), а поврежден *.mdf (например, при подключении базы sql ругается на ошибки в mdf-файле), и режим сохранения backup'а стоит full, то восстанавливаем базу без восстановления лога транзакций, почти 100%, что все мучения на этом могут закончиться. 8) Если же наоборот, поврежден ldf-файл, но остался *.mdf файл, при подключении база ругается на отсутствие/повреждение лога транзакций. В этом случае можно воспользоваться ХП "sp_attach_single_file_db" Например: use master EXEC sp_attach_single_file_db @dbname = 'DemoXMB', @physname = 'c:\mssql7\data\DemoXMB_Dat.mdf'

При выполнении этих команд, создастся файл DemoXMB_Log.ldf в том же каталоге где и база, размером 1MB и авторасширением. Если есть *.MDF и *.LDF-файлы, или данные хранятся более чем в одном физическом файле (общее количество подключаемых физических файлов не должно превышать 16-ти), то следует использовать ХП "sp_attach_db" Например:use master EXEC sp_attach_db @dbname = 'DemoXMB', @filename1 = 'c:\mssql7\data\DemoXMB_Dat.mdf', @filename1 = 'c:\mssql7\data\DemoXMB_Log.ldf'

Для подключения более 16-ти физических файлов к БД следует использовать команду: CREATE DATABASE FOR ATTACH

Однако если ничего не помогло, оказались поврежденными оба файла и база всё еще в состоянии suspect, то можно попробовать сбросить состояние базы следующей последовательностью: (перед использованием этой ХП необходимо разрешить прямое изменение системных таблиц:use master go

Разрешаем прямое изменение системных таблиц:sp_configure 'allow updates',1 go reconfigure with override go

Для сброса признака suspect выполняем в БД master ХП sp_resetstatus:sp_resetstatus 'DataBaseName' go

А теперь запретим прямое изменение системных таблиц:sp_configure 'allow updates',0 go reconfigure with override go

В принципе, когда я выполнил все эти шаги, статус suspect сбросился, НО! при попытке выполнить какие-либо действия SQL начинала ругаться, что база все еще в состоянии suspect. И тогда я сделал так: Из QA выполняем скрипт: Use master go sp_configure 'allow updates', 1 reconfigure with override go

Там же выполняем: update sysdatabases set status= 32768 where name = '<db_name>'

Перезапускаем SQL Server. В принципе база должна быть видна (в emergency mode).Из QA выполняем: USE '<db_name>' GO sp_dboption '<db_name>', 'single_user', 'true' go DBCC CHECKDB('<db_name>', REPAIR_ALLOW_DATA_LOSS) go

Если все в порядке, то: sp_dboption '<db_name>', 'single_user', 'false' go Use master go sp_configure 'allow updates', 0 go

После этого стало возможно просмотреть таблицы базы из SQL, а вот работать с ней было невозможно. Теперь необходимо при помощи Data Transformation Services экспортировать данные в новую базу. После этого проводим восстановление/тестирование базы средствами 1С. Внимание! Многие не обращают внимания на этот очень важный пункт. В результате, вы можете в один прекрасный момент обнаружить, что база восстановлена, мягко говоря, не совсем корректно. Т.е. в документе вместо номенклатуры будет стоять нечто вроде 10122/<Объект не найден>, это та проблема, которая возникла у меня, вариантов же может быть уйма. Поэтому лучше потерять время, но проверить базу средствами 1С.

Если уж совсем ничего не помогает, а данные страсть как нужно восстановить, есть еще сторонняя утилита под названием MSSQLRecovery . Утилита платная, но есть возможность воспользоваться демонстрационной версией, которую можно взять здесь: http://www.officerecovery.com/mssql/download_demo.htm . Программа очень простая, и восстановление базы сводится к трем шагам: 1) выбираем файл с базой; 2) выбираем путь куда сохранять; 3) Жмем кнопку recovery; Ждем. Программа разбирает SQL-базу по косточкам и складывает ее в отдельный каталог. Туда же она добавляет и .bat файл для восстановления базы из полученных «кусочков». Я ей так и не воспользовался, т.к. сумел восстановить базу предыдущими шагами.

Но! Здесь следует сделать паузу. Статья не была бы полной, если бы я не описал методы для предотвращения подобных проблем. Итак, самый простой и надежный способ: архивация, архивация и еще раз архивация. В Enterprise Manager заходим в меню Tools->Wizards->Management->Backup Wizard и настраиваем все необходимые параметры. В результате, у меня полный сброс SQL базы на диск происходит ночью, а затем каждые 15 минут backup изменений, внесенных в базу. В принципе, если бы у меня был такой backup, я бы за пару минут сделал откат назад, и продолжил бы попивать Coca-Cola :).

www.compline-ufa.ru

Восстановление SQL базы из бэкапа

Бэкап MS SQL — важнейший элемент обеспечения информационной безопасности серверов MS SQL. Handy Backup предоставляет пользователям эффективное автоматизированное решение, выполняющее бэкап и восстановление базы SQL.

Различные режимы бэкапа

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

Средства безопасности данных

В Handy Backup предусмотрено шифрование бэкапов MS SQL Server встроенным алгоритмом BlowFish и сжатие данных.

Кроме того, в корпоративных сетях снятый с MS SQL бэкап базы может быть переслан на FTP-хранилище по защищённому протоколу SFTP или FTPS.

Автоматический бэкап MS SQL по расписанию

Для задачи создания или восстановления бэкапа MS SQL может быть задано точное время запуска копирования по расписанию, а также интервал повторения этой задачи. Можно сделать бэкап MS SQL и по некоторому событию, например, при подключении USB-диска.

Помимо вышеописанных преимуществ, Handy Backup использует множество других возможностей и функций для повышения эффективности бэкапа MS SQL Server. К числу таких возможностей относятся, в частности:

  • Запуск настроенной программы как службы Windows в "бесшумном" режиме;
  • Горячий бэкап MS SQL, позволяющий обойтись без остановки работы СУБД;
  • Единый плагин для бэкапа MS SQL 2016, 2012, 2008 и ранних версий базы;
  • Отправка отчётов и уведомлений о работе задач администратора по почте.

Рекомендуемое решение для бэкапа MS SQL

Версия 7.18.0 от 22 октября 2018. 164 MBПрограмма резервного копирования Handy Backup. 7400 RUB за лицензию

Handy Backup Office Expert - решениен для небольших предприятий, где базы MS SQL хранятся на одном сервере. Бесплатный пробный период 30 дней!

Чтобы сделать бэкап БД MS SQL, создайте задачу автоматического резервного копирования. Шаги по созданию такой задачи вкратце описаны в нижеприведённой инструкции.

  1. Откройте Handy Backup, создайте новую задачу с помощью кнопки на панели управления или элемента меню.
  2. На Шаге 1 мастера новых задач выберите тип задачи – бэкап (резервное копирование) ваших данных.
  3. Перейдите к Шагу 2. На левой панели (источники данных) разверните список Database и дважды щёлкните на названии MSSQL.

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

  1. Откроется диалог выбора данных. Пометьте “галочками” те базы данных, для которых вы собираетесь делать бэкап MS SQL в создаваемой задаче.
  2. Нажмите ОК, вернитесь в окно Шага 2. Выберите другие данные для бэкапа, если это нужно. Нажмите “Далее”.
  1. На Шаге 3 выберите хранилище для бэкапа базы MS SQL, на Шаге 4 – другие настройки (дифференциальный бэкап, метки и т.д.).
  2. На Шаге 5 укажите параметры сжатия и шифрования данных, если вы хотите сделать бэкап MS SQL Защищённым от случайного доступа.
  3. На Шаге 6 для автоматического бэкапа MS SQL задайте расписание. Выберите время запуска задачи, укажите интервал повторения. Вы также можете указать системные события, при которых задача запускается.
  1. На Шаге 7 вы можете также указать другие программы, запускаемые до и/или после бэкапа MS SQL Server.

С помощью этого шага может быть создана сколь угодно сложная последовательность команд, эффективно заменяющая любой специализированный скрипт бэкапа MS SQL.

  1. На финальном шаге дайте вашей задаче имя. Завершите работу мастера новых задач.

Восстановление бэкапа MS SQL производится с использованием службы SQL Writer Service. Чтобы выполнить восстановление MS SQL Server из бэкапа, создайте задачу автоматического восстановления, как описано ниже.

  1. На Шаге 1 выберите задачу восстановления данных. На следующем шаге откройте ваше хранилище, содержащее файлы бэкапа MS SQL.
  2. Дважды щёлкните на файле backup.hbi в каталоге хранения. Откроется новый диалог.
  3. Нажимайте кнопку "Далее" до конца работы мастера задач, если вам просто нужно восстановить базу MS SQL на то место, откуда она была скопирована.
  1. Если вы хотите перенести базу данных в новое место, создать клон или настроить автоматическую репликацию, то выберите интересующую вас базу и затем нажмите кнопку "Изменить место" в диалоге восстановления.
  2. Откроется диалог изменения места восстановления. Выберите конфигурацию базы данных, в которую вы намереваетесь копировать данные из бэкапа MS SQL.
  3. Далее продолжайте шаг за шагом создавать задачу восстановления.

В решениях Handy Backup Standard и Handy Backup Professional плагин MSSQL отсутствует. В этом случае можно приобрести его для вашей версии Handy Backup отдельно. Это решение оправдано, например, в следующих случаях:

  • Создание копий устаревших версий базы данных (например, бэкап MS SQL 2008) в тех случаях, когда использование специализированного плагина нецелессобразно;
  • Бэкап локальных или небольших баз данных, тесно связанных с приложениями на рабочих станциях (например, бэкап MS SQL Express).

Приобретение плагина MSSQL для решения вышеописанных задач освобождает пользователя от необходимости устанавливать и обслуживать более дорогое программное обеспечение серверного уровня для рабочих станций и отдельных машин.

В Handy Backup бэкап БД MS SQL может храниться на множестве современных носителей информации. К числу поддерживаемых хранилищ относятся:

  1. Локальные и внешние жёсткие диски, USB устройства;
  2. Сетевые диски и папки, устройства NAS, сетевые машины*;
  3. Серверы хранения информации, работающие по протоколам FTP, SFTP и FTPS;
  4. Облачные сервисы: Amazon S3, Google Диск, Яндекс.Диск, Dropbox, OneDrive;
  5. Любые коммерческие и частные облака, поддерживающие протокол WebDAV;
  6. Специализированное защищённое облачное хранилище для бэкапов – HBDrive.

*Обмен данными с машинами в локальной сети, помимо специализированных интерфейсов и протоколов, поддерживается только сетевыми решениями - Handy Backup Network и Handy Backup Server Network с установленными на удалённых машинах Сетевыми Агентами!

Handy Backup – мощное, универсальное решение, обеспечивающее бэкап MS SQL и восстановление данных. Попробуйте прямо сейчас, скачав и установив полную версию программы на 30-дневный бесплатный пробный период!

Читайте также:

www.handybackup.ru

Автоматический бэкап 1С файловой и SQL-версии

Программа Handy Backup – это удобное и эффективное решение для автоматизации бэкапа баз 1С, т.е., для создания и восстановления резервных копий данных 1С.

Простая настройка бэкапа 1С и восстановления, множество инструментов и функцйи Handy Backup экономят ваше время, силы и финансы. Также при помощи Handy Backup легко автоматизировать бэкап баз данных, почты, веб-сайтов, библиотек Windows, файлов, папок, образа диска, используя различные функции бэкапа.

Планирование задач бэкапа 1С

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

  • Осуществляйте регулярный запуск задачи бэкапа в удобное время или через через заданный интервал, а также при входе или выходе из системы.
  • Можно также настроить автоматический бэкап 1С при подключении связанного с задачей устройства USB.
  • При необходимости можно установить автоматический перезапуск для пропущенных по расписанию задач.

Оптимизация бэкапа 1С

Дифференциальное, смешанное и инкрементальное копирование, а также Zip-сжатие позволяют:

  • сэкономить место, занимаемое копиями 1С на устройствах и сервисах хранения;
  • уменьшить время бэкапа и затраты сетевых ресурсов на пересылку данных.

Возможен запуск Handy Backup как службы Windows, что позволяет не отвлекать пользователей сообщениями интерфейса программы.

Удобное хранение резервных копий 1С

Handy Backup предлагает большой выбор устройств и методов хранения бэкапа 1С: локальные, подключаемые или сетевые диски, флэш-память, сетевые накопители (NAS), файловые хранилища по протоколу FTP/SFTP/FTPS, а также облачные сервисы, включая Яндекс Диск, Amazon S3, онлайн бэкап HBDrive.

Резервные копии сохраняются в папки с временными метками управляемого формата. Старые копии при необходимости автоматически удаляются.

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

Испытайте всю мощь и удобство автоматического бэкапа 1С прямо сейчас: скачайте и установите Handy Backup! Бесплатный полнофункциональный пробный период 30 дней!

Продвинутое управление бэкапом 1С

Автоматическое отключение системы 1С перед копированием поможет избежать потери данных при незавершённых транзакциях и создать целостную резервную копию.

Для мониторинга бэкапа и восстановления 1С существуют Email-уведомления и подробные логи всех операций.

Поддержка интерфейса командной строки позволяет включать выполнение задач Handy Backup в пакетные файлы инструкций.

Запуск других программ до или после бэкапа 1С делает возможным включение задач по защите данных 1С в общий план работ.

Бэкап всех версий 1С

Программа Handy Backup сертифицирована фирмой “1С” и совместима с системой программ “1С: Предприятие” для выполнения бэкапа баз 1С версий 8.2, 7.7, 8.0, 8.1, 8.3.

Handy Backup осуществляет автоматический поиск и бэкап данных файловой СУБД 1С, а также бэкап SQL баз 1С таких СУБД: MS SQL, Oracle, PostgreSQL, IBM DB2.

Быстрое и эффективное восстановление данных 1С

С помощью Handy Backup вы можете автоматически восстановить систему 1С в произвольное место отличное от исходного, например, с целью создания копии.

Выбор отдельных таблиц или баз 1С для восстановления позволяет не тратить время на полное восстановление всей системы, уменьшая общее время простоя.

Предусмотрена возможность “отката” базы 1С к определённой версии или дате.

Широкий выбор функциональных решений Handy Backup позволяет каждому пользователю выбрать функционально подходящее для него решение по приемлемой цене. Техническая поддержка Handy Backup осуществляется бесплатно - поможем установить и настроить программу, отладить бэкап 1С на вашем предприятии!

Версия 7.18.0 от 22 октября 2018. 164 MBПрограмма резервного копирования Handy Backup. 7400 RUB за лицензию

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

Версия 7.18.0 от 22 октября 2018. 164 MBПрограмма резервного копирования Handy Backup. 39000 RUB за лицензию

Версия предназначена для обслуживания сети клиентских и серверных компьютеров с управлением из центральной консоли. Бесплатный пробный период 30 дней!

К настоящему моменту Handy Backup – одна из самых востребованных программ на рынке резервного копирования. Вы можете не только защищать свои данные, но и внедрять решения Handy Backup на различных предприятиях, став нашим дистрибьютером. За подробной информацией о сотрудничестве обращайтесь, пожалуйста, по адресу [email protected].

Читайте также:

www.handybackup.ru

Бэкап sql баз 1С

1С + MSSQL server: автоматическое создание резервных копий

Резервное копирование и восстановление системных баз данных в SQL Server 2014

SQL и 1с 8 - бэкап и восстановление из журналов транзакций

SQL Создание бэкапа - копии базы данных - резервное копирование БД

Обслуживание баз данных 1С на MS SQL сервере.

Резервное копирование и восстановление в MS SQL Server

Бэкап клиент - серверных баз в 1С Предприятии

Бэкап файловой базы 1С Предприятия.

Перенос баз данных MS SQL Server с одного ПК на другой.

Резервное копирование базы данных в 1С 8

Также смотрите:

  • Реестр расходов 1С
  • 1С представление периода
  • Презентация 1С торговля и склад
  • Оформление путевых листов в 1С
  • Программа для сервисного центра 1С
  • Хранилище значений 1С files
  • 1С кортес адресный склад
  • Программа 1С базы данных
  • Пользовательские поля 1С строка
  • Договор подряда в программе 1С
  • Расчет резерва отпусков в 1С зуп
  • 1С 8 проверить что это не группа
  • 1С 8 2 инвентарный номер список
  • Ingenico ict220 подключение к 1С инструкция
  • Табличная часть документа 1С 8 2 методы
Главная » Клипы » Бэкап sql баз 1С

buhchita.ru