Как восстановить Windows из созданной ранее резервной копии! Восстановление Windows из резервной копии на другом компьютере с помощью AOMEI Universal Restore Резервное копирование для восстановления windows.

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

сли объема памяти на выбранном для хранения носителе недостаточно для переноса файлов, то используется архивирование со сжатием. К тому же сжатие данных сокращает расходы на хранение и передачу данных по сети или в Интернете. Сжатие данных выполняется с помощью специальных программ-архиваторов, таких как Zip, Rar, Arj и пр. В зависимости от выбора степени сжатия исходные файлы (особенно текстовые) могут уменьшаться в объеме примерно в четыре-пять раз. При этом следует учесть, что упаковка данных происходит значительно медленнее, чем их восстановление, и что при современной производительности компьютеров можно сжимать не только редко используемые данные и программы, но и активно эксплуатируемые.

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

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

Базовые средства операционных систем

птимальная организация резервирования предполагает автоматическое копирование: файлы помещаются на предназначенные для них носители таким образом, что в процессе работы пользователь этого даже не замечает. Взрывообразный рост емкости используемых винчестеров привел к тому, что организация программно-аппаратного комплекса для сохранения таких объемов информации значительно усложнилась. Традиционные накопители на магнитной ленте, а также Jaz- и Zip-диски уже не выдерживают конкуренции с жесткими дисками и мало подходят для резервирования. Болванки CD-R/RW и появившиеся относительно недавно записываемые DVD-диски обладают несколько большей емкостью, но тоже не справляются с современными объемами в десятки и сотни гигабайт. Можно, конечно, решить эту проблему, создав несколько отдельных систем резервирования, каждая из которых будет работать по своему графику и с собственным носителем.

Например, с помощью утилиты Мicrosoft Backup можно сделать один резервный файл для копирования каталога Windows и корневых каталогов, другой - каталога Program Files, третий - файлов данных и т.д., но в этом случае пользователю придется выполнять вручную множество операций. Средства автоматизированного резервирования появились еще в Windows 95, где был установлен пакет Microsoft Plus, а для запуска Microsoft Backup использовалась утилита System Agent, добраться до которой можно было из меню «Пуск», пунктов «Программы»/«Стандартные»/«Служебные программы»/«Архивация данных». Чтобы указать, какие файлы нужно копировать, достаточно было выбрать в правой и левой панелях открывшегося окна соответствующие опции, потом выбрать нужный дисковый либо ленточный накопитель, а также каталог для хранения резервных копий и указать, что программу резервирования следует закрыть после завершения ее работы. Для автоматизации работы этой программы следовало отключить вывод на экран запроса на подтверждение перед началом операции. Таким образом, задав однажды во вкладке Backup меню «Параметры» все необходимые настройки и указав в пункте «Файл»/«Сохранить как» имя и местонахождение будущей резервной копии (другой диск или каталог), вы могли организовать автоматический процесс резервирования. Поскольку SET-файлы по умолчанию были ассоциированы с утилитой Microsoft Backup, простое добавление файла в список приводило к запуску Backup. Там же задавался график резервирования (When to Run - когда запускать System Agent). Если же требовалось запланировать несколько сеансов резервирования для различных наборов файлов и разных накопителей, то данную процедуру следовало повторить, задавая различные имена SET-файлам и иной график выполнения.

Версия Microsoft Backup, поставлявшаяся вместе с операционной системой Windows 98, уже не позволяла установить автоматическое архивирование. Конечно, можно было запускать Microsoft Backup с помощью планировщика заданий, но для того, чтобы он сделал резервную копию, ему требовались некоторые вводные данные.

Операционные системы семейства Windows NT поставлялись с утилитой NTBACKUP.EXE, которую можно было использовать в большинстве случаев для резервного копирования данных и которая поддерживала следующие пять видов создания резервных копий:

Нормальная резервная копия, которая сохраняла выбранные файлы и помечала их как резервные;

Пошаговая резервная копия, сохранявшая только те файлы, которые изменились со времени создания последней резервной копии, а после копирования они помечались как резервные;

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

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

Ежедневное резервное копирование, то есть сохранение файлов, которые изменились за этот день, но файлы при этом не помечались как резервированные.

Как видите, это был уже вполне профессиональный подход, который сохранился и в операционных системах Windows 2000/XP, но тем не менее возможности стандартной Вackup-утилиты очень ограниченны. Для более гибкого резервирования применяются и другие программы.

Утилиты резервного копирования дисков

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

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

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

Пользователи Windows наверняка замечали, что чем больше они устанавливают новых программ (прежде всего это касается компьютерных игр), тем медленнее и неустойчивее работает вся система. Иногда к разрушению системы приводит инсталляция новых устройств или просто какие-то несанкционированные компанией Microsoft эксперименты, и уж совсем плачевно выглядит рабочая среда после вирусной атаки. Часто даже резервная копия не помогает восстановлению (не успели зарезервировать или вообще потеряли рабочую копию), и тогда приходится устанавливать операционную систему заново. В этом случае вам поможет только полное сохранение рабочей копии системного диска (например, на CD-R/RW) с возможностью ее восстановления в первозданном виде. Такую копию следует сделать после первой установки системы, всех необходимых программ и драйверов и проверки ее работоспособности.

