Куда создается резервная копия 1с 11.1.

Бэкапер-1С: резервные копии бухгалтерии 1С (8.3, 8.2, 8.1, 7.7)

2017-05-12T19:44:44+00:00

Удивительно, как мало знакомых бухгалтеров задумывается о резервном копировании баз 1С и документов!

А ведь по статистике критический возраст для жёстких дисков наступает через 3 года использования и спустя это время вероятность потери данных особенно велика.

И хорошо, если есть программист. Худо-бедно, но раз в месяц он копию сделает. А, если речь о бухгалтере на дому? Обычно тянут с архивацией до последнего, крайнего случая.

И как жаль бывает потраченных сил, если такой случай настаёт. Как много времени, средств и нервов уходит на восстановление учёта!

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

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

А ему всего-то надо сохранять свои данные, скажем, раз в неделю. Какая простая задача и какие сложные инструменты для её решения нам зачастую предлагают!

Бэкапер-1С Резервные копии бухгалтерии - очень надёжная, но в то же время простая в использовании программа архивации ваших баз 1С и документов.

Сразу после установки Бэкапер-1С готов к работе. Можно больше ничего не настраивать. Каждый раз при запуске он сам будет находить:

• Базы 1С 7.7
• Базы 1С 8.3, 8.2, 8.1, 8.0
• Офисные документы на “Рабочем столе”

В 90% случаев этого оказывается достаточно!

Бэкапер-1С многое умеет. Вот некоторые из его возможностей:

• Автоматический поиск баз.
• Поддержка файлов большого размера (свыше 4 гигабайт).
• Встроенный архиватор 7-Zip и, как следствие, очень высокая скорость работы.
• Целостность создаваемых копий (за счёт блокировки на запись перед копированием).
• Гибкая система удаления старых копий .
• Каталогизация архивов по году, месяцу и числу.
• Шифрование архивов по паролю.
• Запуск по расписанию .
• Отправка отчетов на почту.
• Корректная работа с русскими именами документов.

Вы ещё сомневаетесь относится ли ваш случай к счастливым 90%? Тогда установите Бэкапер-1С и нажмите кнопку "Сделать архив" - всё остальное он сделает за вас.

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

С уважением, Владимир Милькин (преподаватель

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

При сбое резервное копирование не восстановит систему. Зачем же оно нужно?

Вокруг функции создания резервных копий существует несколько мифов. Один из них связан с назначением такой опции. Многие полагают, что автоматическая архивация базы 1С помогает:

1. развернуть копию всей системы;
2. восстановить ее работоспособность.

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

Архив, который создается 1С, представляет собой полную систему резервных копий. Сюда не входят разве что журналы регистрации и конфигурации вида отображения различных вкладок. Существует два варианта архивирования: ручное и автоматическое по расписанию. Первый способ используется редко, куда удобнее, чтобы сама система в заданные промежутки производила автообновление созданных копий. Осуществляется это с помощью инструментария MS SQL. Раньше, в версии 1С: предприятие 7.7 оно не было полноценным, но с выходом версий 8.1, 8.2, 8.3 этот функционал работает точно, словно швейцарские часы.

Но для этого должны быть соблюден ряд важных условий.

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

Итак, стоит подробнее рассмотреть вопрос о том, как настроить автоматическое резервное копирование 1С версии 8.3 (в версиях 8.2 и 8.1 алгоритм идентичен).

Настройка автоматического автоархивирования в файловом режиме

Для выполнения этой задачи потребуется пункт «Поддержка и обслуживание», который расположен во вкладке с названием «Администрирование».

Настройка автоматического копирования 1С осуществляется в одноименном пункте раскрывающегося меню.

На этом этапе необходимо определиться с тем, где будут храниться создаваемые копии. Доступно несколько вариантов:

• внешний жесткий диск;
• в памяти стационарного компьютера;
• с помощью сервиса под названием «1С Облачный архив».

Открыв вкладку «Резервное копирование и восстановление» можно также использовать опцию ручного запуска архивации. Автоматическое копирование баз программы 1С будет осуществляться после задания соответствующих параметров в пункте, который посвящен настройкам данной опции.

Автоматическое резервное копирование в 1С версии 8.3 можно задать при разных условиях:

• по расписанию;
• при закрытии программы.

Если работа с продуктом осуществляется разными пользователями, то выбрать лучше всего первый вариант. Так, отметив пункт «Регулярно по расписанию» можно указать период архивации, например, каждый день. Так в 1С будет создаваться резервная копия при автоматическом обновлении архива по заданному вами параметру.

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

Настройка автосохранения базы с помощью средств MS SQL

Есть еще один вариант решения рассматриваемой задачи - использование бэкапов посредством инструментов СУБД - Postgre, MS SQL. Автоматическое сохранение данных 1С с помощью этих средств позволяет работать как с файлами, так и с группами, создает несколько зеркальных копий, а также всегда сжимает архивные материалы для экономии пространства.

Для начала необходимо открыть автоархиватор с названием SQL Server Studio. Он доступен в общем списке всех утилит компьютера.

Если использовать Microsoft Windows Server 2008 (R2), то нужно выйти в меню кнопки «Пуск», затем выбрать «Microsoft SQL Server 2012», а далее «Среда SQL Server Management Studio».

После этого в обозревателе объектов нужно раскрыть вкладку под названием «Базы данных». Необходимо кликнуть правой кнопкой мышки по базе, которая содержит нужную информацию. В появившемся контекстном меню выбираем опцию «Задачи», а далее - «Создать резервную копию…» (так называемый backup).

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

• базу данных;
• тип резервной копии (полная, частичная и т. д.);
• компоненты для архивации (только выбранные файлы или всю базу данных);
• срок обновления копий (если выбрать 0 дней, то и данные перезаписываться не будут);
• место хранения архива.

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

Также здесь можно изменить или добавить иное место расположения резерва, имя создаваемого файла. Для этого нужно нажать кнопку «Добавить». Выбрать каталог и имя файла в раскрывающемся окне и нажать кнопку подтверждения изменений «Ok».

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

База будет в еще большей безопасности, если установить галочку напротив параметра сжатия копий. Так будет экономиться пространство памяти. Нажав кнопку «Ok», вы запустите процесс архивации.

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

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

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

Этот документ включает в себя такие сведения, как:

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

Выгрузка этих сведений требует раскрытия соответствующую запросу группировки внутри отчета.

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

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

Администраторы БД делятся на тех, кто делает бэкапы, и тех, кто будет делать бэкапы.

Введение

В этой статье описано самое обычное резервное копирование ИБ 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 администраторы баз данных наконец-то смогли расслабиться. Штатные средства резервного копирования позволяют создать полную и целостную систему резервных копий. Не входит в резервное копирование только журнал регистрации и некоторые мелочи типа настроек положения форм (в старых версиях), но это потеря этих данных на функциональности системы в не сказывается, хотя безусловно резервные копии журнала регистрации делать правильно и полезно.

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

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

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

• Обеспечьте физическую безопасность серверов: пожары, затопления, плохое электропитание, уборщицы, строители, метеориты и дикие животные — все они только и ждут за углом, чтобы уничтожить вашу серверную.
• Ответственно относитесь к угрозам информационной безопасности.
• Квалифицированно вносите изменения в систему и заранее максимально убедитесь, что эти изменения не приведут к ухудшениям. Кроме плана внесения изменений желательно иметь и план "что делать, если всё пойдёт не так".
• Активно используйте технологии повышения доступности и надёжности системы вместо того, чтобы потом разгребать последствия аварий. Для 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. Все РКЖТ, от момена последней разностной копии до момента восстановления

• Полная копия 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)

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

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

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

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

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

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

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

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

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

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

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

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

