Форум казахстанского налогоплательщика

Наверное Вы о случае, когда делаете резервную копию базы, в которой в это время кто-то работает. Да, это может приводить к тому, что пока Вы делаете резервную копию, часть базу уже изменилась. Для этого сейчас в базах данных существуют специальные инструменты. в MSSQL. Если не изменяет память это называется теневое копирование, но в MSSQL это появилось недавно. В версии SQL Server 2000 кажется этой возможности не было (могу ошибаться)

Теневое копирование тома - это в Вин2008Сервер. Не пробовал.

А в СКЛ бэкап средствами самого СКЛ всегда можно было делать бэкап в теневом режиме, при работающих и "сидящих в базе" пользователях. Даже в СКЛ2000. Пробовал, работает.
В литературе интересно описывается, как именно и на какой момент времени получается этот бэкап при работающих в базе пользователях. Если бэкап начался, допустим, в 16-30 и продолжался до 16-45, то на какую минуту будут в бэкапе данные, если мы с него потом восстановим базу? Ответ - на конец бэкапа, на 16-45. Это достигается копированием в бэкап всех данных начала бэкапа и потом "дозаписыванием" тех данных, которые изменились в процессе бэкапа. Благодаря этому можно не выгонять узеров из базы. Это СКЛ называется, это - сила. У 1С такого до сих пор не получилось сделать, ни в 1С60, ни в 1С77, ни в 1С8. Я уверен, что у них не хватит слюней сделать такой бэкап даже в 1С9...10....15...48. А позиционируются типа как "мерседес", платформа корпоративного уровня. Смешно. В продуктах корп. уровня зачастую просто невозможно выгнать узеров из базы, их бывает так много и они подсоединяются к базе из таких далеких мест.

А мой "регламент при сбоях" по любому надо делать монопольно, single user, и всех выгнать из базы. Причем пункты 0-3 и 6 по иному и не получится. Пункты 4-5 технически можно делать при сидящих в базе пользователях, но тогда процесс будет идти гораздо медленнее.

Технологии теневого копирования Microsoft стала внедрять в продукты несколько лет назад и вот о чем они. Да, Вы правы, часто файлы или базы очень большие. Представьте, что у Вас есть большая папка, в которой много других папок, внутри них много документов. Но все документы связаны, Ваши пользователи их редактируют, переносят из одной папки в другую.

Представьте, что Вы начали копировать: через 5 минут Вы скопировали папку А, через 10 минут перешли в папку Б. Раньше в папке Б был документ, но его перенесли в папку А пару минут назад. Что в итоге? В итоге этого документа в резервной копии не осталось вообще. Когда мы копировали папку А, документ был в папке Б. Когда дошли до папки Б, он оказался в папке А. В итоге Ваша резервная копия неполноценна. В ней нет важного документа. Хотя его даже никто не удалял. Это я на примере документов объясняю.

В базах данных проблемы похожие: положим в таблице "Контрагенты" у Вас внесена компания, а данные о ее покупках в отдельной таблице "Реализация". Теперь мы начали долгий путь копирования, через 5 минут сделали копию таблицы "Контрагенты", через 10 минут таблицы "Реализация". Вроде всё нормально. А нет. На 8 минуте менеджеры добавили еще одну компанию и продали им товар. Молодцы конечно, мы любим менеджеров.

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

Вот чтобы этого не было сделали теневое копирование. Есть техники теневого копирования. Когда начинается процесс копирования, делается "снимок" и копия делается с этого снимка. Т.е. если копирование будет идти даже час и целый час будет база изменяться, но мы всё равно скопируем ровно то, что было на начало копирования. И это замечательно.

Есть и другой подход, когда по завершению копирования в него будут добавлены изменения, но это редкий подход. Это всё я описываю в теории. На деле в разных операционных системах это по-разному. Тот же MSSQL на деле не сам это реализует. Он использует возможности операционной системы.

И кстати, Вы можете и для 1С сделать такое. Можно написать сценарий резервного копирования с использованием теневого копирования. На деле это не так сложно. Просто наши 1С-ники полагаются больше на стандартные поставки и известные практики. Но даже если у Вас Windows Server 2003, то Вы вполне можете настроить регулярное теневое копирование баз 1С и при этом 1С необязательно выключать.

Теневое копирование это еще одна из многих классных, потрясающих вещей, которые надо знать, надо понимать, надо пользоваться. Она бесплатно идет уже кучу лет не только в Windows Server, но даже в Windows XP. Но проблема в том, что даже те, кто постоянно должны это знать и владеть не пользуются этим.

Под 1С-никами я подразумеваю не разработчиков 1С, которые сидят в Москве и других городах России, а тех кто практически ставит, обслуживают 1С. Т.е. тех кто приходит в наши с Вами компании и ставят 1С.

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

Выделил в отдельную тему из темы Как проверить не повреждена ли база в 1С версии 8

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

Не думаю, что использовать теневое копирование для баз 1С, файловых и СКЛ - хорошая идея. По моему опыту, лучше пользоваться штатными методами - выгрузкой 1С, или бэкапом СКЛ.
У теневого копирования томов средствами ОС совсем другая область назначения. Допустим, Вы хостер и у вас на сервере крутятся десятки виртуальных машин, сотни сайтов, и т.д. Да, конечно, в этом случае теневое копирование томов сервера - это неплохое решение. Экономите кучу времени.

Для SQL теневое копирование специально заточено и успешно используется. Именно в SQL в отличие от файловых баз есть свои нюансы, но их реализует сама MSSQL. А в случае с файловой БД просто достаточно встроенных средств в Windows, чтобы снять снимок базы данных.