Самыми популярными решениями для репликации содержимого жестких дисков до последнего времени были утилиты Norton Ghost и PowerQuest Drive Image. Однако появившиеся недавно отечественные разработки в области резервного копирования не только не уступают, но во многом и превосходят вышеперечисленные программы - речь идет прежде всего о продуктах компании Acronis (http://www.acronis.com , http://www.acronis.ru). К тому же разработчики большинства продуктов Acronis находятся в Москве (в отличие от своих конкурентов PowerQuest и Symantec), поэтому все программы обладают русскоязычным интерфейсом. Кроме того, продукты компании Acronis в России проще купить, чем украсть: при цене 50-70 долл. на мировом рынке, все они продаются у нас за 299-399 руб. По-моему, совсем недорого за чистую совесть и поддержку отечественного производителя, а кроме того, за русскоязычную поддержку самого продукта от производителя.

Собственно говоря, основная задача подобных утилит - копирование содержимого жесткого диска, включая системные области, на другой накопитель или в резервный файл. Но сегодня такие программы взяли на себя роль и систем архивации, которые работают с файлами, и Вackup-утилит. При этом они подчас более удобны в использовании, универсальны и даже имеют некоторые преимущества перед традиционными подходами. Описываемые ниже программы идеально подходят и для восстановления рабочей среды в случае сбоя без необходимости переустановки операционной системы и прикладных программ, и для сохранения важных данных пользователя, и для копирования нужной конфигурации на другой компьютер. Кроме того, при копировании диски могут иметь разную емкость, а эти утилиты позволяют изменять размеры логических дисков при подготовке нового компьютера к работе.

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

True Image

Для Windows 95/98/Me/NT (включая Server)/2000 (включая Server)/XP

Acronis True Image 6.0 — лучший на сегодняшний день продукт для полного резервного копирования, позволяющий создавать точные образы жесткого диска и/или отдельных разделов прямо в Windows без перезагрузки. Образ диска, включающий абсолютно все данные, приложения и операционные системы, может быть восстановлен на жесткий диск в случаях внезапной «кончины» жесткого диска, вирусных атак и любых других фатальных ошибок программного и аппаратного обеспечения, причем даже в тех ситуациях, когда обычные средства резервного копирования файлов уже не помогают.

Основные возможности:

Быстрое создание точного образа диска с гарантией полной сохранности данных (поддерживаются жесткие диски любых размеров);

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

Удобное копирование точного образа жесткого диска на CD-R/RW, ZIP, JAZ или на какое-либо другое устройство хранения данных со сменным носителем в дружественной среде с пошаговыми инструкциями и с интерфейсом в стиле Windows XP;

Полное клонирование жесткого диска на новый компьютер.

Эксклюзивные возможности:

Возможность создания и восстановления полного образа диска непосредственно в Windows без необходимости перезагрузки в DOS или в другую систему;

Наличие дружественного пользовательского интерфейса с пошаговыми инструкциями в стиле Windows XP, делающего работу доступной для пользователя любой квалификации;

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

Прочие особенности:

Сохранение только необходимого содержимого секторов диска в образе, вследствие чего полный образ диска создается за считанные минуты;

Возможность создания резервных копий и восстановление образов жестких дисков по локальной сети;

Задание пользователем уровня сжатия; разбивание архива на несколько томов; установление пароля;

Задание комментария к создаваемому образу раздела;

Создание загрузочной дискеты, компакт-дисков CD-R/RW или DVD-R/RW, с помощью которых можно восстановить работоспособность компьютера даже в случае, если все операционные системы на нем уничтожены;

Возможность менять в процессе восстановления типы раздела, файловой системы, размеры и расположение диска (поддерживаются файловые системы Windows FAT16/32 и NTFS, а также Linux Ext2, Ext3, ReiserFS и SWAP, а для разделов других типов обеспечивается специальная посекторная поддержка);

Полная поддержка жестких дисков и пишущих приводов с интерфейсами IDE, SCSI, PCMCIA, USB 2.0 и FireWire.

После установки Acronis True Image 6.0 предложит создать загрузочную дискету или компакт-диск для работы на компьютере с любой другой операционной системой.

Следует подчеркнуть, что при запуске Acronis True Image не требуется выполнять перезагрузку компьютера, более того - вы можете продолжать работу с приложениями в обычном режиме, однако при этом не следует запускать ресурсоемких приложений. Хотя компания Acronis утверждает, что с помощью ее уникальных технологий при создании образа обеспечивается целостность данных, структур жесткого диска и файловых систем, но лучше все же минимально использовать компьютер при этом процессе. Кроме того, Acronis True Image не гарантирует целостности данных на уровне таких сложных приложений, как Microsoft SQL Server, Oracle и Microsoft Exchange.

Drive Image

Для Windows DOS/95/98/Me/NT/2000/XP

Утилита Drive Image Pro предназначена для резервного копирования информации с жесткого диска в файл или на другие носители информации (Jaz, Zip, CD-R/RW и пр.) и вполне обоснованно считается не только одним из лучших решений для клонирования жестких дисков, но и весьма удобным инструментом для резервного копирования.

Drive Image позволяет создать сжатый образ винчестера, защитить информацию паролем и зашифровать ее в случае необходимости. При восстановлении можно скопировать весь диск или отдельные файлы, а также разбить диск на логические разделы (этим занимается утилита PartitionMagic Pro). Drive Image поддерживает все известные файловые системы: FAT, FAT32, NTFS и HPFS.

Хотя Drive Image инсталлируется практически во всех версиях Windows, на самом деле это DOS-приложение - программа запускается из MS-DOS и имеет малый размер (может быть записана на дискету). При этом не имеет значения, как вы загрузитесь в DOS, поскольку Drive Image можно запустить из инсталляционного каталога или с CD-ROM при помощи утилиты QuickImage, которая создает виртуальную дискету в памяти вашего компьютера. Drive Image загружается с этой виртуальной дискеты и выполняет выбранные вами задачи по резервному копированию и восстановлению файлов.

Самое главное преимущество этой программы состоит в том, что она может самостоятельно записать образ диска на CD-R/RW и сделать его загрузочным. Поддерживаются и другие съемные накопители, а в состав Drive Image входят все необходимые драйверы. Реализована функция для создания набора из двух гибких загрузочных дисков, которые обеспечат запуск программы в том случае, если нет CD-R или память не позволяет сформировать виртуальную дискету. Интерфейс программы выполнен в виде мастера, интуитивно понятен и даже не требует обращения к руководству пользователя.

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

Отметим, что полное восстановление диска программой Drive Image занимает значительно меньше времени, чем инсталляция системы Windows (не говоря уже о необходимых драйверах и приложениях и о последующей настройке). Кроме того, восстановление диска из образа благодаря технологии SmartSector (программа работает на уровне секторов, в обход файловой системы) происходит даже быстрее, чем необходимо для обычного копирования информации, а размер файла образа более чем вдвое меньше объема сохраненных в нем данных.

Восстановление информации никаких затруднений не вызывает (особенно если вы выбрали опцию копирования «диск в диск»), однако если вы захотите восстановить рабочую среду на компьютере с другой аппаратной конфигурацией, то вам потребуется профессиональная версия Drive Image Pro, куда входят такие вспомогательные утилиты, как PowerCast (программа для одновременного тиражирования информации на произвольное число компьютеров в локальной сети) и полная версия PartitionMagic Pro. А для работы с файлами образов нужна утилита Drive Image File Editor, при помощи которой можно копировать разделы из одного образа в другой, сжимать образ диска, удалять из него информацию, разбивать на несколько файлов (что необходимо, например, для копирования большого диска на различные сменные накопители) или, наоборот, объединять несколько файлов в один, а также выборочно восстанавливать разделы и считывать необходимую информацию из файла образа диска. Для извлечения отдельных файлов предназначена утилита Image Explorer, поставляемая вместе с Drive Image.

Кроме того, в состав Drive Image входит отдельная программа DataKeeper, которая может использоваться для организации автоматического резервного копирования измененной информации в уже созданный образ диска, то есть при каждом изменении содержимого файлов (на целом диске или в избранных каталогах) они будут сохраняться в файл образа автоматически. При этом различные версии файлов могут накапливаться практически без ограничений. По умолчанию копируются все файлы, кроме программных модулей, однако можно явно указать необходимые расширения или шаблоны. Можно также составить расписание для автоматического выполнения задач резервного копирования и восстановления, например для того, чтобы каждую ночь общедоступная машина приводилась в рабочее состояние либо чтобы какой-то раздел диска копировался на CD-R/RW (или на другой съемный носитель) или в сжатый файл, находящийся в другом разделе того же жесткого диска.

К тому же программа весьма эффективно работает в фоновом режиме и практически не оказывает влияния на производительность компьютера.

Последняя версия PowerQuest Drive Image 7.0 отличается от предыдущих рядом новых возможностей. В частности, она позволяет сохранять образы целых дисков или отдельных разделов на носители DVD-R/RW и DVD+R/RW, а также поддерживает разнообразные внешние накопители с интерфейсами USB (в том числе версии 2.0) и FireWire. Некоторые улучшения произошли и в области сетевой поддержки, вследствие чего пользователи могут сохранять образы и восстанавливать содержимое с дисков по сети. Кроме того, благодаря технологии Virtual Volume Imaging (V2i) имеется возможность оформления резервных образов в виде виртуальных жестких дисков.

Norton Ghost

Для Windows XP/2000/NT WS/Me/98

Программа Norton Ghost 2003 корпорации Symantec (первоначально она была разработана компанией Binary Research) может защитить информацию от различных проблем, связанных с аварийными сбоями в работе компьютера. Norton Ghost хотя и не самая удобная программа для создания копии диска, но наиболее полная по своим возможностям. Она позволяет копировать и восстанавливать как отдельные разделы, так и весь диск полностью, причем образ диска можно считывать и записывать по сети, через параллельный или USB-порт, а также сохранять на CD-R/RW или на других сменных носителях.

Данная программа реализует все основные функции, которых только можно ждать от такого рода решения: копирование данных с жесткого диска на другой жесткий диск или в файл (образ диска), копирование дисковых разделов на жесткий диск, на сменные носители и в файлы, защищенные с помощью пароля и сжатые. В пакете имеется очень хороший редактор образа диск Ghost Explorer, который позволяет просматривать образ диска и восстанавливать отдельные файлы. Программа также обеспечивает функции проверки поверхности диска на наличие ошибок и сбойных секторов и имеет возможность копирования «сектор в сектор», если пользователь желает получить точную копию диска. Достаточно простой и интуитивно понятный интерфейс позволяет с легкостью делать резервные копии жесткого диска и упрощает впоследствии процедуру его восстановления. В окне Ghost Explorer можно перемещать мышью файлы и папки в файл образа или из него. Запускаемая из командной строки утилита форматирования диска Gdisk содержит уникальный набор функций, рассчитанных на опытных пользователей, знающих, как с ними обращаться.

Программа также может регулярно создавать резервные копии, просто и надежно восстанавливать файлы и упрощать любую модернизацию системы. Ghost может записывать копии на жесткие или съемные диски, включая приводы CD-R/RW и DVD+RW, а также на сменные устройства типа Iomega Zip и Jaz. Запись может также осуществляться непосредственно на поддерживаемые устройства USB или FireWire (IEEE-1394), а быстрое соединение между несколькими компьютерами через локальную сеть, USB или высокоскоростные параллельные порты обеспечивает возможность создания разнообразных клонов.

Однако следует отметить, что, в отличие, например, от Drive Image, перед выполнением любых операций по созданию образа или восстановлению диска программу Norton Ghost нужно загрузить с гибкого диска или с загрузочного компакт-диска, а также ввести серийный номер программы перед восстановлением образа. При этом один загрузочный диск вы должны создать для записи копий образов на CD-RW, а другой - для считывания их с диска CD-RW. Нельзя использовать один и тот же гибкий диск для чтения и записи, хотя в ходе подготовки второго диска можно копировать его содержимое на диск CD-RW.

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

Программа имеет подробное учебное пособие и обладает надлежащей поддержкой на сайте компании Symantec в Интернете.

Розничная цена программы — около 70 долл.

Paragon Drive Backup

Для Windows: 9х/Me/NT/2000/XP

Drive Backup — утилита для резервного копирования данных, в том числе для создания копий разделов с целью их быстрого восстановления в случаях аварии, вирусной атаки или при необходимости перенести все данные, включая операционную систему и установленное программное обеспечение, на новый жесткий диск. Переустановка операционной системы и приложений после выхода из строя аппаратуры или вирусной атаки не отнимет у вас много времени и сил. Наилучший путь защитить систему –– сделать резервную копию системного раздела с установленной на нем операционной системой и всеми необходимыми приложениями. Копии могут создаваться на жестком диске и сменных носителях (ZIP, JAZ, Sequest, CD-R/RW), а также на дисках, подключенных по сети.

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

Правда, утилита Paragon Drive Backup не смогла достичь столь серьезного коммерческого успеха, как это удалось Acronis True Image. И причина здесь, по-видимому, в интерфейсе пользователя и удобстве работы с пакетом: очевидно, что компания Acronis создала более дружественную по отношению к пользователю программу.

Universal Backup

Для Windows 95/98/Mе/NT/2000/XP

Если у вас не окажется 300 руб. на покупку Acronis True Image, то для резервного копирования можно воспользоваться бесплатно распространяемой программой с русскоязычным интерфейсом, которая так и называется - Universal Backup (универсальный «резерватор»). Эта многофункциональная программа предназначена в первую очередь для создания архивов, содержащих любые файлы и каталоги, с возможностью их последующего восстановления как из-под «глухого» DOS, так и непосредственно из Windows. Утилита позволяет сканировать любые файлы, каталоги, ключи и переменные реестра, а также DOS-файлы и файлы настройки Windows. Информация о сканировании сохраняется в отчетные файлы, которые впоследствии можно сравнивать и на основе различий создавать архивы. Хотя программа очень маленькая (189 Кбайт) и не требует инсталляции, она вполне годится для резервирования как какой-либо отдельной программы, так и операционной системы в целом.

Основные возможности:

Создание архивов, содержащих любые файлы, каталоги, ключи и переменные системного реестра;

Восстановление файлов, каталогов, ключей и переменных реестра в их исходные места расположения (как из DOS, так и непосредственно из Windows);

Сканирование любых каталогов, ключей реестра, файлов настройки Windows (control.ini, system.ini, win.ini) и системных файлов MS-DOS (boot.ini, winstart.bat, dosstart.bat, autoexec.bat, config.sys, msdos.sys);

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

Создание архивов на основе выявленных изменений (в архив включаются созданные и измененные файлы, каталоги, ключи и переменные реестра);

Переустановка (восстановление) операционной системы;

Доустановление необходимых компонентов системы.

Данная программа облегчит жизнь огромному количеству пользователей, а умещается всего на одной дискете. Вы только представьте себе: полная переустановка Windows из-под DOS займет у вас считанные минуты! Обычно большую часть времени занимает не столько установка самой операционной системы, сколько ее дальнейшая настройка и оптимизация, а с помощью Universal Backup вы эту проблему решите. Все, что вам необходимо, - это инсталлировать операционную систему, настроить ее по своему усмотрению, установить необходимые программы, а затем создать посредством Universal Backup резервный архивный файл.

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

Любая современная СУБД должна предоставлять средства резервного копирования, позволяющие восстанавливать базу данных в случае ее разрушения. Кроме того, рекомендуется создавать резервные копии базы данных и ее файла журнала с некоторой установленной периодичностью, а также организовывать хранение созданных копий в местах, обеспеченных необходимой защитой. В случае аварийного отказа, в результате которого база данных становится непригодной для дальнейшей эксплуатации, резервная копия и зафиксированная в файле журнала оперативная информация используются для восстановления базы данных до последнего согласованного состояния.

Ведение журнала - процедура создания и обслуживания файла журнала, содержащего сведения обо всех изменениях, внесенных в базу данных с момента создания последней резервной копий, и предназначенного для обеспечения эффективного восстановления системы в случае ее отказа.

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

Восстановление базы данных

Восстановление базы данных - процесс возвращения базы данных в приемлемое состояние, утраченное в результате сбоя или отказа.

Необходимость восстановления

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

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

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

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

Стихийные бедствия - пожары, наводнения, землетрясения или отказы в сети электропитания.

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

Диверсии, или преднамеренное разрушение и уничтожение данных, оборудования или программного обеспечения.

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

Увеличить рисунок

На этой странице:

Восстановление файлов из архива

В Windows 7 вы можете восстанавливать файлы из архива с помощью элемента панели управления .

В главном окне элемента панели управления имеется три варианта восстановления файлов:

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

Ниже рассматривается восстановление «моих» файлов. Первое окно мастера восстановления файлов насыщено опциями, поэтому пойдем по порядку.

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

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

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

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

Добавление файлов и папок. Наряду с поиском имеется возможность добавления индивидуальных файлов и папок — для каждого действия собственная кнопка.

Список восстанавливаемых файлов. Отображаются имена добавленных папок и отдельных файлов.

Удаление файлов и папок из списка. Файлы и папки удаляются только из списка восстанавливаемых, но не из архива.

Переход к выбору места назначения для восстанавливаемых файлов. Вы можете восстановить файлы:

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

Определившись с конечным расположением восстанавливаемых файлов, нажмите кнопку Восстановить .

Восстановление предыдущих версий файлов и папок

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

Восстановление из свойств файла или папки помощью вкладки «Предыдущие версии» доступно только в изданиях Windows 7 не ниже «Профессиональная». В домашних изданиях Windows 7 и во всех изданиях более новых ОС Windows есть обходной путь .

Восстановление предыдущих версий файлов и папок из теневых копий

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

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

Из теневых копий вы можете восстановить предыдущие версии:

• отдельных файлов
• папок с файлами

Восстановление отдельного файла из теневой копии почти не отличается от восстановления файла из архива. В свойствах файла на вкладке Предыдущие версии Точка восстановления .

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

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

Вы можете открыть папку, копировать ее в другое место или восстановить на старом месте. При восстановлении система предупредит вас, если в папке окажется файл с таким же именем.

Восстановление предыдущих версий файлов из архивов (только в Windows 7)

Если файл включен в архив средствами резервного копирования Windows, в его свойствах на вкладке Предыдущие версии вы увидите список версий, а в качестве расположения будет указано Архивация .

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

Безусловно, этот же файл можно восстановить из панели управления, но делать это из свойств файла может оказаться удобнее и быстрее.

Восстановление удаленных файлов из теневых копий

Если вам требуется восстановить предыдущую копию существующего файла, достаточно перейти в свойствах файла на вкладку Предыдущие версии . А что делать в том случае, если файл удален? У вас есть два пути:

• восстановление папки
• поиск файла (только в Windows 7)

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

Однако прежде чем восстанавливать папку, можно попробовать найти удаленный файл с помощью поиска Windows. Давайте рассмотрим последовательность действий на примере. Я удалил файл support_center01.png , а теперь он мне понадобился. Я знаю, в какой папке он находился, и ищу файл в ней (а если бы не знал точное расположение, искал бы в ближайшей родительской).

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

В теневых копиях нашелся не только нужный мне PNG-файл, но и давным давно удаленный BMP-файл с тем же именем, о котором я и думать забыл.

Почему предыдущие версии файлов могут отсутствовать

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

• отключена защита системы , т.е. отстутствуют теневые копии, где хранятся предыдущие версии системных файлов
• для защиты системы выделено незначительное дисковое пространство, поэтому для теневых копий пользовательских файлов не хватает места
• файл или содержимое папки не изменялись — в этом случае их теневые копии не создаются
• теневые копии работают нормально, но не включено что-либо из перечисленного ниже:
  клиент для сетей Microsoft в свойствах подключения
  служба доступа к файлам и принтерам сетей Microsoft
  службы «Рабочая станция», «Сервер» и «Модуль поддержки NetBIOS через TCP/IP»
  административные общие сетевые ресурсы/li>

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

Восстановление системы из заранее созданного образа

Ввиду разнообразия средств восстановления Windows, я подготовил сравнительную таблицу . В ней вы найдете краткое описание способов восстановления и механизмов их работы, а также ссылки на подробные статьи о каждом из средств.

Теперь непосредственно о процессе. Выполнив загрузку в среду восстановления, вы сможете восстановить систему из заранее созданного образа.

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

Загрузка в среду восстановления Windows 7 с жесткого диска

Для того чтобы войти в меню Дополнительные варианты загрузки , нажмите F8 после включения компьютера, но до загрузки операционной системы.

Выберите первый пункт меню — Устранение неполадок компьютера и нажмите Ввод. Запустится среда восстановления Windows, где первым делом вам будет предложено выбрать раскладку клавиатуры.

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

После ввода пароля вы увидите меню с вариантами восстановления, одним из которых является Восстановление образа системы .

Восстановление образа системы из среды Windows RE

В среде Windows RE имеются различные средства восстановления системы.

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

Вы можете отформатировать диски и создать разделы, при этом у вас имеется возможность исключить диски из операции форматирования (диск, содержащий архивный образ автоматически исключается). Также, вы можете просто восстановить образ на имеющемся системном разделе. За кнопкой Дополнительно скрывается еще две опции.

Определившись с параметрами восстановления, нажмите кнопку Далее , а затем, в последнем окне мастера, нажмите кнопку Готово . Windows предупредит вас о том, что все данные будут удалены с раздела, и запустит процесс восстановления.

Если у вас нет установочного диска Windows, обязательно создайте диск восстановления системы. Этот диск позволит вам восстановить резервный образ системы даже в том случае, если на жестком диске окажется поврежденным служебный раздел Windows RE.

Если вам не удается найти файл на компьютере или он был случайно удален или изменен, то вы можете восстановить его из резервной копии или попытаться восстановить его предыдущую версию. Предыдущие версии - это копии файлов и папок, которые Windows автоматически сохраняет в составе точки восстановления. Предыдущие версии иногда называют теневыми копиями. Для операционной системы Windows XP функция восстановления предыдущих версий файлов недоступна. Для остальных операционных систем семейства Windows набор действий для восстановлений будет различен:

Резервное копирование и восстановление файлов в Windows 10:

Нажмите кнопку Пуск ​ , затем выберите Параметры > Обновление и безопасность > Резервное копирование > Добавление диска и укажите внешний диск или сетевое местоположение для резервного копирования.

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

Создание «Истории файлов» и их восстановление в Windows 8.1:

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

История файлов создает только копии файлов, хранящихся в папках "Изображения", "Музыка", "Видео", "Документы" и "Рабочий стол", а также файлов из OneDrive, доступных автономно на компьютере. Если нужно заархивировать файлы или папки, находящиеся в другом месте, переместите их в одну из этих папок.

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

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

1) Переместите курсор мыши в правый нижний угол экрана, потом вверх и нажмите кнопку Поиск .

