Рассмотрим, как организовать две наиболее часто встречающиеся задачи администрирования SQL Server’а:
- Автоматическое резервное копирование баз данных;
- Удаление старых резервные копии.
Планирование резервных копий базы данных
- Откройте SQL Management Studio и подключитесь к требуемой базе данных. Убедитесь, что SQL Server Agent работает;
- Разверните узел Management – Maintenance (для этого у Вас должна быть роль «SYSADMIN») – щелкните правой кнопкой и выберите «New Maintenance Plan»;
- Введите имя нового плана обслуживания;
- Щелкните по иконке календаря справа в единственной строке. В открывшемся окне сконфигурируйте время выполнения задания. Выберите такое время, когда база данных меньше загружена;
- Из раздела Toolbox перетащите задачу Backup Database Task в основную область;
- Дважды щелкните по Backup Database Task – откроется окно настроек задачи резервного копирования – задайте нужные настройки;
- Щелкните ОК – теперь резервные копии будут создаваться в соответствии с запланированным временем;
Удаление старых резервных копий
Так как файлы резервных копий будут создаваться часто, то в скором времени свободного места на жестком диске у Вас поубавится. Поэтому Вам нужно будет удалять устаревшие файлы резервных копий. Продолжим конфигурировать план обслуживания:
- Из панели Toolbox перетащите в основную область задачу Maintenance Cleanup Task;
- Дважды щелкните по Maintenance Cleanup Task, чтобы открыть окно свойств. В нем Вы должны определить расположение резервных копий, их расширение и определить возраст файлов подлежащих удалению. Хорошей практикой является хранение бэкапов до одного месяца;
- Жмите ОК и сохраняете план обслуживания;
- Дальше можете либо дождаться следующего времени выполнения плана обслуживания, либо выполнить его вручную (правой кнопкой мыши по плану обслуживания в Object Explorer).
А также: бэкап SQL, бэкап 1С.
Серверная 1С содержит данные в базе данных, которая находится на SQL сервере. Сегодня мы рассматриваем вариант MS SQL 2005/2008.
Чтобы данные не были потеряны в случае сгоревшего диска сервера или других форс-мажорных ситуаций – необходимо с самого начала делать бэкапы (backup).
Делать ручками каждый день Backup SQL базы 1С конечно никто не хочет. Для этого есть автоматические средства. Познакомимся с ними.
Настройка Backup SQL
Настройка Backup SQL для базы 1С ничем не отличается от настройки бэкапа для любой другой базы данных.
Для настройки запустите MS SQL Management Studio. Эта программа находится в группе программ MS SQL.
Добавление задания бэкапа SQL базы 1С
Задания автоматического бэкапа баз SQL находятся в ветке Management / Maintenance plans.
Чтобы добавить новое задание бэкапа щелкните на группу Maintenance plans правой кнопкой мыши и выберите New Maintenance Plan.
Введите название задания. Название имеет значение только для Вас. На всякий случай лучше использовать английские символы.
Настройка задания бэкапа SQL базы 1С
Откроется редактор заданий. Обратите внимание – задания могут делать различные операции с базой данных, а не только бэкапы.
Список вариантов операций выведен слева внизу. Выберите Back Up Database Task двойной кнопкой мыши или просто перетащите вправо.
Обратите внимание на стрелочку. Вы можете перетащить несколько различных или одинаковых операций и связать их стрелочками. Тогда будет выполняться сразу несколько заданий в определенной Вами последовательности.
В окне настройки выберите нужные базы SQL 1С (можно сразу несколько или по одной).
Выберите место сохранения бэкапа базы SQL 1С. Необходимо выбрать физически другой винчестер. Организационно можно поставить галочку «Создать подпапки».
Теперь настроим расписание backup. Расписание backup по-умолчанию добавилось само. Но Вы можете добавить несколько расписаний (например, одно – ежедневное, одно – еженедельное и т.п.). Нажмите кнопку настройки расписания backup.
На скриншоте пример ежедневного Backup SQL базы 1С в 3 ночи.
Чтобы расписание backup в списке было красиво-понятным, его можно изменить.
Сохранение задания бэкапа SQL базы 1С
Нажмите записать. Задание появится слева в списке.
Это важно! Проверьте правильность создания задания Backup SQL базы. Для этого нажмите на задании правой кнопкой и выберите Execute.
В результате должен появится файл бэкапа по указанному пути. Если что-то не так – удалите задание (Del) и начните с начала.
Администраторы БД делятся на тех, кто делает бэкапы, и тех, кто будет делать бэкапы.
Введение
В этой статье описано самое обычное резервное копирование ИБ 1С при помощи инструментов MS SQL Server 2008 R2, объяснено почему следует делать именно так, а не иначе, и развеяно несколько мифов. В статье достаточно много ссылок на документацию MS SQL, эта статья скорее обзор механизмов резервного копирования, чем всеобъемлющее руководство. Но для тех, кто сталкивается с этой задачей впервые, даны простые и пошаговые инструкции, которые применимы к простым ситуациям. Статья предназначена не для гуру администрирования, гуру и так всё это знают, но предполагается, что читатель способен сам установить MS SQL Server и заставить это чудо враждебной техники создать в своих недрах базу данных, которую в свою очередь он же способен заставить хранить данные 1С.
Я считаю команду TSQL BACKUP DATABASE (и её брата BACKUP LOG) по сути единственным средством резервного копирования баз 1С, использующих MS SQL Server в качестве СУБД. Почему? Давайте рассмотрим, какие у нас способы вообще есть:
| Как | Хорошо | Плохо | Итого |
| Выгрузка в dt | Очень компактный формат. | Долго формируется, требует монопольного доступа, не сохраняет часть малозначительных данных (таких как настройки пользователей в ранних версиях), долго разворачивается. | Это не столько способ резервного копирования, сколько способ переноса данных из одной среды в другую. Идеален для узких каналов. |
| Копирование файлов mdf и ldf | Очень понятный способ для начинающих админов. | Требует освобождения файлов базы данных от блокировки, а это возможно, если база отключена (команда take offline контекстного меню), отсоединена (detach) или просто остановлен сервер. Очевидно, что пользователи в это время работать не смогут. | Этот способ имеет смысл применять тогда и только тогда, когда уже произошла авария, чтобы при попытках восстановления хотя бы иметь возможность вернуться к тому варианту, с которого началось восстановление. |
| Резервное копирование средствами ОС или гипервизора | Удобный способ для сред разработки и тестирования. | Не всегда дружит с целостностью данных. Ресурсоёмкий способ. | Может ограниченно применяться для разработки. В продуктовой среде практического смысла не имеет. |
| Резервное копироавние средствами MS SQL | Не требует простоев. Позволяет восстановить целостное состояние на произвольный момент, если заранее об этом побеспокоиться. Отлично автоматизируется. Экономный по времени и другим ресурсам. | Не очень компактный формат. Не все умеют пользоваться этим способом в необходимой мере. | Для продуктовых сред — основной инструмент. |
Основные сложности при использовании резервного копирования встроенными средствами MS SQL возникают из-за элементарного непонимания принципов работы. Это объясняется отчасти великой ленью, отчасти отсутствием простого и понятного разъяснения на уровне «готовых рецептов» (хм, скажем так, мне не встречалось), да еще и усугубляется ситуация мифосоветами «недогуру» на форумах. Что делать с ленью я не знаю, а вот объяснить основы резервного копирования попробую.
Что и зачем сохраняем?
Давным-давно в далёкой галактике существовал такой продукт инженерно-бухгалтерской мысли, как 1С:Предприятие 7.7. Видимо из-за того, что первые версии 1С:Предприятия разрабатывались для использования популярного формата файлов dbf, его SQL-версия не хранила в базе данных достаточно информации для того, чтобы считать резервное копирование MS SQL полноценным, да еще и при каждом изменении структуры нарушались условия работы полной модели восстановления, поэтому приходилось идти на разные ухищрения, чтобы заставить систему резервного копирования исполнять свою основную функцию. Но, с тех пор, как появилась версия 8 администраторы баз данных наконец-то смогли расслабиться. Штатные средства резервного копирования позволяют создать полную и целостную систему резервных копий. Не входит в резервное копирование только журнал регистрации и некоторые мелочи типа настроек положения форм (в старых версиях), но это потеря этих данных на функциональности системы в не сказывается, хотя безусловно резервные копии журнала регистрации делать правильно и полезно.
А зачем вообще нам нужно резервное копирование? Хм. На первый взгляд странный вопрос. Ну, наверное, во-первых, чтобы иметь возможность развернуть копию системы и во-вторых восстановить систему при сбое? На счет первого я согласен, а вот второе назначение — первый миф резервного копирования.
Резервное копирование — это последний рубеж обеспечения сохранности системы.
