Приветствую, в данной заметке будет рассмотрено создание резервных копий и восстановление в MS SQL Server. Резервное копирование необходимо делать каждый раз, когда создаются, удаляются или изменяются пользовательские базы данных. Используется в качестве шаблона для создаваемых баз данных. Хранит временные данные например для транзакций. Резервное копирование делать нет смысла. Включает в себя файлы данных и журнал транзакций. По сути является базой данных на момент создания резервной копии базы данный MS SQL Server. Резервное копирование изменений, возникающих во время резервного копирования. Резервное копирование транзакций, не зафиксированных в журнале транзакций. Способ 2 Запрос SQL: Включает в себя все изменения базы данных с момента последнего полного резервного копирования. Нельзя восстановить без полной резервной копии. После каждого запуска разностного копирования, размер резервной копии возрастает из-за количества транзакций с момента полного резервного копирования. При создании разностного резервного копирования выполняются следующие действия: Создание резервных копий баз данных, которые изменились с момента полного резервного копирования. Создание резервных копий всех операций, выполняющихся во время разностного резервного копирования и всех транзакций не зафиксированных в журнале транзакций. Далее по аналогии с полным запустим задачу резервного копирования, но модель выберем — разностную: Проведем полный бэкап, добавим еще данных, проведем разностный бэкап: Вывод, не надо доводить разностное копирование до больших объемов, иначе оно теряет свой смысл быстрого восстановления данных. Содержат все изменения базы данных при первичном резервном копировании лога транзакций, или изменения с последней успешной резервной копии журнала транзакций. Не имеет смысла, если хоть раз не выполнялось полное резервное копирование, так как резервную копию лога невозможно будет восстановить при отсутствии полной резервной копии. Создается копия журнала транзакций от последнего резервного копирования лога до конца текущего. Очищаются части журнала транзакций до начала активной части и отбрасываются сведения в неактивной части. По аналогии с полным и разностным копированием запускаем задачу, но тип выбираем — лог транзакций: По сути являются именованными коллекциями файлов и используются для упрощения размещения данных и выполнения задач администрирования. Управление пространством журнала отделено от управления пространством данных, возможно только полное и разностное резервное копирование файлов и файловых групп. В этой точке базы данных обычно имеются незафиксированные транзакции, и потому база находится в непригодном для работы состоянии. В этом случае следует производить в процесс восстановления базы данных стадию отмена. После завершения стадии отката восстановление последующих резервных копий становится невозможным. Затем в процессе восстановления база данных переводится в активный режим. Режим WITH RECOVERY включает и стадию повтора, и стадию отката и восстанавливает базу данных. Более поздние резервные копии восстановить невозможно. Это значение по умолчанию. Если набор данных наката не был восстановлен в достаточной степени, чтобы обеспечить согласованность с базой данных, стадия отката выполнена быть не может. Компонент Database Engine выдает ошибку и прекращает восстановление. Если весь набор данных наката согласован с базой данных, то выполняется восстановление, после чего базу данных можно перевести в режим в сети. Предложение WITH NORECOVERY позволяет пропустить стадию отката, чтобы сохранить незафиксированные транзакции. Пропуск стадии отката позволяет восстановить другие резервные копии, чтобы выполнить накат базы данных на более поздний момент времени. Иногда инструкция RESTORE WITH NORECOVERY выполняет накат данных до момента, пока они не будут согласованы с базой данных. В таких случаях компонент Database Engine выдает информационное сообщение, указывающее, что набор данных наката теперь можно восстановить при помощи параметра RECOVERY. Другими словами, параметр NORECOVERY нужно использовать, когда для восстановления базы используются несколько восстанавливаемых резервных копий, за исключением последней восстанавливаемой резервной копии. После применения параметра NORECOVERY, база данных переходит в состояние восстановления. В начале восстанавливается полная копия например в прошлом шаге мы это уже сделали , а далее восстановим разностную копию. Графический интерфейс аналогичен с предыдущим примером за исключением типа выбираемой копии, а запрос будет таков на примере наших разностных копий: В начале следует восстановить базу данных из полной резервной копии, затем накатить на базу последовательно резервные копии журнала транзакций. Графический вариант интуитивно понятен, будет продемонстрирован только SQL запрос: Для того, чтоб все отработало корректно, вернемся разностному бэкапу 2, и после него накатим журнал транзакций: Графический вариант показан не будет, он довольно интуитивен, запрос SQL: Запускаем экземпляр сервера в однопользовательском режиме. Восстановление базы осуществляется так же, как полное восстановление пользовательской базы данных. После восстановления следует перезапустить экземпляр SQL сервера. Запускаем экземпляр сервера в однопользовательском режиме: Подключимся к серверу и запустим процесс восстановления базы. Если Вы хотите обменяться ссылками со мной между сайтами - пишите в контактах Видео к статьям на Youtube Мои друзья: При копировании материала с сайта - оставьте ссылку. Эту новость ещё не комментировали Написать комментарий. Создание резервных копий 1 Резервное копирование системных баз данных. Восстановление из резервных копий 6 Восстановление из полной резервной копии. Резервное копирование данных в базе. Резервное копирование изменений, возникающих во время резервного копирования Резервное копирование транзакций, не зафиксированных в журнале транзакций. Способ 1 Графический интерфейс: В процессе выполняются следующие действия: Или с помощью запроса: Файлы журналов не входят в состав файловых групп. По аналогии с другими видами копирования запускаем мастер: Разное Если Вы хотите обменяться ссылками со мной между сайтами - пишите в контактах Видео к статьям на Youtube Мои друзья:
Ваш браузер устарел, пожалуйста обновите ваш браузер пройдя по ссылке www. Администрирование - Архивирование backup. Администраторы БД делятся на тех, кто делает бэкапы, и тех, кто будет делать бэкапы. В этой статье описано самое обычное резервное копирование ИБ 1С при помощи инструментов MS SQL Server R2, объяснено почему следует делать именно так, а не иначе, и развеяно несколько мифов. В статье достаточно много ссылок на документацию MS SQL, эта статья скорее обзор механизмов резервного копирования, чем всеобъемлющее руководство. Но для тех, кто сталкивается с этой задачей впервые, даны простые и пошаговые инструкции, которые применимы к простым ситуациям. Статья предназначена не для гуру администрирования, гуру и так всё это знают, но предполагается, что читатель способен сам установить MS SQL Server и заставить это чудо враждебной техники создать в своих недрах базу данных, которую в свою очередь он же способен заставить хранить данные 1С. Я считаю команду TSQL BACKUP DATABASE и её брата BACKUP LOG по сути единственным средством резервного копирования баз 1С, использующих MS SQL Server в качестве СУБД. Давайте рассмотрим, какие у нас способы вообще есть:. Основные сложности при использовании резервного копирования встроенными средствами MS SQL возникают из-за элементарного непонимания принципов работы. Это объясняется отчасти великой ленью, отчасти отсутствием простого и понятного разъяснения на уровне "готовых рецептов" хм, скажем так, мне не встречалось , да еще и усугубляется ситуация мифосоветами "недогуру" на форумах. Что делать с ленью я не знаю, а вот объяснить основы резервного копирования попробую. Давным-давно в далёкой галактике существовал такой продукт инженерно-бухгалтерской мысли, как 1С: Видимо из-за того, что первые версии 1С: Предприятия разрабатывались для использования популярного формата файлов dbf, его SQL-версия не хранила в базе данных достаточно информации для того, чтобы считать резервное копирование MS SQL полноценным, да еще и при каждом изменении структуры нарушались условия работы полной модели восстановления, поэтому приходилось идти на разные ухищрения, чтобы заставить систему резервного копирования исполнять свою основную функцию. Но, с тех пор, как появилась версия 8 администраторы баз данных наконец-то смогли расслабиться. Штатные средства резервного копирования позволяют создать полную и целостную систему резервных копий. Не входит в резервное копирование только журнал регистрации и некоторые мелочи типа настроек положения форм в старых версиях , но это потеря этих данных на функциональности системы в не сказывается, хотя безусловно резервные копии журнала регистрации делать правильно и полезно. А зачем вообще нам нужно резервное копирование? На первый взгляд странный вопрос. Ну, наверное, во-первых, чтобы иметь возможность развернуть копию системы и во-вторых восстановить систему при сбое? На счет первого я согласен, а вот второе назначение — первый миф резервного копирования. Резервное копирование — это последний рубеж обеспечения сохранности системы. Если администратору базы данных приходится восстанавливать продуктовую систему из резервных копий, значит, с большой вероятностью было допущено множество грубых ошибок в организации работ. Нельзя относиться к резервному копированию, как к основному способу обеспечения целостности данных, нет, это скорее ближе к системе пожаротушения. Она должна быть настроена, проверена и работоспособна. Но если она сработала, то это само по себе является серьёзным ЧП с массой негативных последствий. Для того, чтобы резервное копирование применялось только "в мирных" целях, используйте для обеспечения работоспособности и другие средства:. В зависимости от требований доступности системы и от бюджета, выделенного на эти цели, вполне можно выбрать решения, которые позволят на порядка сократить время простоя и восстановления при сбоях. Не нужно бояться технологий повышения доступности: Но, несмотря ни на что, резервное копирование всё ж таки необходимо. Это тот самый запасной парашют, который вы сможете использовать, когда все остальные средства спасения откажут. Но, как и настоящий запасной парашют, для этого:. Данные в MS SQL обычно хранятся в файлах данных далее ФД — сокращение не общеупотребимое, в данной статье будет еще несколько не очень распространённых сокращений с расширениями mdf или ndf. Кроме этих файлов есть еще журналы транзакций ЖТ , которые хранятся в файлах с расширением ldf. Нередко начинающие администраторы безответственно и легкомысленно относятся к ЖТ, как в отношении производительности, так и в отношении надёжности хранения. Это очень грубая ошибка. На самом деле, скорее наоборот, если есть надёжно функционирующая система резервного копирования и на восстановление системы можно выделить много времени, то можно хранить данные на быстром, но крайне ненадёжном RAID-0 , но тогда ЖТ должны храниться на отдельном надёжном и производительном ресурсе хотя бы на RAID Сразу оговорюсь, что изложение несколько упрощено, но достаточно для начального понимания. В ФД хранятся данные страницами по 8 килобайт которые объединены в экстенты по 64 килобайт, но это не существенно. MS SQL не гарантирует , что сразу после выполнения команды изменения данных, эти изменения попадут в ФД. Нет, просто страница в памяти помечается как "требующая сохранения". Если у сервера достаточно ресурсов, то вскоре эти данные окажутся на диске. Причем, сервер работает "оптимистично" и если эти изменения происходят в транзакции, то они вполне могут попадать на диск до фиксации транзакции. То есть в общем случае, при активной работе ФД содержит разрозненные куски недописанных данных и незавершённых транзакций, для которых неизвестно, будут ли они отменены или зафиксированы. Есть специальная команда " CHECKPOINT ", которая указывает серверу, что нужно "прямо сейчас" сбросить все несохранённые данные на диск, но область применения этой команды достаточно специфична. Достаточно сказать, что 1С её не использует я не сталкивался и понимать, что во время работы обычно ФД не находится в целостном состоянии. Вся эта информация пишется с указанием идентификатора транзакции в которой она произошла и в достаточном объёме чтобы понять как из состояния до этой операции перейти к состоянию после этой операции и наоборот исключение — модель восстановления с неполным протоколированием. Важно, что эта информация пишется на диск сразу. Пока информация не записана в ЖТ, команда не считается исполненной. В нормальной ситуации, когда размер ЖТ достаточного объёма и когда он не сильно фрагментирован, записи в него пишутся последовательно небольшими записями не обязательно кратные 8 кб. В журнал транзакций попадают данные только действительно необходимые для восстановления. В частности не попадает информация о том, какой текст запроса привел к модификациям, какой план выполнения был у этого запроса, какой пользователь его запустил и прочая ненужная для восстановления информация. Некоторое представление о структуре данных журнала транзакций может дать запрос. Из-за того, что жёсткие диски значительно эффективнее работают с последовательной записью, чем с хаотичным потоком команд на чтение и запись и из-за того, что команды SQL будут ждать момента окончания записи в ЖТ, возникает следующая рекомендация:. Если есть хоть малейшая возможность, то в продуктовой среде ЖТ должны располагаться на отдельных от всего остального физических носителях, желательно с минимальным временем доступа для последовательной записи и с максимальной надёжностью. Для простых систем вполне подойдёт RAID Если транзакция отменяется, то все уже внесённые изменения сервер вернёт в предыдущее состояние. Отмена транзакции в MS SQL Server обычно длится сопоставимо с суммарной длительностью операций изменения данных самой транзакции. Старайтесь не отменять транзакции или принимать решение об отмене как можно раньше. Если сервер по каким-то причинам неожиданно прекратит работу, то при повторном запуске будет проанализировано, какие данные в ФД не соответствуют целостному состоянию незаписанные, но зафиксированные транзакции и записанные, но отмененные транзакции и эти данные будут откорректированы. Поэтому если вы, например запустили перестроение индексов большой таблицы и перезапустили сервер, то при повторном запуске уйдёт значительное время на откат этой транзакции, причем прервать этот процесс возможности нет. Что происходит когда ЖТ дошёл до конца файла? Всё просто — если есть освобождённое место в начале, то он начнёт писать в свободное место в начале файла до занятого места. Как закольцованная магнитная лента. Если места в начале нет, то сервер обычно попытается расширить файл журнала транзакций, при этом для сервера выделенный новый кусок является новым виртуальным файлом журнала транзакций , которых в физическом файле транзакций может быть много, но это уже к резервному копированию относится мало. Если у сервера не получится расширить файл закончилось место на диске или запрещено настройками расширять ЖТ , то текущая транзакция отменится с ошибкой А что же надо сделать чтобы место в ЖТ всегда было? Вот тут мы подошли к системе резервного копирования и к моделям восстановления. Для отмены транзакций и для восстановления корректного состояния сервера в случае внезапного выключения необходимо хранить в ЖТ записи, начиная с момента старта самой ранней из открытых транзакций. Этот минимум пишется и хранится в ЖТ обязательно. Вне зависимости от погоды, настроек сервера и желания админа. Сервер не может допустить, чтобы этой информации не было. Поэтому, если открыть в одном сеансе транзакцию, а в других выполнять разные действия, то журнал транзакций может неожиданно закончиться. Самую раннюю транзакцию можно выявить командой DBCC OPENTRAN. Но это только необходимый минимум информации. Дальнейшее зависит от модели восстановления. В SQL Server их три:. Модель Bulk logged для баз 1С использовать почти бессмысленно, поэтому дальше мы её не рассматриваем. А вот выбор между Full и Simple расмотрим подробнее в следующей части. Для любознательных — ссылки на русскоязычную документацию, которая более полно описывает работу журнала транзакций:. Здесь надо не запутаться: Для того чтобы их не спутать, ниже я буду использовать английские термины для модели восстановления и русскоязычные для видов резервных копий. Полная и дифференциальная копия работают одинаково для Simple и Full. Резервная копия журналов транзакций полностью отсутствует в Simple. Позволяет восстановить состояние базы данных на некоторый момент времени на тот в который начато формирование резервной копии. Состоит из постраничной копии используемой части файлов данных и активного куска журнала транзакций за то время пока формировалась резервная копия. Хранит страницы данных, изменившиеся с момента последней полной резервной копии. При восстановлении нужно сначала восстановить полную резервную копию в режиме NORECOVERY , примеры будут приведены ниже , потом можно к получившейся "заготовке" применить любую из последующих разностных копий, но, конечно только из тех, которые сделаны до следующей полной резервной копии. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии. Содержит копию ЖТ за некоторый период. Обычно с момента прошлой РКЖТ до момента формирования текущей РКЖТ. РКЖТ позволяет из восстановленной в режиме NORECOVERY копии на любой момент времени, входящий в период восстанавливаемой копии ЖТ, восстановить состояние на любой последующий момент времени, входящий в интервал восстанавливаемой резервной копии. При формировании резервной копии со стандартными параметрами, место в файле журнала транзакций высвобождается до момента последней открытой транзакции. Очевидно, что РКЖТ не имеет смысла в модели Simple тогда ЖТ содержит лишь информацию с момента последней незакрытой транзакции. При использовании РКЖТ возникает важное понятие — непрерывная цепочка РКЖТ. Эту цепочку может прервать либо потеря некоторых резервных копий этой цепочки, либо перевод базы данных в Simple и обратно. Пусть есть база данных в ГБ. Каждый день база прирастает на 2 ГБ, при этом меняется 10 ГБ старых данных. Сделаны следующие резервные копии. При помощи этого набора мы можем восстановить данные на момент 0: Для этого нам нужно взять полную копию F1 для недели февраля или полную копию F2 для февраля, восстановить её в режиме NORECOVERY и потом применить разностную копию нужного дня. Пусть у нас есть такой же набор резервных полных и разностных резервных копий, как в предыдущем примере. В дополнение к этому есть следующие РКЖТ:. Сначала будет восстановлена F2, потом D2. Но существенное преимущество Full модели в том, что у нас появляется выбор — использовать последнюю полную или разностную копию или НЕ последнюю. Например, если бы обнаружилось, что копия D2. А теперь представим, что мы очень хитрые. И за пару дней до сбоя Мы восстанавливаем на соседнем сервере базу данных из полной резервной копии, оставляя возможность донакатывать последующие состояния разностными копиями или РКЖТ, т. И каждый раз сразу после формирования РКЖТ применяем её к этой резервной базе, оставляя в режиме NORECOVERY. Да ведь на восстановление базы данных у нас теперь уйдёт всего минут, вместо того, чтобы восстанавливать огромную базу! Поздравляю, мы заново изобрели механизм доставки журналов , один из способов снижения времени простоев. Если так передавать данные не раз в период, а постоянно, то получится уже зеркалирование, причем если база-источник ждёт пока база-зеркало обновится, то это синхронное зеркалирование, если не ждёт, то асинхронное. Этот раздел можно смело пропустить, если вам наскучила теория и руки чешутся опробовать настройки резервного копирования. Предприятие по сути не умеет работать с файловыми группами. Есть единственная файловая группа и всё. На самом деле программист или администратор базы данных MS SQL способен некоторые таблицы, индексы или даже куски таблиц и индексов положить в отдельные файловые группы в простейшем варианте — в отдельные файлы. Это нужно либо для того, чтобы ускорить доступ к каким-то данным положив на очень быстрые носители , либо наоборот, пожертвовав скоростью поместить на более дешёвые носители например, малоиспользуемые но объёмные данные. При работе с файловыми группами есть возможность делать их резервные копии отдельно, также отдельно можно и восстанавливать, но нужно учесть, что все файловые группы придётся "догнать" до одного момента накатыванием РКЖТ. Если помещением данных в разные файловые группы управляет человек, то когда внутри файловой группы есть несколько файлов, то данные по ним распихивает MS SQL Server самостоятельно при равном объёме файлов — постарается равномерно. С прикладной точки зрения это используется для распараллеливания операций ввода-вывода. А с точки зрения резервных копий есть другой момент. Для очень больших баз данных в эпоху "до SQL " была типичной проблема выделить непрерывное окно для полной резервной копии, да и диск-приемник для этой резервной копии мог просто её не вместить. Самым простым способом в этом случае было делать резервную копию каждого файла или файловой группы в своё окно. Сейчас, с активным распространением сжатия резервных копий эта проблема стала меньше, но всё же этот прием можно иметь в виду. В MS SQL Server появилась супер-мега-ультра возможность. Отныне и навсегда резервные копии могут быть компрессированными при формировании на лету. Это уменьшает размер резервной копии БД 1С в раз. А учитывая, что обычно производительность дисковой подсистемы является узким местом СУБД, то это даёт не только снижение стоимости хранения, но и еще мощное ускорение резервного копирования хотя и повышается нагрузка на процессоры, но обычно процессорные мощности вполне достаточны на сервере СУБД. Если в версии эта возможность была только для Enterprise редакции которая стоит очень дорого , то в R2 эта возможность отдана в версию Standard, что сильно радует. Ниже при разборе примеров настройки сжатия не рассматриваются, но я настоятельно рекомендую использовать сжатие резервных копий, если нет особых причин его отключить. На самом деле резервная копия это не просто файл, это достаточно сложный контейнер, в котором может храниться много резервных копий. У этого подхода очень древняя история я лично её наблюдаю с версии 6. Для общего развития полезно изучить возможность складывать в один файл несколько резервных копий, но использовать её скорее всего не придётся или если и придётся, то разбирая завалы горе-администратора, который эту возможность неквалифицированно использовал. В SQL Server есть еще одна замечательная возможность. Можно резервную копию формировать параллельно в несколько приемников. Как простейший пример, можно сваливать одну копию на локальный диск и одновременно складывать на сетевой ресурс. Локальная копия удобна, так как восстановление из неё существенно быстрее, удалённая копия зато гораздо лучше перенесёт физическое уничтожение основного сервера базы данных. Этот раздел построен в виде готовых рецептов с пояснениями. Этот раздел очень скучный и длинный за счет картинок, поэтому его можно пропустить. Сразу возникает вопрос, а чего еще надо? Вроде ж только что всё настроили и всё работает как часы? Зачем маяться со всякими скриптами? Планы обслуживания не позволяют:. Полная резервная копия с затиранием существующего файла если есть и проверкой контрольных сумм страниц перед записью. При формировании резервной копии отсчтитывается каждый процент прогресса выполнения. Часто удобно делать сразу не одну резервную копию, а две. Например, одна может лежать локально на сервере чтобы была под рукой , а вторая сразу формируется в физически удалённое и защищённое от неблагоприятных воздействий хранилище:. Важный момент, который часто упускается: Если не указать MIRROR TO , то это будет не 2 зеркальных копии, а одна копия, разбитая на 2 файла, по принципу чередования. И каждая из них в отдельности будет бесполезна. Вы думаете что резервное копирование работает? А вы уверены, что то, что формируется резервным копированием при аварии можно будет использовать для восстановления? Давайте проверим, а заодно научимся восстанавливать данные. Проверка возможностей восстановления — это обязательный этап настройки резервного копирования. Здесь, правда, как с анализами в больнице: Вот и тут также: Но если не ругается, то это еще не окончательная гарантия, что он восстановится. Особенно это актуально для предыдущих версий MS SQL Server. Это, пожалуй, самая частая операция с файлами резервных копий. Делать её можно как скриптом, так и интерактивно. Для самых хитрых и ленивых есть очень полезная возможность создать вариант TSQL из настроенного окна восстановления: Обратите внимание, если указанное время STOPAT назначено после создания последней резервной копии журналов, база данных остается в невосстановленном состоянии, как если бы инструкция RESTORE LOG работала с параметром NORECOVERY. Приведённой информации достаточно для ликбеза по резервным копиям, но недостаточно для практических навыков. Читайте, изучайте, тренируйтесь в "песочнице", естественно. Всё вышеперечисленное применимо далеко не только к 1С: Напоследок ссылочка по теме: Пошаговая инструкция восстановления повреждённой БД доля шутки. Тип файла Нет файла. Платформа Платформа 1С v8. Конфигурация Конфигурации 1cv8 , Не имеет значения. Страна Не имеет значения. Отрасль Не имеет значения. Налоги Не имеет значения. Вид учета Не имеет значения. Раздел учета Не имеет значения. Доступ к файлу Бесплатно free. Код открыт Не указано. По каталогу По форуму. Новости Event Библиотека Конфигурации Разработки Курсы Биржа труда Вакансии Резюме Кабинет Биржа заказов Компании Вебинары Видео Форум ТОП Резервное копирование 1С средствами MS SQL Администраторы БД делятся на тех, кто делает бэкапы, и тех, кто будет делать бэкапы. Введение В этой статье описано самое обычное резервное копирование ИБ 1С при помощи инструментов MS SQL Server R2, объяснено почему следует делать именно так, а не иначе, и развеяно несколько мифов. Давайте рассмотрим, какие у нас способы вообще есть: Как Хорошо Плохо Итого Выгрузка в dt Очень компактный формат. Долго формируется, требует монопольного доступа, не сохраняет часть малозначительных данных таких как настройки пользователей в ранних версиях , долго разворачивается. Это не столько способ резервного копирования, сколько способ переноса данных из одной среды в другую. Идеален для узких каналов. Копирование файлов mdf и ldf Очень понятный способ для начинающих админов. Требует освобождения файлов базы данных от блокировки, а это возможно, если база отключена команда take offline контекстного меню , отсоединена detach или просто остановлен сервер. Очевидно, что пользователи в это время работать не смогут. Этот способ имеет смысл применять тогда и только тогда, когда уже произошла авария, чтобы при попытках восстановления хотя бы иметь возможность вернуться к тому варианту, с которого началось восстановление. Резервное копирование средствами ОС или гипервизора Удобный способ для сред разработки и тестирования. Не всегда дружит с целостностью данных. Может ограниченно применяться для разработки. В продуктовой среде практического смысла не имеет. Резервное копироавние средствами MS SQL Не требует простоев. Позволяет восстановить целостное состояние на произвольный момент, если заранее об этом побеспокоиться. Экономный по времени и другим ресурсам. Не очень компактный формат. Не все умеют пользоваться этим способом в необходимой мере. Для продуктовых сред — основной инструмент. Что и зачем сохраняем? Для того, чтобы резервное копирование применялось только "в мирных" целях, используйте для обеспечения работоспособности и другие средства: Обеспечьте физическую безопасность серверов: Ответственно относитесь к угрозам информационной безопасности. Квалифицированно вносите изменения в систему и заранее максимально убедитесь, что эти изменения не приведут к ухудшениям. Кроме плана внесения изменений желательно иметь и план "что делать, если всё пойдёт не так". Активно используйте технологии повышения доступности и надёжности системы вместо того, чтобы потом разгребать последствия аварий. Для MS SQL следует обратить на следующие возможности: Использование кластеров MS SQL хотя, если честно, я считаю, это одним из наиболее дорогих и бесполезных способов занять администратора БД для систем не требующих 24х7 Зеркалирование базы данных в синхронном и асинхронном режиме в зависимости от требований доступности, производительности и стоимости Доставка журналов транзакций Репликация средствами 1С распределённые базы данных В зависимости от требований доступности системы и от бюджета, выделенного на эти цели, вполне можно выбрать решения, которые позволят на порядка сократить время простоя и восстановления при сбоях. Но, как и настоящий запасной парашют, для этого: Базовая информация о хранении и обработке данных MS SQL Данные в MS SQL обычно хранятся в файлах данных далее ФД — сокращение не общеупотребимое, в данной статье будет еще несколько не очень распространённых сокращений с расширениями mdf или ndf. Чтобы справиться с этим хаосом нам как раз и нужен ЖТ. В него пишутся следующие события: Информация о старте транзакции и её идентификатор. Информация о факте фиксации или отмене транзакции. Информация обо всех изменениях данных в ФД грубо говоря, что было и что стало. Информация об изменении самого ФД или структуры базы данных увеличение файлов, уменьшение файлов, выделение и освобождение страниц, создание и удаление таблиц и индексов Вся эта информация пишется с указанием идентификатора транзакции в которой она произошла и в достаточном объёме чтобы понять как из состояния до этой операции перейти к состоянию после этой операции и наоборот исключение — модель восстановления с неполным протоколированием. Именно поэтому Отмена транзакции в MS SQL Server обычно длится сопоставимо с суммарной длительностью операций изменения данных самой транзакции. В SQL Server их три: Simple Простая — хранится только необходимый для жизни остаток ЖТ. Full Полная — хранится весь ЖТ с момента последнего резервного копирования журнала транзакций. Обратите внимание, не с момента полного бэкапа! Bulk logged С неполным протоколированием — часть очень небольшая обычно часть операций записываются в очень компактном формате по сути только запись, что изменена такая-то страница файла данных. В остальном идентична Full. С моделями восстановления связано несколько мифов. Simple позволяет снизить нагрузку на дисковую подсистему. Bulk logged позволяет снизить нагрузку на дисковую подсистему. Для 1С это почти не так. По сути одна из немногих операций, которая может без дополнительных плясок с бубном подпадать под минимальное протоколирование — загрузка данных из выгрузки в формате dt и реструктуризация таблиц. При использовании модели Bulk logged какие-то операции не попадают в резервную копию журнала транзакций и она не позволяет восстановить состояние на момент этой резервной копии. Это не совсем так. Если операция относится к минимально протоколируемым, то в резервную копию попадут текущие страницы с данными и будет возможность "проиграть" журнал транзакций до конца хотя и нельзя на произвольный момент времени, если есть минимально протоколируемые операции. Для любознательных — ссылки на русскоязычную документацию, которая более полно описывает работу журнала транзакций: Структура журнала транзакций Логическая архитектура журнала транзакций Физическая архитектура журнала транзакций Контрольные точки и активная часть журнала Журнал транзакций с упреждающей записью Управление журналом транзакций Общие сведения о журналах транзакций Модели восстановления и управление журналом транзакций Обзор моделей восстановления Выбор модели восстановления для базы данных Модели восстановления системных баз данных Управление журналом транзакций Усечение журнала транзакций Управление размером файла журнала транзакций Факторы, могущие вызвать задержку усечения журнала Использование резервных копий журналов транзакций Создание резервных копий журналов транзакций Резервные копии заключительного фрагмента журнала Применение резервных копий журнала транзакций Принцип действия резервного копирования в моделях восстановления Simple и Full По типу формирования резервные копии бывают трёх видов: Full Полная Differential Дифференциальная, разностная Log Резервная копия журналов транзакций, учитывая, то, насколько часто этот термин используется, будем сокращать до РКЖТ Здесь надо не запутаться: Полная резервная копия Позволяет восстановить состояние базы данных на некоторый момент времени на тот в который начато формирование резервной копии. Разностная резервная копия Хранит страницы данных, изменившиеся с момента последней полной резервной копии. Без предыдущей полной резервной копии разностная копия бесполезна. Поэтому желательно хранить их где-то рядом друг с другом. Каждая последующая разностная копия будет хранить все страницы, входящие в предыдущую разностную резервную копию, сделанную после предыдущей полной хотя, возможно, уже с другим содержимым. Поэтому каждая следующая разностная копия больше предыдущих, пока снова не сделать полную копию если это и нарушается, то только из-за алгоритмов сжатия Для восстановления на какой-то момент достаточно последней полной резервной копии на этот момент и последней разностной копии на этот момент. Промежуточные копии для восстановления не нужны хотя они могут быть нужны для выбора момента восстановления РКЖТ Содержит копию ЖТ за некоторый период. Частые заблуждения и мифы: Нет, это не так. РКЖТ содержит и на первый взгляд бесполезные данные между предыдущей РКЖТ и последующим полным бэкапом. Полный и разностный бэкап не трогают цепочку РКЖТ. ЖТ нужно перидически чистить вручную, уменьшать, шринкать. Нет, не надо и даже наоборот — нежелательно. Если освобождать ЖТ между РКЖТ, то будет нарушена цепочка РКЖТ, нужная для восстановления. Как это работает в simple Пусть есть база данных в ГБ. Сделаны следующие резервные копии Полная копия F1 от 0: Как это работает в full Пусть у нас есть такой же набор резервных полных и разностных резервных копий, как в предыдущем примере. В дополнение к этому есть следующие РКЖТ: РКЖТ 1 за период с Размер РКЖТ будет примерно постоянным. Резервные копии мы можем делать реже, чем разностные или полные, а можем и чаще, тогда они будут меньше по размеру. Теперь мы можем восстановить состояние системы на любой момент с 0: В самом простом случае нам для восстановления понадобятся: Последняя полная копия до момента восстановления Последняя разностная копия до момента восстановления Все РКЖТ, от момена последней разностной копии до момента восстановления Пример. Для восстановления на Полная копия F2 от 0: Восстановить F2, потом потом D2. Восстановить F2, потом РКЖТ 4, потом РКЖТ 5, потом потом РКЖТ 6 до момента Или вообще восстановить F1 и прогнать все РКЖТ до РКЖТ 6 до момента Как видно, полная модель предоставляет нам больший выбор. Подробнее о средствах высокой доступности можно прочтитать в справке: Высокий уровень доступности компонент Database Engine Общие сведения о решениях с высоким уровнем доступности зеркальное отображение базы данных Доставка журналов Высокий уровень доступности. Взаимодействие и совместная работа Прочие аспекты резервного копирования Этот раздел можно смело пропустить, если вам наскучила теория и руки чешутся опробовать настройки резервного копирования. Файлы данных Если помещением данных в разные файловые группы управляет человек, то когда внутри файловой группы есть несколько файлов, то данные по ним распихивает MS SQL Server самостоятельно при равном объёме файлов — постарается равномерно. Сжатие резервных копий В MS SQL Server появилась супер-мега-ультра возможность. Один файл бэкапа — много внутренностей На самом деле резервная копия это не просто файл, это достаточно сложный контейнер, в котором может храниться много резервных копий. Несколько зеркальных копий В SQL Server есть еще одна замечательная возможность. Примеры систем резервного копирования Довольно теории. Пора практикой доказать, что вся эта кухня работает. Настройка типичного резервирования сервера через Планы обслуживания MaintenancePlan Этот раздел построен в виде готовых рецептов с пояснениями. Пользуемся мастером создания плана обслуживания Запускаем SSMS, подключаемся к нужному серверу. Задаём имя плана "Резервное копирование" и описание, указываем галочку "Separate schedules for each task", переходим дальше Устанавливаем режимы работы другие галочки лучше оставить отдельным планам обслуживания , переходим дальше Начинаем настраивать полное резервное копирование: Настраиваем полное копирование всех пользовательских баз данных. Системные базы данных тоже желательно сохранять, но во-первых не все имеет смысл только master и msdb, если вы специально не изменяете model , во-вторых, возможно, с другой периодичностью, в-третьих для master не нужно сохранять РКЖТ. Обратите внимание на следующие моменты: Хотя возможна ситуация, когда даже проверенная таким образом копия не восстановится, но такая проверка лучше, чем никакая; вариант сжатия установлен "по настройкам сервера", очень желательно включить эту возможность на уровне сервера; папку "C: Настраиваем расписание например, раз в неделю по воскресеньям в полночь, примерно как в рассмотренном ранее примере: Аналогично настраиваем разностные резервные копии, но раз в день, кроме воскресенья. Обратите внимание, что базы данных с моделью восстановления simple будут игнорироваться. Обратите внимание, что галочку "Back up the tail Она не предназначена для обычного резервного копирования журналов транзакций. Настроим разумный горизонт хранения резервных копий в этой папке например, 4 недели, предполагается, что резервные копии из этой папки копируются еще куда-то и хранятся существенно дольше: Протоколы сохраняем в папку по умолчанию. Их вообще-то тоже желательно подчищать, но это можно делать и вручную раз в года. Проверяем, убеждаемся, что всё правильно Вот в общем-то и всё. Резервное копирование, подходящее для большинства баз данных размером от ГБ до ГБ готово. Как проверить, что система работает? Проверяем, что нужные объекты созданы: Для каждого из заданий Резервное копирование. Проверяем, что в целевой папке появились резервные копии. Проверяем, что разностная копия существенно меньше полной. Снова запускаем задание Резервное копирование. Проверяем папку протоколов и читаем у меня это папка C: Читаем протоколы, убеждаемся, что ошибок нет. Настройка резервирования сервера скриптами TSQL, примеры некоторых возможностей Сразу возникает вопрос, а чего еще надо? Планы обслуживания не позволяют: Использовать зеркальное резервирование Использовать настройки сжатия отличные от настроек сервера Не позволяет гибко реагировать на возникающие ситуации никаких возможностей по обработке ошибок Не позволяет гибко использовать настройки безопасности Планы обслуживания очень неудобно развёртывать и поддерживать одинаковыми на большом количестве серверов даже, пожалуй, уже на Ниже приведены типичные команды резервного копирования Полная резервная копия Полная резервная копия с затиранием существующего файла если есть и проверкой контрольных сумм страниц перед записью. Например, одна может лежать локально на сервере чтобы была под рукой , а вторая сразу формируется в физически удалённое и защищённое от неблагоприятных воздействий хранилище: Ссылки Полезнее всего для понимания работы резервного копирования ознакомиться со следующими статьями: Проверяем резервную копию без восстановления Файл лежит на диске. Но может быть это вовсе и не резервная копия? Восстановление полной копии в новую базу данных Это, пожалуй, самая частая операция с файлами резервных копий. Выбираем Restore Database из контекстного меню: Выбираем базу данных, в которую надо восстановить файл, и сам файл На закладке Options настраиваем, где будут лежать файлы восстановленной базы данных. Если базу данных восстанавливаем поверх существующей, то нужно установить флажок WITH REPLACE Жмем OK А вот вариант TSQL: Факультативно рекомендую посмотреть самостоятельно Восстановление с использованием "хвоста" журнала транзакций WITH TAIL Восстановление в состояние standby но важно понимать, что обычно 1С не сможет работать с БД, доступной только для чтения Восстановление сбойных страниц, восстановление файлов факультатив Все эти возможности можно посмотреть в MSDN: Инструкции RESTORE для восстановления из копии, восстановления по журналу и управления резервными копиями Transact-SQL - страниц со статьями по вариантам RESTORE RESTORE Transact-SQL Аргументы инструкции RESTORE Transact-SQL Инструкция RESTORE HEADERONLY Transact-SQL RESTORE VERIFYONLY Transact-SQL Заключение Приведённой информации достаточно для ликбеза по резервным копиям, но недостаточно для практических навыков. Скрипт удобного восстановления базы MSSQL при дифференциальном резервировании. Восстановление SQL базы 1С 8. Резервное копирование-архивирование каталогов с помощью Python 3. К вопросу об архивации баз 1С и снова, и снова Как выгрузить не всю конфигурацию в файл, а только изменения? Программа для резервного копирования данных: Как выгрузить базу средствами 1С, не выгоняя пользователей. Выгружаем базу средствами 1С не выгоняя пользователей. Резервное копирование информационных баз 1С: Предприятие 8 с помощью xStarter. Настройка зеркалирования базы для MS SQL. Автоматический backup и регламентные процедуры в SQL Server Express Edition. Как я восстанавливал разрушенную базу. Архивирование файловой базы 1С 8 каждый день, не выгоняя пользователей из базы, и не нужно знать пароль администратора. Дата Дата Дата Рейтинг Древо Сохранить. Андрей Окипний DMSDeveloper Спасибо автору за развернутое описание принципов резервного копирования! Утащил в свою библиотеку. Алексей Роза DoctorRoza Написано то, "ни салили, букавак многа". Зачетный пост, плюс однозначно! Alexander Speshilov speshuric Анатолий Бритько headMade Посоветуете может книгу по настройке, администрированию MSQL, где так же доходчиво все было было показано? Алексей Патюков apatyukov Алексей Новиков Новиков Давно не видел такой грамотной подачи - с одной стороны, и - не скатывания к адаму и еве - с другой. Ждем следующую обзорную статью, которые позволяют автоматизировать всю рутину, которая описана в статье "в несколько кликов мыши" с. В частности Компонент SQL Server Database Engine Там сейчас русский язык очень приличный и относительно систематичное изложение. Минус - реально почти вся информация. Microsoft SQL Server Основы T-SQL - классика, хоть и не совсем по администрированию. Гладченко , если начинаешь чувствовать "гуристость" Ну и вся серия от Microsoft Press, но там самое интересное не переведено, насколько я помню: Internals , Inside , тут тоже ссылки обратить внимание на книги авторов Кален Дилейни Kalen Delaney , Джо Селко Joe Celko , Кен Хендерсон Ken Henderson , Ицик Бен-Ган Itzik Ben-Gan , Мамаев Е. На инфостарте пока не писал. Эту статью почти год назад написал, всё лень и некогда дописать было. А работы нам еще много останется. Хотя бы от тех, кто 2 раза в день все индексы ребилдит: Раньше хоть архивировать приходилось, а с R2 и сжатием и это стало ненужным. Для баз меньше ГБ даже разностные бэкапы лень настраивать, а баз больше 1,5 ТБ где уже можно подумать о чем-то более сложном чем вышеупомянутая схема с поправкой на то, что заменить часть полных бэкапов на разностные вообще изчезающе мало. Вот "самодельный лог-шиппинг" было бы, пожалуй, интересно описать. Buots Vladimir vbuots 20 Так и надо писать статьи! Пошел делать все правильно: Валентина Иванова VallyD Спасибо за огромный труд. Много интересного и нового почерпнула из статьи, так как только начинаю осваивать азы программирования. При этом форумы пестрят вопросом, что делать с переполняющим диск журналом транзакций. Пусть хоть тут они прочитают введение в суть вопроса без страшного слова "мануал". Добавлю тут пример простенького скрипта архивирования резервных копий с помощью WinRar для владельцев SQLserver-а без возможности сжатия пусть резервные копии хранятся в папке "C: SQL Server уже с поддержки планируют снимать, и сейчас, наверное, ни одной причины не назову оставаться на нём для 1С 8, а Express использовать в продукте как-то странно. Поэтому сейчас лучше всё-таки использовать сжатие. Вы забыли про Standard, там нет сжатия: Роман Узьмов RomanUzmov 42 Полная и написанная понятным языком статья, очень полезная для начинающих сисадмов! Всеволод Соковиков sevushka Отличная статья, но не раскрыт один маленький нюанс. Что надо написать в t-sql, чтобы сделать бекап с помощью mirror , который на локальном жестком диске будет хранить 1 месяц, а на удаленном сетевом - 1 год? С mirror бэкап делается, а не удаляется. Для удаления нужно cleanup task настраивать, если в терминах maintenance планов. Перенастроил у себя backup-ы. WWWolfy WWWolfy Alexandr Turyshev turbo Подскажите, можно ли создать план резервного копирования, как описано выше НО добавить к нему MIRROR TO? Для каждой базы свои подпапки. Но хотелось бы копировать их сразу в две папки. Целостность и живучесть отложенных яиц архивов я контролирую с помощью ежедневного резервного копирования и восстановления рабочей базы в параллельное состояние. Иными словами, ночью главная база base1 бакапится и тут же средствами TSQL реанимируется параллельно рабочей base2. Все развлекухи отчеты, программные дописки главбух "марьиванна" и иже с ней делают на base2, чтобы не сажать по нагрузке манагеров в рабочей base1. Строки соединения с внешними данными и файловые каталоги в копии будут совпадать с боевыми. Так запущенное для тестирования задание выгрузки во внешнюю систему может нарушить работу продуктовой среды. Нередко пользователи да и ИТшники начинаю путать эти 2 базы, если открывают их одновременно. При расположении копии на основном сервере, загрузка сервера вызванная созданием и работой такой базы может оказаться заметной и неприемлемой. А вот держать подготовленную копию в режиме stand by на соседнем сервере, восстановленную с заранее оговоренным запаздыванием - полезная практика. Для переключения на эту БД остаётся только восстановить кусочек журналов транзакций и не нужно ждать восстановления копии. Андрей Асанов victorree Не получилось сделать восстановление из полной копии с журналами транзакций через мастер восстановления. Если делать последовательно восстановление бака, потом журналов по одному то работает, при попытке добавить все файлы выдает ошибку. Неужели через мастер нельзя за раз сделать восстановление? Или я как то не так делаю? Александр Новиков ZergKRSK У меня тоже не получается через мастера сделать. Я наверно не внимательно читал. Как бороться с переполнением ЖТ? Он не переполняется, потому что своевременно сливается и место внутри файлов освобождается. Если при настроенном резервном копировании ЖТ всё равно переполняется, то это может быть из-за: Незавершённых длительных транзакций Поломанной репликации Огромных изменений в БД например, нередко при перестроении индексов. Проверить причину разрастания можно командой: AHDP AHDP 7 Иначе полная модель не нужна. Валерий Волошин VVi3ard 38 В этом случае я думаю shrink не помешал бы? Aleksandr Filonov AleksSF А с какой периодичностью и в какой последовательности необходимо выполнять регламентные операции: А вторую статью я тоже читал и очень благодарен за нее. Нужно ли делать резервное копирование системных БД. Михаил Максимов МихаилМ С файловыми группами лучше не экспериментировать. Alex Steiner OrsoBear Огреб только что странную ошибку, При восстановлении в непустую базу с отметкой перезаписывать данные. Все перенеслось, но у некоторых справочников часть данных потерялась. При этом отчеты с оборотами, остатками сходятся. Пробую второй раз с выгрузкой в Новую пустую базу SQL раньше вроде таких проблем не было. Just Just 2 Возможно как-нибудь сделать резервную копию без одной-двух таблиц, не создавая для 1с-ки файловые группы? Алексей ADirks Нарисовал немножко скриптов для работы с бэкапами, может пригодится кому. Расположение и имена файлов фиксируются в момент полного бэкапа - для этого создаётся табличка в msdb. На сервере, базы которого нужно бэкапить создаются вспомогательные 2 таблички, и 3 SP-шки. BackupDatabase dbName, dir - dbo. BackupTransactionLog dbName - dbo. BackupDatabaseDiff dbName, dir SP-шки для просмотра содержимого файлов, и восстановления: DestDatabase - имя базы, куда хотим развернуть бэкап SrcServer - имя сервера, на котором делается бэкап то есть где живёт табличка BackupLog SrcDb - имя базы, бэкап которой надо развернуть. Если не указано, то д. Если указан, то будет восстановлен соотв. DestDatabase SrcServer idBackup nStartFile, nEndFile - диапазон номеров логов внутри файла fFinal - если 1, то восстановление последнего лога будет с параметром RECOVERY. По умолчанию NORECOVERY - dbo. ShowBackupHeader SrcServer, idBackup Показывает содержимое файлов бэкапа с указанным ID. Алексей Малык alexfps79 Я прочитал вашу статью про бэкапы SQL, у меня вопрос я делаю. Ну или случайно в тот же файл еще что-то запихнули. Уточнить можно командами RESTORE HEADERONLY и RESTORE FILELISTONLY. Максим Кравченко inomaratadeath Спасибо большое за статью! Настраивал бэкап по инструкции - возникли вопросы. Николай Князев HDRX 23 Такой вопрос по теме: Загрузка идет с флагом WITH REPLACE. При выборе бэкапа пути автоматом проставляются базы источника, и вот никак не могу разобраться, нужно ли менять имена на имена файлов базы-приемника? По идее если мы загружаем с WITH REPLACE, должны перезатираться файлы приемника, по факту - то пишет, что файлы используются, то загружает без вопросов, перезатирая файлы приемника пути при этом не меняются, то есть остаются от приемника. Попробуй выполнить этот запрос в студии, возможно сразу увидишь, что не так например, может банально прав не хватать. Лог усекается при полном бэкапе базы а не лога. Если он всё время растёт, то возможно проблема в чём-то другом. У нас в основном экспериментальные базы на отдельном сервере, но иной раз бывает необходимость. Опять же, можно в студии запустить скрипт полного бэкапа, и сразу же дифф - может что-то прояснится. Кстати, эти самые дифференциальные бэкапы актуальны только при совсем уж больших объемах баз. У нас к примеру база 40Г, и я делаю полный бэкап по пятницам, и каждые 15 мин. Лога за неделю всего гиг набегает, восстанавливается за 15мин, а с диффами только гемор один. Если указываю вручную - вроде опознаёт его корректно. Когда экспериментировал с диффами - работало. Про восстановление по логам: Сначала восстанавливается полный бэкап в режиме NORECOVERY, потом восстанавливаются все куски ркжт начиная с первого, до нужного. Самый последний кусок ркжт восстанавливается с флагом RECOVERY, и получаем рабочую базу. Как это делается можно посмотреть в скриптах, которые я в 44 приводил. Удобная фигня, как раз когда баз много. Не надо каждый раз всё прописывать в планах обслуживания. Я так понял там идёт работа с файловыми группами? Синтаксис в скриптах очень отличается от синтаксисе в статье. Если делать ежедневный полный бэкап, а потом каждый час ркжт, то - грубо говоря, при сбое я могу ограничиться восстановлением последнего полного бэкапа в режиме норекавери, а потом поочерёдно накатывать ркжт с флагом норекавери от момента полного бэкапа и до последней ркжт с флагом рекавери? Максимум что я потеряю - данные за 1 час работы? Или я что-то упустил? Статью несколько раз перечитывал, и с каждым разом всё больше и больше вопросов, чем ответов. Но проще делать бэкап лога почаще. Что касается размера файла лога - то он никогда не уменьшается. В момент полного бэкапа базы место внутри файла "освобождается", таким образом, чтобы файл лога не рос сильно, надо чаще делать полный бэкап. У нас, при описанных выше условиях, файл лога 25Г. Ну и ладно, никого не парит. И шринкать его совершенно ни к чему. Поудалял все планы обслуживания и архивации, в логе ERRORLOG всё равно регулярно появляются записи This is an informational message only. No user action is required. A G grachev1c Стоит задача иметь возможность восстановить или откатить базу с потерей данных максимум за один час. Что будет эффективнее по параметрам: Это ж даже полный размер на 2 минуты неспешного копирования на современном железе. Я бы сделал раз в день полный и раз в минут ЖТ. Если дисковая система нормально спроектирована данные, ЖТ и темпдб на разных дисках , то нагрузки не будет. При этом можно где-нибудь сразу разворачивать болванку в norecovery и время восстановления почти равно времени обнаружения - как бы тёплый резерв, как бы аналог доставки журналов лог шиппинг. С учетом сжатия раз обычно, но таблица конфигурации хуже одного раздела в 1 ТБ хватит "навсегда" годовая история бэкапов. Денис Вурдалак 19 Я конечно дико извиняюсь, что поднимаю старую тему, но все таки. Не совсем понятно, как сделать зеркальную резервную копию? В 24 уже спрашивали, но на этот вопрос тихо ответили в 32 и не совсем понятно как это сделать. Можно ли какой нибудь пример? Алекс Ю AlexO Смысл SQL-ю базу MDF копировать, SQL еще и не даст это сделать. Через xcopy делается копия любого файла: Способ обхода - копировать после создания это можно настроить. Пример есть и в статье и в справке 61 Речь о предложении "MIRROR TO" из синтаксиса BACKUP DATABASE. Введите ваш пароль Забыли свой пароль? Код подтверждения из письма: Введите код подтверждения из письма. Оставьте заявку и в течение 24 часов с Вами свяжется менеджер и вышлет подбор обработок или программных продуктов 1С по вашим требованиям. Отраслевые решения Бухгалтерия Производство Услуги и сервис Торговля Прочее Отчеты Анализ учета Бухгалтерские Налоговые Специальные Статистические Управленческие Финансовые Разное Обработки Закрытие периода Менеджеры внешних отчетов 53 Обработка документов Обработка справочников Рабочее место Свертка базы Универсальные обработки Ценообразование, прайсы Управление Бизнес-процессы Интеграция 43 Личная эффективность 17 Пользователю системы Практика учета Теория учета Техническое задание 44 Управление проектом Обмен Email рассылки SMS рассылки 96 Загрузка и выгрузка в Excel Интеграция с WEB Обмен с другими системами Обмен с интернет-банком Обмен через DBF Обмен через XML Перенос данных из 1C8 в 1C8 Перенос данных из 1С7. Администрирование Архивирование backup Журнал регистрации Защита, права, пароли Оптимизация БД HighLoad Поиск данных Распределенная БД УРИБ, УРБД Сервисные утилиты Системное Стартеры 1С 75 Статистика базы данных Тестирование и исправление Чистка базы Программирование Инструментарий Внешние компоненты Защита и шифрование 68 Мобильные приложения Ошибки в отраслевых решениях 28 Практика программирования Работа с интерфейсом Сертификация Теория программирования Универсальные функции Печать Классификаторы 55 Пакетная печать Печатные формы документов Регламентированная отчетность Справки Статистики 80 Универсальные печатные формы Ценники Оборудование POS терминал 36 Весы 56 ККМ Ридер магнитных карт 11 Сканер штрих-кода Телефония, SIP 41 Терминал сбора данных 86 Фискальный регистратор 82 Сообщество Архив Игры Инфостарт Люди 22 О жизни Поздравления Резервное копирование 1С средствами MS SQL. Alexander Speshilov speshuric Рейтинг: Библиотека Новости Статьи Книги. Сообщество Форум ТОП Спецпроекты. Биржа труда Вакансии Резюме Компании. Обучение Видео Вебинары Курсы. Программы Конфигурации Разработки Софт. Биржа заказов Специалисты Заказы Компании. Тарифы на абонемент О сайте Контакты Партнерство Пресса о нас Помощь Реклама на сайте. Бесплатный доступ Пользовательское соглашение Правила публикации Правила форума Правила работы магазина Конфиденциальность. Написать в техподдержку Контакты и реквизиты Россия:
https://gist.github.com/cb818f92f4f9ab0ac46e9010dd3cd0f4
https://gist.github.com/2cd8f0bde622d62e64070eb6d415502d
https://gist.github.com/89047670315bc906bd5253fa48e7b4f7