2) Введите параметры истории файлов в поле поиска и выберите пункт Параметры истории файлов .

3) Выберите элемент Выбор диска и выберите нужный сетевой или внешний диск.

4) Включите параметр История файлов.

Примечание.

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

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

Чтобы восстановить файлы или папки с помощью истории файлов, сделайте следующее:

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

2) В поле поиска введите имя файла, который нужно найти, или воспользуйтесь стрелками влево и вправо для просмотра разных версий папок и файлов.

3) Выберите нужный файл или папку и нажмите кнопку Восстановить .

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

Восстановление утерянных или удаленных файлов в Windows 7 :

В Windows 7 существует два способа восстановления утерянных файлов – восстановление из резервной копии и восстановление предыдущих версий файлов.

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

Откройте средство "Архивация и восстановление". Для этого нажмите кнопку Пуск , последовательно щелкните Панель управления , Система и ее обслуживание и Архивация и восстановление .

Щелкните Восстановить мои файлы , а затем следуйте инструкциям в мастере.

Для восстановления файлов предыдущих версий Нажмите кнопку Пуск и щелкните Компьютер . Найдите папку, в которой хранился нужный файл или папка, щелкните ее правой кнопкой мыши, а затем щелкните Восстановить прежнюю версию . Если папка была расположена на верхнем уровне диска, например по пути "C:\", щелкните диск правой кнопкой мыши, а затем щелкните Восстановить прежнюю версию . Отобразится список доступных предыдущих версий файла или папки. В этот список включаются и файлы, сохраненные при резервном копировании (если вы используете программу архивации данных), и точки восстановления (если доступны оба типа архивации).