РКЖТ

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

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

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

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

BACKUP DATABASE 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 файла, по принципу чередования. И каждая из них в отдельности будет бесполезна.

Как сделать копию базы 1С самостоятельно? - Для админов это вопрос бесхитростный (хотя эти бекапы всегда куда-то улетучиваются). Это интересует скорее бухгалтеров, которые работают дома, обслуживая серию предприятий. Рассмотрим несколько решений для такой миссии.

Выполнить копирование имеющейся базы 1С может пользователь.

Копипаст

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

Смысл его в том, что абоненту нужно скопировать базу 1С в какое-то (желательно недоступное) место. Наверное, наилучшим выбором стало бы копирование и содержание копии в облаке . Но сначала нужно отыскать папку, где содержится объект нашего стремления. Для этого в окошке обычного запуска программы нужно выделить курсором искомую базу. Тогда внизу будет отражён путь к ней.

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

Выгрузка

Этот способ является универсальным для любых платформ. С его помощью конфигурация выгружается в файл с расширением *dt. Для выгрузки базы программа запускается в режиме «Конфигуратор». Для выгрузки выбирается в меню (после запуска) команда «Администрирование» / «Выгрузить ИБ»:

Следующим шагом будет указание в диалоговом окне местоположения и имени для сохранения, - вводим и требуем «Сохранить». Удобно выбирать имя для сохранения в формате: ГГГГММДД.dt, - соответствующем дате создания копии. Удачное завершение будет отмечено системой:

ВАЖНО. Всем пользователям системы перед выгрузкой архива нужно выйти, завершив работу.

Создание копии при обновлении

Не всем известно о возможности бекапиться через интернет, не покидая 1С при загрузке новых релизов. Наверное, просто дело привычки. Но этот способ явно удобен. Им можно воспользоваться, настроив запуск обновления так, чтобы создание резервного файла-архива происходило программно (автобекап) в заранее указанном месте. Необходимые действия видны из рисунка:

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

Резервное копирование в 1С 8.3 и 8.2 — это важнейшая операция, которую должен уметь делать каждый пользователь, программист, администратор. Такое копирование специалисты по информационным технологиям также часто называют бэкап 1С. Рассмотрим, что это такое и подробную инструкцию.

Люди делятся на две категории: на тех, кто ещё не делает бэкапы, и на тех, кто уже делает. — Шутка системных администраторов.

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

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

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

Получите 267 видеоуроков по 1С бесплатно:

Инструкция по резервному копированию в 1С

Рассмотрим краткую инструкцию по снятию бэкапа базы данных в 1С. Инструкция подойдет как для файлового режима работы базы, так и клиент-серверного.

Выгрузка копии базы данных в файл

Войдите в программу в режиме конфигуратор. Для этого в стартовом окне программы выберите нужную базу данных и нажмите «Конфигуратор»:

Вы попадёте в режим разработки и администрирования базы данных. Далее выберите в меню пункт «Администрирование — Выгрузить информационную базу…»:

Программа предложит выбрать путь, куда выгрузить файл базы данных, и его название. После выбора программа сообщит об успешном завершении операции:

Файл лучшего всего сохранять на внешний носитель (например, флешка, внешний жесткий диск).

Как восстановить базу 1С 8.3 из резервной копии

Для восстановления базы данных из файла требуется зайти так же в режим конфигуратора, но выбрать уже пункт «Администрирование — Загрузить информационную базу…»: