Рассмотрим правильный вариант создания резервных копий базы 1С. Правильный вариант это значит использование средств самой внешней СУБД, а именно SQL Server 2008. Что нам это дает? Не требует монопольного доступа, это, пожалуй, один из самых весомых плюсов, что дает возможность создавать резервные копии в любой момент, не зависимо от того, есть пользователи в базе или нет.
Если это делать средствами самой 1С, то приходится изобретать некоторый велосипед, то есть писать скрипт, который выгоняет пользователей на время выгрузки самого этого файла. Надо признать, что данная процедура не очень удобная и по большому счету не всегда можно сделать бэкап Microsoft SQL Server, то есть резервную копию. Второй плюс – это надежность, с надежностью SQL Server никто спорить не станет. Третье – это быстрота, можно убедиться, что подобные копии создаются намного быстрее. Нельзя также забывать о повышении чувства собственной важности.
Дело в том, что когда все остальные используют общедоступные какие-то “костыли”, скрипты и сторонние приложения, которые автоматизируют процесс выгрузки файлов, мы будем использовать более совершенные средства. Ну, и еще одни из многочисленных плюсов подобной процедуры, это то, что выгруженные файлы занимают меньше места в дисковом пространстве и удобство восстановления.
Дело в том, что мы можем настроить резервное копирование и последующее восстановление вплоть до каждого часа работы, то есть мы можем восстановить базу, скажем на 15.00, когда у нас был создан последний журнал транзакций. Для начала нужно подготовить базу, для этого выберем модель восстановления, заходим в свойства базы через Management Studio, свойства, опции, выбираем полную модель восстановления. Полная модель нужна для того, чтобы создавать также и резервные копии журналов транзакций.
Для чего это нужно, узнаем чуть позже. Далее жмем ОК и подготавливаем папку, куда будем выгружать файлы резервных копий. Сначала разберем в ручном варианте, как все это работает, затем уже настроим планировщик задач. Как это вообще все происходит? Сперва, предположим раз в неделю, выполняем полную копию базы данных, то есть всех таблиц и активную часть журнала транзакций. Далее, каждый день мы будем создавать, это оптимальный план для большинства организаций, дифференцированную копию нашей базы.
Дифференцированная, значит хранящая в себе лишь измененные таблицы с момента полного резервирования. Затем, к примеру, ежечасно создаем копию журнала транзакций, и это нам позволяет восстановить базу вплоть до каждого часа, то есть мы восстанавливаем полную копию, далее последнюю интересующую нас дифференцированную и если необходимо на какой-то определенный час, мы до этого часа накатываем копию журналов транзакций. Таким образом, получаем работоспособную базу вплоть до определенного часа. Это очень удобно и довольно быстро.
Создание резервных копий с помощью SQL это не такая уж сложная работа, все гораздо проще, чем многие думают, гораздо эффективнее, гораздо быстрее и надо отметить, что гораздо приятнее. На самом деле данная процедура куда лучше, чем ковыряться с непонятными скриптами и что-то там изобретать, придумывать и постоянно нервничать, - “а прошло ли у нас сегодня ночью резервное копирование или все-таки кто-то зашел, наш скрипт не сработал, резервной копии нет, все рухнет и нас завтра уволят”. Такого теперь не будет, мы можем спать спокойно и восстанавливать все гораздо удобнее.
Карта сайта || Начало раздела || Уникальные издания || Компьютеры