Архивация и восстановление данных в Windows Vista :

Инструменты по резервированию и восстановлению данных в Windows Vista находятся в одном окне , для открытия которого следует выбрать команду Пуск - Панель управления - Система и ее обслуживание - Резервное копирование данных компьютера .

Для настройки автоматической архивации данных , проделайте следующее:

1) Нажмите кнопку Архивировать файлы ивыберите место для хранения резервной копии - на жестком диске, компакт-диске/DVD или на сетевом ресурсе.

2) Если выбран вариант сохранения резервной копии на жестком диске, компакт-диске или DVD, выберите привод из раскрывающегося меню, если вариант сохранения резервной копии на сетевом ресурсе, нажмите кнопку Обзор , чтобы перейти к выбранному сетевому ресурсу, после чего нажмите Далее чтобы выбрать, какие именно разделы жесткого диска следует архивировать.

3) Убедитесь, что флажок установлен рядом со всеми типами файлов, для которых необходимо создать резервную копию, и нажмите кнопку Далее .

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

Для восстановления файлов из резервной копии необходимо снова обратиться к окну Центр архивации и восстановления .

1) Нажмите кнопку Восстановить файлы и выберите вариант восстановления Файлы из последней резервной копии или Файлы из предыдущих резервных копий и нажмите кнопку Далее .

2) Чтобы выбрать файлы и папки для восстановления, нажмите кнопку Добавить файлы , Добавить папки или Поиск .

3) Выберите место для хранения восстановленных файлов - В исходное место или В следующее место , после чего нажмите кнопку Начать восстановление .

Также Вы можете использовать бесплатную утилиту Shadow Explorer для просмотра и редактирования всех имеющихся теневых копий в системах Windows Vista/7/8.

Для получения дополнительной информации обратитесь в .

Традиционно, пользователи 1С делятся на две категории: тех, кто делает резервные копии*, и тех, кто начнет их делать. Чтобы не учиться на собственных ошибках, давайте начнем делать резервное копирование прямо сейчас.

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

Стоит ли вообще тратить на это время?

Разве в наше время информационная база 1С может как-то сломаться? Ломается все: чайники и самолеты, ножка от табуретки и электронный микроскоп. Трудно сломать только что-то очень простое, например, чугунный шар. Но информационная база 1С – сложный объект и функционирует в сложной технологической среде. Рано или поздно что-то произойдет, сначала совсем незначительное, а далее «открутившийся винтик» вызовет каскадную реакцию отказов ПО и оборудования, которая в итоге закончится крупными неприятностями и потерей информационной базы.

Файловый вариант информационной базы

Начнем с самого простого примера. В небольшой организации работает конфигурация 1С с файловой информационной базой, которую обслуживает приходящий системный администратор, который вероятно все настроил. Но! Отсутствие сообщений «Не настроено резервное копирование» вовсе не означает, что теперь оно настроено. Это может означать также, что данное сообщение просто не показывается. Поэтому, взяв на себя ответственность за надежность и сохранность результатов своего труда, для начала убедимся, что информационная база именно файловая. Как это сделать – наглядно показано на иллюстрации ниже. Если вместо File= написано Srv=, это SQL-база и для настройки резервного копирования обратитесь к вашему администратору баз данных. Если база файловая, можно воспользоваться ручным или автоматическим копированием.

Ручной способ – создайте резервную копию, как показано на иллюстрации. Перед выгрузкой все пользователи должны завершить работу с информационной базой. Выгрузка создает один файл резервной копии с расширением DT, в котором будет почти все (об этом – далее), что есть в данный момент в информационной базе, и не будет того, что введется после. Дайте осмысленное имя файлу (например, «Резервная копия Управления торговлей на 2017-10-31») и выберите для его сохранения специальную папку (например, папка «Резервные копии» в папке «Мои документы»). Используя этот файл, вы можете впоследствии восстановить информационную базу до состояния, которое предшествовало выгрузке. Для восстановления надо использовать операцию «Загрузить информационную базу».

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

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

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

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

• Все ли попадет в резервную копию?

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

• Можно ли делать резервную копию в процессе работы?

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

• Как часто надо делать резервные копии?

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

• У нас были случаи потери данных, и мы бы хотели перейти на SQL-вариант информационной базы, но это очень дорого…

Возможно, вам подойдет бесплатный вариант MS SQL. Обратитесь к нам за консультацией.

SQL-вариант информационной базы

Данная часть статьи будет интересна специалистам и тем, кто еще только собирается им стать.

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

С точки зрения пользователя, живущего в понятийном пространстве файловых баз, у нас есть точки восстановления в виде бэкапов информационной базы, разделенные по времени частотой резервного копирования: если мы делаем копии раз в сутки, то в случае восстановления потеряем изменения, сделанные в базе максимум за сутки или меньше. Но в среде SQL server и способ хранения/изменения данных, и технологии резервного копирования предусматривают «бесконечное» количество точек, сливающихся в одну непрерывную прямую восстановления. Это означает возможность отката на точку, непосредственно предшествующую моменту сбоя или при необходимости на любой момент времени назад. На языке пользователя, это равнозначно созданию резервных копий раз в секунду и менее того.

Дело в том, что резервное копирование в среде SQL – это не последовательность нажатий кнопок, а комплекс регулярных мероприятий над сложно устроенными объектами. И этот комплекс создается в весьма сложной среде.

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

Неужели так важно восстановление данных с точностью до секунды?

Это важно для фронт-офисных систем или в случае, когда предприятие достигает определенного масштаба. Поясним это утверждение, задав несколько наводящих вопросов. Легко ли организовать повторный ввод данных в филиальной сети, разбросанной по 10 регионам с разными часовыми поясами и имеющей несколько тысяч сотрудников? Как проконтролировать его правильность? Допустим, можно взять накладную и повторно ввести с нее данные. А как выполнить повторный ввод данных, которые поступали в систему при взаимодействии с аппаратурой (фискальные регистраторы, банковские терминалы) или со сторонними информационными системами (онлайн-кредит, процессинг скидочных карт единой партнерской сети), при участии большого количества людей (системы учета рабочего времени по отпечатку пальца)? Где взять источник информации для повторного ввода, если нет никаких документов, а все действия фиксируются безбумажным способом (учет питания в корпоративной столовой по карте сотрудника)?

Как получить копию базы со всеми данными, которые находились в системе «за секунду до взрыва»

Журнал транзакций (Transaction log, TLog)

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

Резервные копии журнала транзакций (Transaction log backup, TLog backup)

Образно выражаясь, мы будем регулярно забирать из журнала все листы и относить их в соседнюю комнату (назовем изъятые листы TLog backup), а в сам журнал класть пачку новых чистых листов, чтобы было, куда записывать новые действия с базой. Технически это выполняется так: снимается копия с файла TLog и записывается на архивный диск, после чего все записи в TLog «стираются» (помечаются как свободные, размер файла журнала не меняется), на «стертом» месте пишется информация о новых транзакциях. Очень важно понимать – каждая вырванная пачка листов, хоть и называется в устоявшейся терминологии Transaction Log backup, является единственным носителем информации о действиях с базой за этот период, а в самом журнале этой информации теперь нет. Поэтому потеря даже одного «вырванного листа» пока абсолютно недопустима, а термин TLog backup коварно маскирует сущность и назначение данной информации. Запомните – это не бэкап! Мы разбили журнал на множество файлов и информация в каждом из них нигде не продублирована. Но термин Transaction Log Backup общепринят, поэтому и дальше мы будем использовать именно его.

Теперь TLog бесконечно не растет, но возникает регламентная задача – резервное копирование TLog по расписанию.

Полные резервные копии базы данных (Full database backup, Full backup)

Если периодически делать копии всей базы данных, то для восстановления можно будет взять наиболее подходящую по времени копию и повторить не все операции с нулевого момента времени, а только операции с момента создания этой копии до момента восстановления (как говорят, «взять Full backup и накатить на него TLog»). Это значительно сокращает время восстановления, особенно если база существует уже лет 5. Помимо этого, теперь у нас появилась возможность удалять старые Full backup и TLog backup. На самом деле, откат назад с точностью до секунды зачастую может быть необходим только на коротком временном периоде (например, два месяца назад от текущего момента для расследования каких-то инцидентов или для восстановления базы за секунду до трагического внесения нежелательных изменений). В течение этого периода мы и будем хранить непрерывную цепочку TLog backup. За пределами этого периода можно хранить лишь точки восстановления в виде Full backup (и то не все, а например, только точки на первые числа месяца). TLog backup за пределами периода можно теперь удалять вообще (очевидно, что их выборочное удаление и выборочное хранение за пределами периода совершенно бессмысленно из-за нарушения непрерывности цепочки TLog). Так или иначе, возникает регламентная задача интеллектуального удаления.

Здесь возникает следующая проблема. Представим базу данных с большим количеством пользователей и высокой интенсивностью изменений. Условно – 33% времени тратится на запись и 67% на чтение, простоев нет. Когда мы будем восстанавливать базу, мы можем писать почти 100% времени, т.е. в три раза быстрее. Значит, мы можем три часа работы с базой восстановить по журналу за час. И этот час – максимальное время простоя на восстановление, на которое согласен бизнес. Допустим, Full backup делается раз в сутки. Если сбой произошел через 21 час от этого момента – нам придется потратить на восстановление по журналу 7 часов, что уже абсолютно неприемлемо. Значит, Full backup надо делать 1 раз в 3 часа? Увы, не всегда это возможно: базы бывают настолько большими (сотни гигабайт и даже терабайты), что за такое время Full backup создать просто невозможно. К тому же частое создание Full backup в рабочее время дает дополнительную нагрузку и замедляет работу пользователей, да и хранить такое количество данных весьма накладно. Но в принципе достаточно и того, что отсутствие возможности создать Full backup за приемлемое время полностью ставит крест на нашей технологии резервного копирования.

Разностные резервные копии (Differential backup, Diff backup)

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

В этом месте очень удачно можно сравнить дифференциальный бэкап и бэкап журнала транзакций, закрепив полученную информацию. Если не делать полную копию – размер дифференциальных бэкапов будет монотонно увеличиваться, т.к. будет накапливаться все больше и больше отличий от полной копии – и так до создания очередного полного бэкапа. Размеры очередных бэкапов журнала транзакций не будут иметь такой тенденции, их размер определяется количеством произведенных действий с базой за период. Обычно их размер колеблется вокруг некоего среднего значения, но в отдельные периоды (при выполнении операций массового изменения данных, при всплеске активности пользователей и т.д.) может очень сильно отличаться от среднего.

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

• 5+7=3. Это означает, что имея Full backup 5 и Diff backup 7 можно восстановить базу в состояние 3. При этом отсутствие 6 никак не повлияет на возможность восстановления.
• 5+10+11=3. Того же результата (восстановить в состояние 3) можно достичь, если к Full backup 5 применить все изменения, зафиксированные в TLogBackup 10 и 11. Так придется делать, если у нас отсутствуют 6 и 7 из-за того, что расписанием было предусмотрено только создание 5 и 8 (или если 6 и 7 повреждены). Но если 7 есть, то способ 5+7 гораздо быстрее способа 5+10+11.
• Если отсутствует только 7, то базу в состояние 3 можно восстановить способом 5+6+11.
• Если расписание таково, что 11 не создавалось, содержимое 12 будет следующим: «Добавлены: Топорков, Уфимцев, Яшин».
• Журнал транзакций, на первый взгляд, на картинке не представлен, но как вы помните, TLog backup – это никакой не бэкап, а журнал транзакций за определенный период. Обратите внимание, что появление новых фамилий в журнале предшествует их появлению в базе данных.
• Если не создавать резервные копии журналов транзакций, содержимое TLog в момент 12 будет следующим: «Добавлены:», а далее список фамилий 4 (т.е. зафиксированы все действия). Если резервные копии созданы, как на картинке, то содержимое журнала транзакций в момент 4, как и в момент 8, будет следующим: «Никаких действий пока не производилось».

Резервное копирование заключительного фрагмента журнала транзакций

Если речь не идет о системах высокой доступности, то в случае сбоя нужна еще одна уже не регламентная, а ручная операция – создание самого последнего TLog backup. Если это невозможно, т.е. журнал поврежден вместе с базой или вместе с сервером – восстановление возможно только до момента последнего TLog backup, а не на последнюю секунду. Т.е. поставленная изначально цель не будет достигнута.

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

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

Full recovery model (работает только с регламентными заданиями и под контролем администраторов)

Мы описали полную модель восстановления базы данных – Full recovery model. Для особых случаев в MS SQL Server существует простая модель восстановления (Simple recovery model) и модель с неполным протоколированием (Bulk-logged). Full recovery model предусматривает регулярное выполнение задач обслуживания базы данных, а также контроль регулярности и результатов выполнения заданий со стороны администратора. Это предполагает существование сложного инструментария проектирования плана обслуживания (Maintenance Plan), который необходимо изучить.

Перейдем к практике

Возможно, первая трудность, с которой придется столкнуться – невозможно создать новый план обслуживания.

Надо разрешить этот функционал выполнением SQL-скрипта (New Query на панели инструментов, набрать скрипт, Execute на панели инструментов). При успешном выполнении скрипта вы увидите соответствующие сообщения в нижней части окна со скриптом.

Текст этого скрипта для копирования/вставки:

sp_configure "show advanced options", 1; GO RECONFIGURE; GO sp_configure "Agent XPs", 1; GO RECONFIGURE GO

Реальный план обслуживания

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

В обозревателе объектов мы видим, что на SQL сервере настроено два плана обслуживания (Основной план, Тестовый план). Основной план состоит из четырех подпланов с разным расписанием (Shedule):

• Еженедельное обслуживание
• Дифференциальный бэкап
• Бэкап ЖТ

В области дизайна задач мы видим задачи. Процесс конструирования плана заключается в перетаскивании задач с палитры Toolbox, установки параметров задач и рисовании стрелок между задачами. Задачи могут иметь произвольное описание в области дизайна, соответствие между задачей на плане и задачей на палитре можно установить по иконкам. Например, задача «Ошибка целостности» – это задача «Notify operator task» на палитре (иконка «человек»).

Это блок-схема?

Первое, что можно подумать, глядя на сценарий выполнения задач плана обслуживания – что это блок-схема, стрелочки обозначают переходы от одной задачи к другой, и по ним можно пройтись указательным пальцем, проследив весь сценарий от начала и до конца. Однако это не так. Бывает, с первого взгляда даже сложно определить, с чего все начинается и какова последовательность выполнения задач. Сценарий в общем случае может начинаться в нескольких местах и заканчиваться также в нескольких местах, потому что SQL сервер стремится запустить абсолютно все задачи одновременно.

Параллелизм и ограничения

Единственное, что его останавливает – наличие ограничений. Задача не может быть запущена, пока не «сбылись» входящие в нее стрелки (ограничения, restrictions). Цвет стрелки обозначает тип завершения влияющей задачи. Входящая зеленая стрелка обозначает для зависимой задачи ограничение «запустить только в случае успешного выполнения влияющей задачи», черная – «запустить только после завершения влияющей задачи (Completion)», красная – «запустить только в случае ошибки во влияющей задаче (Failure)».

Тип линии (сплошная или пунктир) обозначает логический оператор AND или OR для вычисления итогового ограничения от нескольких входящих стрелок. Этот оператор меняется в диалоге Precedence Constraint Editor (двойной клик по любой из стрелок). Сплошные стрелки должны сбыться все, из пунктирных должна сбыться хотя бы одна – тогда зависимая задача сразу будет запущена. Цвет каждой входящей стрелки можно менять независимо (правый клик, Success/Failure/Completion). Тип линии можно изменить только для всех входящих стрелок сразу (двойной клик, диалог Precedence Constraint Editor). Сначала начинают одновременно выполняться все задачи, не имеющие ограничений. Как только завершается очередная задача, проверяются все зависимые от нее задачи и одновременно запускаются на выполнение те, у которых итоговое значение ограничений стало достаточным для принятия решения о запуске.

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

Странное расписание

Странное время выполнения задач объясняется разницей 4 часа между часовым поясом серверов и часовым поясом разработчиков. Диапазон возможного времени работы разработчиков с 9:00 до 21:00, поэтому подплан «Бэкап ЖТ» выполняется каждый час с 10:00 до 21:00, фиксируя изменения каждый час (в 9:00 этих изменений еще нет). В переводе на часовой пояс серверов это с 14:00 дня до 01:00 часа ночи, что и указано в расписании.

При указании времени можно перескакивать через полночь, это корректно работает. Выглядит немного непривычно. Другие планировщики во избежание трудностей с пониманием времени окончания в следующих сутках запрашивают длительность выполнения задачи – «в течение Х часов».

Если за полным бэкапом немедленно следует бэкап ЖТ – можно быть на 100% уверенным в том, что план создан мастером планов обслуживания (никогда не используйте его, он не создает ничего, кроме мусора) или администратором низкой квалификации, считающим пару Full backup + TLog backup, сделанную в одно время, неким обязательным комплектом для восстановления. А ведь это – независимые задачи, выполняющиеся по разным расписаниям.

Но наш план является исключением, поскольку наша цель – в одном подплане собрать информацию об успешности выполнения ключевых задач (целостность, полный бэкап, бэкап ЖТ), и только в случае их успешного выполнения отдать команду на удаление старых бэкапов.

Если удаление старых бэкапов выполняется безусловно, может оказаться, что новые бэкапы не создаются, а старые окажутся удалены полностью. Если удаление старых бэкапов раскидывается в зависимости от типа бэкапа по разным подпланам – получается почти то же самое. Допустим, перестал срабатывать полный бэкап. При этом перестало выполняться удаление старых полных копий. Но подплан Бэкап ЖТ ничего об этом не знает и продолжает удалять устаревшие бэкапы ЖТ. Через некоторое время у нас не будет не только непрерывной прямой восстановления, но и даже точек восстановления в актуальном окне: последний сделанный полный бэкап сделан слишком давно, а хранящиеся бэкапы ЖТ за последнее время абсолютно бесполезны, т.к. нет ни одного полного бэкапа внутри их непрерывной цепочки.

Задача дифференциального бэкапа ключевой для восстановления не является и в подплане не фигурирует. Но в этот подплан все-таки можно было бы добавить и ее, расположив сразу после полного бэкапа.

*

*Заметьте на задаче значок fx

У каждой задачи есть свойства, часть из которых можно увидеть в диалоге настройки задачи (двойной клик), а полный список – в диалоге свойств (правый клик, Properties). Также в задачах есть свойство Expressions, которое позволяет сформировать таблицу свойств и соответствующих им выражений SQL, для вычисления значений свойств «на лету». Практическая польза от этой возможности следующая. Наверняка вам приходилось видеть т.н. «батники» для того, чтобы удалить все, кроме бэкапов на первые числа, или наоборот, чтобы перед удалением бэкапов скопировать бэкапы на эти числа в какое-то другое место.

Подобные задачи не требуют внешних инструментов и решаются штатными средствами MS SQL. Расширение файла полной резервной копии по первым числам можно сделать MNT, а по остальным дням – BAK. А значит, задача очистки может удалять BAK старше 1 месяца, а MNT хранить более длительное время, удаляя их, например, через 1 год.

При открытии диалога настройки задачи «Полный бэкап БД» вы увидите расширение файла BAK или MNT в зависимости от сегодняшней даты.

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

Рассмотрим закономерный вопрос: а все ли корректно будет работать в запрещенной задаче? Как на такой запрет отреагируют красные, черные и зеленые стрелки?

При написании сложных планов обслуживания возникает задача отладки и вытекающие из нее практические потребности:

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

Для первого в MS SQL есть механизм запрета фактического выполнения задачи: правый клик по задаче, Disable. При этом задача станет серой, фактически выполняться не будет, но будет считаться как завершенной, так и выполненной (будут работать черные и зеленые стрелки). Если мы хотим смоделировать ошибочное выполнение, то в окне свойств задачи надо установить свойство задачи ForceExecutionResult в значение Failure. Не перепутайте это свойство со свойством ForcedExecutionValue в другом разделе.

Реализация условия ((A or B) and C) для ограничений задачи или фиктивные задачи, которые совсем не фиктивные

Ограничения могут быть объединены или оператором AND, или оператором OR. Это значит, что на иллюстрации ниже пунктирные стрелки Completion нельзя провести непосредственно к задаче «Оповестить о завершении с ошибками». Решение состоит в создании промежуточной задачи «Были ошибки», аккумулирующей результат пунктирных черных стрелок. Задача является SQL-скриптом из одной единственной инструкции go, то есть, казалось бы, ничего полезного не делает.

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

Асинхронность выполнения

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

Что это такое?

Это первая и одна из последних выполняемых задач, являющихся скриптами SQL. Дело в том, что в контуре разработки часто присутствуют копии исторических систем весьма большого объема. Они предназначены для ознакомления с ведением исторического учета, служат источником данных в операциях миграции. Данные в них практически не меняются. Оригиналы баз находятся в текущем продуктивном контуре заказчика, копии этих систем всегда могут быть получены по запросу. Бэкапить этот гигантский объем информации – впустую расходовать ресурсы. В параметрах задач, создающих бэкапы, хорошей практикой является указание в задачах бэкапа параметра «All» вместо перечисления конкретных баз данных (это позволяет избежать типичной ошибки «базу создали, а в список бэкапа включить забыли»). А раз так, необходим механизм какого-то исключения некоторых особых баз из множества All. Именно это и делает первый скрип – переводит такие базы в состояние OFFLINE. Второй скрипт выполняет обратную операцию. При этом в параметрах задач бэкапа или реиндексирования ставится параметр «Игнорировать базы в состоянии OFFLINE», иначе возникнет ошибка задания.

Параллельно или последовательно

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

В качестве причин последовательного выполнения назовем, допустим, желание не превысить нагрузку сервера SQL во время обслуживания и наглядность восприятия плана. Обычно, за счет большого ночного окна с перерывом в работе пользователей последовательное выполнение не становится проблемой. Но могут быть ситуации, когда с базой работают много пользователей из разных часовых поясов и окно обслуживания становится очень небольшим. Если последовательное выполнение задач не вписывается в окно обслуживания, их придется распараллеливать. Это можно сделать стрелками, исходящими из «Оффлайн небэкапируемых баз» к каждой основной задаче, а затем сходящимися к «Онлайн небэкапируемых баз». Две серые задачи должны выполняться последовательно по отношению друг к другу. Результат распараллеливания на иллюстрации ниже. Достигаются поставленные цели, но значительно теряется наглядность:

Приведем второй вариант, топологически эквивалентный предыдущей схеме, но более наглядный из-за измененного расположения задач + удаления серых задач.

Параллелизм внутри стандартных задач Backup Database и Check Database Integrity и интерпретация результата их выполнения

Задачи «Создание резервной копии» и «Проверка целостности базы данных» работают в общем случае со списком баз данных. Будут ли они работать последовательно с каждой базой данных или возникнет множество параллельных задач обслуживания каждой базы? Выполним двойной клик по задаче, в открывшемся диалоге нажмем кнопку «View T-SQL». Мы видим, что в скрипте, который генерируется и исполняется сервером SQL, инструкции создания резервных копий BACKUP DATABASE разделены инструкциями GO, а значит, эти процессы создания резервных копий будут выполняться параллельно. Результат относится не к пакетам, а к заданию в целом. Если возникла ошибка в задании хотя бы с одной базой – в целом задание будет считаться выполненным ошибочно, если ошибок нет – в целом задание считается выполненным успешно.

Расписание задач обслуживания (ключевой вопрос, часто считающийся второстепенным)

Вспомним главные задачи плана обслуживания базы данных полной модели восстановления:

1. Задача Full backup
2. Задача Diff backup
3. Задача TLog backup

В популярных статьях на тему резервного копирования в среде SQL вопрос расписания задач чаще всего специально не рассматривается или ему отводится второстепенная роль. При этом предлагаемая периодичность выполнения задач внятно не аргументируется. Между тем, данный вопрос является ключевым. Однозначных рекомендаций не существует. Периодичность и состав задач могут быть различными в разных обстоятельствах. Рассмотрим общие принципы.

Главное, из чего надо исходить, это допустимое окно потери данных (Recovery point objective, RPO) + время на восстановление (Recovery time objective, RTO). Эти показатели в свою очередь определяют аппаратную архитектуру, применяемые технологии и периодичность выполнения задач.

Периодичность TLog backup

Периодичность TLog backup зависит от значения RPO. Типовая периодичность задачи TLog backup для продуктивных баз – от ½ до 1 времени RPO на всем суточном интервале времени внесения изменений в базу (включая интервалы времени, на которых происходят изменения регламентными заданиями и разовыми обработками во внерабочее время). Для продуктивных баз характерным является внесение изменений в течение всех 24 часов. Если для такой базы RPO=1 час, то бэкап журналов транзакций должен выполняться круглосуточно каждые 30-60 минут. Но не исключены случаи, когда в силу специфики системы можно ограничиться только интервалом рабочего времени, например с 10 до 18, с понедельника по пятницу, а также большей или меньшей частотой.

Для непродуктивных баз (в среде разработки) более целесообразным может оказаться использование простой модели восстановления, где данная задача вообще отсутствует. Несмотря на то, что в многочисленной литературе и официальной документации декларируется, что использование упрощенной модели не дает выигрыша в производительности (т.к. TLog все равно ведется), на практике это не так. Время выполнения часто выполняющейся операции помещения измененных объектов конфигурации 1С в хранилище при использовании упрощенной модели восстановления сокращается в разы, а суммарный выигрыш по времени резко увеличивает скорость разработки. При этом с периодичностью от ½ до 1 времени RPO надо создавать уже Diff backup. Этот же метод можно использовать для продуктивных бэк-офисных систем с низкой интенсивностью изменения, где есть возможность повторного ввода данных, находившихся в окне RPO и потерянных в результате сбоя.

Взаимосвязанная периодичность Full backup и Diff backup

Периодичность обеих задач в целом подбирается таким образом, чтобы можно было соблюсти RTO. Если интенсивность внесения изменений такова, что позволяет делать полные бэкапы раз в месяц, дифференциальные бэкапы раз в день, и при этом 29-го числа восстановление происходит в рамках RTO – почему бы и нет. Если интенсивность внесения изменений такова, что при такой периодичности задач время восстановления становится неприемлемым – возможно, требуется полная копия на начало дня и несколько дифференциальных бэкапов в течение суток.

Периодичность задачи Diff backup также зависит от объема Diff backup по сравнению с Full backup. Если при выбранной периодичности Diff backup его размер начинает превышать половину размера Full backup, дальнейшее создание Diff backup становится нецелесообразным, в этой точке надо создавать очередной Full backup. Однако стоит помнить, что это соотношение следует игнорировать на относительно новых базах данных – со временем объем ежедневных изменений будет составлять небольшую (т.е. допустимую для Diff backup) часть общего объема данных, а 95% объема будут занимать исторические данные.

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

Для часто обновляемых баз предлагается делать Full backup по воскресеньям, а TLog backup 1 раз в сутки. Окно потери данных (RPO)=1 сутки – это недопустимо много. При этом эксперт убежден, что это и есть лучший способ предотвратить любую потерю данных. Недопустимо большим будет также время восстановления в субботу, ведь надо будет применить к Full backup изменения за 6 дней, а интенсивность изменений в базе большая.

Здесь ежедневно с понедельника по пятницу делается бэкап ЖТ и Shrink ЖТ (Текст «копии БД» в колонке «Описание» – явная опечатка, т.к. в колонке «действия» четко указана операция – бэкап ЖТ). Если вы вернетесь к нашему подплану «Еженедельное обслуживание», то увидите, что задача усечения ЖТ носит красноречивое название «Shrink не делать» и является запрещенной задачей (серая). Поисковый запрос «надо ли делать шринк» поможет уточнить информацию.

Спускаемся на строку ниже и видим, что после каждого Diff backup удаляются TLog backup – это добровольный отказ от непрерывной прямой восстановления (ключевая цель всей системы резервного копирования) и переход к точкам восстановления. Точки отстоят друг от друга на сутки. Это означает, что окно потери данных – сутки (RPO=24 часа).

Спускаемся на последнюю строчку и находим самую крупную ошибку всего плана. Если произошло случайное или злонамеренное повреждение данных, то данные очень надежно хранятся, но являются бесполезными. Представим случай, когда в субботу выходит программист, чтобы разобраться с проблемой «отчеты выдают полную ерунду». В 18:05 он понимает, что наличие проблемы связано с тем, что полностью искажены (удалены) данные ключевых регистров, причем журналы говорят, что это произошло в пятницу после обеда. В этот момент времени у него существует база данных, данные в которой неверны, и один единственный полный бэкап, сделанный 5 минут назад, данные в котором также неверны. Все остальное начисто удалено, т.к. был успешно создан полный бэкап. Этот план обслуживания – чемпион по количеству сделанных ошибок.

На иллюстрации выше – план начального уровня, созданный начинающим специалистом с помощью мастера Maintenance Plan Wizard и не решающий никаких задач. В нем имеется распространенная ошибка: нельзя ставить задачу создания полной резервной копии в зависимость от результатов проверки целостности. При падении базы данных лучше иметь резервную копию с двумя «битыми» ссылками в базе, чем не иметь ничего. Сравните с тем, как сделано в подплане «Ежедневный бэкап» – нарушение целостности информирует оператора, но не препятствует созданию бэкапов.

Особенности восстановления – как не потерять данные

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

Поскольку эти «особенности» нигде не описаны, давайте восполним этот пробел. Рассмотрим типовую задачу восстановления продуктивной базы по состоянию на какое-то время (источник, ZUP3ENERGO на иллюстрациях) в индивидуальную базу программиста (приемник, ZUP_SUV на иллюстрациях) для расследования инцидента. Описывая различные «особенности» поведения разных версий SQL сервер, под термином «новые версии» мы будем подразумевать релиз 13.0.4457.0, а под термином «старые версии» – релиз 11.0.3156.0.

Первое действие – правой кнопкой по базе-приемнику, Tasks, Restore, DataBase. И сразу же в диалоге Restore Database (иллюстрация ниже) мы видим желтый знак опасности: будет сделана резервная копия заключительного фрагмента журнала транзакций базы-источника. Конечно, на самом деле речь должна идти о базе-приемнике и логика тут должна была бы быть следующая: прежде чем уничтожить текущее содержимое восстановлением, давайте на всякий случай окончательно зафиксируем то, что есть сейчас. Это позволит откатить текущее восстановление назад, выполнив впоследствии еще одно восстановление на точку перед восстановлением. Операция, казалось бы, полезная и ничего опасного в ней нет, если бы речь действительно шла о приемнике. Но это не просто ошибка в сообщении, tail-log backup ошибочно выполняется для источника. Это можно проверить экспериментально, нажав кнопку Script и посмотрев код.

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

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

• Источник Database – все множество файлов, содержащее в себе бэкапы базы-источника и ее журналов согласно реестру бэкапов, который ведется в системных таблицах SQL сервера. «Согласно реестру бэкапов» – крайне важная фраза для понимания механизма операции. Она означает, что даже если в настоящее время какой-то файл отсутствует на диске, он может оказаться учтен в плане восстановления (т.к. зафиксирован в реестре) и появится в списке Backup sets to restore. Ошибка возникнет только на стадии восстановления и если это файл Diff backup или TLog backup – база останется в состоянии, непригодном к использованию. Чтобы этого не произошло, предварительно проверяйте возможность восстановления кнопкой «Verify backup Media».
• Источник Device – произвольный набор файлов. Дело в том, что история бэкапов может быть очищена. Или бэкапы создавались на другом сервере SQL и поэтому не зарегистрированы в реестре бэкапов на этом сервере. Поэтому имеется возможность явного указания произвольного набора файлов. Указать можно избыточный для восстановления набор файлов (например, за много дней – SQL сервер на следующем шаге подберет только необходимые).

Второе действие – выбираем источник, который в нашем случае отличается от приемника. Новые версии MS SQL Server реагируют на это нормально. В более старых версиях происходят неприятные эффекты, которые необходимо тщательно отслеживать во избежание потери данных:

• Эффект 1. MS SQL сразу же меняет Destination на базу данных, указанную в Source. Поэтому Destination надо вернуть назад. Если вы не заметите этого – база будет молча перезаписана, и даже снятый флаг «Overwrite the existing database» на закладке Options не сможет ее защитить;
• Эффект 2. Переключаемся на закладку Files и видим – вместо приемника MS SQL Server хочет перезаписать источник (см. следующую иллюстрацию). Необходимо руками вбить имена файлов базы-приемника и ее журнала, иначе будет потерян источник (см. далее четвертое действие).

Третье действие. После выбора набора файлов в качестве источника необходимо уточнить момент времени (Restore to, кнопка Timeline). Уточнение момента времени позволяет из исходного множества файлов, определяемых источником (Source), выбрать конкретный набор (Backup sets to restore), необходимый для восстановления на указанное время. Становится очевидной еще одна несуразность, присутствующая даже в самых последних версиях MS SQL: опция «Restore to» и кнопка TimeLine нарисованы в диалоге совсем не там. Они, безусловно, относятся к источнику, а не к приемнику. Эта ошибка не будет исправлена никогда, ей более 10 лет, поэтому к ней надо просто привыкнуть. Будьте также очень внимательны при ручном вводе времени без использования линейки: даже последние версии SQL сервера «съедают» первый ввод числа месяца, так что число необходимо будет ввести два раза.

Четвертое действие.

Пятое действие. Переключаемся на закладку Options. Поставьте опцию перезаписи базы данных, снимите опцию создания заключительного фрагмента ЖТ, включите опцию «закрыть существующие подключения к базе-приемнику», если она доступна:

Шестое действие. После восстановления из «чужого источника» восстановленная база (ZUP_SUV) получит чужое логическое имя (ZUP3ENERGO). Его необходимо вернуть назад в диалоге свойств базы данных (правый клик по базе, Properties). Если этого не сделать, то наступят очень неприятные последствия.

Удачи вам и вашим данным!

← Вернуться