Если Windows настаёт «каюк», то что обычно можно предпринять в этом случае? Те, кто менее опытные видят в голове одно универсальное решение - переустановить систему. Я бы отложил такой вариант на крайний случай, ведь после переустановки у вас будет «голая» Windows без ранее установленных вами программ. И придётся вам в итоге устанавливать и настраивать всё заново. Другой вариант - восстановить систему из контрольной точки, однако, это не всегда помогает. А как же сделать так, чтобы и программы сохранить и проблемы от возникших в системе проблем разом избавиться? Для этого вам нужно предварительно создать резервную копию раздела, на который установлена Windows и тогда в случае любых сбоев в её работе, вы всегда сможете восстановить систему до того состояния, на момент которого вы создавали копию, со всеми программами и параметрами. В данной статье я покажу, как восстановить Windows из резервной копии.

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

Процесс восстановления системы из резервной копии в Windows 8 (8.1) и Windows 10

Запуск программы для восстановления

Для того чтобы запустить процесс восстановления системы Windows 8 и Windows 10 из резервной копии есть несколько способов:

Таким образом, если у вас Windows 8 / 10 хотя бы успешно запускается, то запустить восстановление проще всего по 1-му способу. Если система не запускается и сама не открывает диагностическую программу, то вам нужен либо диск восстановления (способ 2), либо установочный диск с Windows 8 / 10 (способ 3). Если ни того, ни другого диска нет, и Windows не загружается, то вы не сможете запустить процесс восстановления!

Процесс восстановления из образа

После того как вы запустите специальную оболочку (программу), через которую можно выполнить различные варианты восстановления Windows, она будет выглядеть вот так:

Выберите «Диагностика».

В следующем окне нажмите «Дополнительные параметры».

Затем выберите «Восстановление образа системы».

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

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

Если у учётной записи есть пароль, введите его (1) и нажмите «Продолжить» (2) либо просто нажмите эту кнопку.

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

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

Когда образ с резервной копией будет найден, программа восстановления сама его выберет (если вы создавали несколько копий, то будет выбран самый последний, актуальный). Нажмите «Далее» (2).

Если вдруг программа автоматически выбрала не ту резервную копию, то нажмите «Выберите образ системы» (3) и нажмите «Далее», чтобы вручную найти резервную копию. И в следующем окне вы сможете выбрать образ из списка найденных либо нажать «Дополнительно», чтобы включить поиск образа в сети или установить драйвер для оборудования, которое не распознаётся данной программой и на котором хранится ваша резервная копия.

В следующем окне, если активна опция «Исключить диски» (1), то вы можете нажать соответствующую кнопку, для того чтобы исключить те диски, которые не должны участвовать в процессе восстановления, поскольку информация на всех восстанавливаемых дисках будет удалена и разделы на них будут созданы заново. Если эта опция не активна, то, скорее всего, у вас подключено, итак, только 1-2 диска и выбор сделать нельзя.

Для запуска процесса восстановления нажмите «Далее».

Нажав «Дополнительно» (2), вы можете настроить ещё 2 опции:

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

В последнем окне остаётся нажать «Готово» чтобы запустился процесс восстановления Windows 8 / 10 из выбранной вами резервной копии.

Время восстановления напрямую зависит от размера вашей резервной копии, из которой вы восстанавливаете систему.

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

Нажмите в нём «Перезагрузить сейчас».

На этом всё! Восстановление Windows 8 или Windows 10 из образа завершено.

Процесс восстановления системы Windows 7 из резервной копии

Запустить процесс восстановления Windows 7 из созданного ранее образа (резервной копии) можно только 2-мя способами:

1. Загрузиться с установочного диска Windows 7.
2. Загрузиться с ранее созданного диска восстановления.

Следовательно, если Windows 7 у вас не запускается (а также сама не запускается так называемая диагностика) и у вас нет одного из указанных выше дисков, то восстановить систему из образа вы не сможете.

Сам процесс восстановления аналогичен тому, что был описан в главе выше, для Windows 8 и Windows 10. Покажу его запуск на примере загрузки с установочного диска Windows 7 (при загрузке с диска восстановления всё будет аналогично).

Итак, когда выполнится загрузка с установочного диска, нажмите «Далее».

В следующем окне выберите «Восстановление системы».

Заключение

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

А сам процесс восстановления не является сложным, как видите, в особенности если у вас установлены системы Windows 8 или Windows 10, поскольку процесс восстановления можно запустить прямо из их оболочки (если, конечно, Windows хотя бы запускается). С Windows 7 всё чуточку посложнее только лишь тем, что нельзя запустить восстановление прямо из Windows, а нужно обязательно иметь диск восстановления либо установочный диск с Windows.

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

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

Способы резервного копирования (архивации) и восстановления

Windows 7: встроенный инструмент архивации и восстановления

Он довольно прост в использовании и даже позволяет выполнять эту процедуру автоматически по расписанию. Расположение в системе инструмента резервного копирования: «Пуск | Все программы | Обслуживание | Архивация и восстановление» . Меню в колонке слева - «Создать диск восстановления системы» и «Создание образа системы» .

Создание образа системы. Необходимо указать расположение будущего архива: выбираем другой дисковый раздел, внешний HDD или оптический диск (DVD, Blue Ray). Также присутствует возможность сохранения резервной копии на сетевой диск. Использовать оптические носители нецелесообразно, поэтому для хранения резервной копии используйте логический диск с достаточным местом для хранения или внешней HDD. Выбрали место, нажимаем кнопку «Архивировать». Архивироваться будет весь системный раздел. Эту процедуру можно проводить по расписанию, при этом Windows обновляет записанный ранее образ системы, не создавая его заново, что существенно экономит время.

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

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

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

Резервное копирование и восстановление с помощью Acronis True Image Home 2013

Пользователям Windows XP, где отсутствует встроенный инструмент резервирования, а также пользователям с более высокими требованиями к функциональности бэкап-программы я порекомендую воспользоваться Acronis True Image Home 2013 .

Acronis True Image Home использует 3 метода создания резервной копии.

Полный образ — архивирование абсолютно всех данных, включая MBR (если раздел является загрузочным).

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

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

Резервную копию системного раздела сделать просто: в главном окне программы выберите первую опцию - «Резервное копирование дисков и разделов» , затем укажите раздел или диск, задайте место для сохранения архива и при необходимости измените параметры архивирования (например, установите степень компрессии архива на вкладке «Производительность» или защитите архив паролем). По окончании процесса в указанном вами хранилище будет создан файл с расширением *.tib . Acronis True Image Home 2013 позволяет подключить резервную копию как логический диск и работать с нужными данными. Таким образом можно извлечь из заранее созданного архива нужный файл, который вы случайно полностью удалили с жесткого диска.

Кроме резервирования разделов и дисков вы можете архивировать (в том числе по расписанию) отдельные каталоги и файлы, а также адресную книгу Windows, список контактов и переписку Microsoft Outlook. Для восстановления в самых тяжелых случаях можно использовать загрузочную версию программы (boot диск или загрузочный диск), причем возможно создание такого решения как на оптическом, так и USB-носителе.

Случается, что при экспериментах с установкой нескольких операционных систем оказалась испорченной главная загрузочная запись (Master Boot Record), можно попробовать «оживить» ее, отметив галочкой «MBR» при восстановлении из образа. Также, Acronis True Image Home 2011 может конвертировать резервные копии из своего «родного» формата в формат VHD (это резервные копии, созданные системным инструментов Windows 7, и одновременно образы виртуальных дисков, то есть их можно подключать почти к любым виртуальным машинам) и обратно.

В большинстве случаев восстановление сводится к выбору нужного архива и раздела, в котором и будет развернуто содержимое резервной копии. Стоит отметить чрезвычайное долгое время установки и низкую скорость работы Acronis True Image Home в Windows XP.

Paragon Backup & Recovery Professional: резервное копирование с дополнительными возможностями

Про программу Paragon Backup & Recovery Professional, которая осуществляет резервное копирование и восстановление файлов я рассказывал в , правда, с целью переноса Windows на другой ПК. В отличие от продукта Acronis, помимо операций архивирования она позволяет осуществлять также некоторые действия с разделами - например, изменение метки, форматирование, скрытие и удаление. Однако для этого вам потребуется переключиться в «Режим для опытных пользователей».

Перед резервным копированием рекомендуется создать аварийный диск для восстановления данных из образа. Для этого необходимо зайти в раздел «Утилиты» и выбрать «Создание аварийного диска». В качестве носителя здесь также можно выбрать либо оптический, либо внешний жесткий диск, или USB-флешку.

Для создания резервной копии данных зайдите в раздел «Защита и восстановление данных | Интеллектуальное архивирование», не забыв перед этим приготовить надежное хранилище. Вы можете выбрать, что резервировать: «Диски или разделы», e-mail (электронные письма, учетные записи и адресные книги Outlook, Outlook Express и Windows Mail), «Медиа-Файлы» и «Документы» (тексты, фотографии, видео и музыка, хранящиеся в каталоге «Мои документы») или же «Другие Файлы или папки».

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

Для опытных пользователей в Backup & Recovery имеется профессиональный инструмент для работы с образами виртуальных машин Virtual PC, VMware Workstation и VMware Fusion. Благодаря ему вы сможете конвертировать образ реального жесткого диска, например системного раздела, и затем открыть его вместе со всеми данными и программами в виртуальной машине даже на другом компьютере.

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

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

Подготовка

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

Неважно, каким образом произошла проблема, главное - всегда помнить основное правило: если случайно удалились файлы, перед тем как восстановить данные на "Андроиде", старайтесь как можно меньше использовать аппарат. Дело в том, что, если на накопителе окажутся другие файлы, вернуть старые уже не получится.

Если очистилась SD-карта

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

Первое, что нужно сделать, — скачать специальную программу, которых на просторах интернета великое множество. Но лучше, если это будет бесплатная утилита, например Recuva или TestDisk.

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

Есть ли жизнь после hard reset?

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

Для тех, кто задается вопросом о том, как восстановить сброс данных на "Андроиде" после hard reset, ответ прост: помогут все те же сторонние утилиты. Проблема в том, что программа для восстановления файлов может не поддерживать конкретную модель телефона. Поэтому имеет смысл для начала попробовать бесплатную версию. Перечень программ, способных восстановить удаленные данные на "Андроиде" - как на телефоне, так и на планшете:

• EaseUS MobiSaver;
• iSkySoft Android Data Recovery;
• Wondershare Dr.Fone;
• Recovery;
• 7-Data recovery.

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

Как извлечь данные памяти телефона при помощи компьютера?

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

1. Клиент скачивает необходимую утилиту на свой компьютер и устанавливает ее.
2. Смартфон или планшет подключается к ПК при помощи USB-кабеля.
3. Осуществить глубокое сканирование данных.

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

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

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

Для начала следует отключить телефон и далее одновременно нажимать на кнопки включения и звука. В открывшемся окне инженерного меню нужно нажать на вкладку backup and restore и далее - бэкап. Скопированные данные телефона будут сохранены в памяти флеш-карты и в любой момент могут быть перенесены на ПК.

Теперь, когда вы в очередной раз зададитесь вопросом о том, как восстановить данные с "Андроида" после случайной очистки, достаточно воспользоваться вкладкой restore в том же меню.

Да здравствуют сервисы «Гугл»!

Обычно все гаджеты, будь то телефон или планшет, на базе "Андроида" синхронизируются с аккаунтом «Гугл». Если на аппарате был выполнен вход с учетной записи Google, а в настройках включена синхронизация, восстановить "Андроид" без потери данных не составит труда.

Если пользователь ранее включил синхронизацию, все, что нужно сделать, — войти в приложение «Гугл Плей», используя свои логин и пароль. Далее автоматически будет загружено следующее:

• все контактные данные (адреса, номера телефонов, имена);
• данные приложений;
• фото и видео, сохраненные на "Гугл Диске".

В случаях когда нет аккаунта «Гугл» или не была осуществлена синхронизация, к сожалению, восстановить данные на "Андроиде" при помощи бэкапа не получится.

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

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

Если вы хотите вернуть платное приложение, которое уже оплатили, достаточно просто переустановить его. Как обычно, такие приложения привязываются к аккаунту «Гугл» и не требуют повторной оплаты. Если в списке нет приложения, которое вам нужно, вполне возможно, что вы осуществили вход под другой учетной записью. Другая причина отсутствия приложения — полное его удаление из магазина для всех пользователей.

GT Recovery for Android: если нет компьютера под рукой

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

Решить такую нелегкую проблему можно при помощи программы GT Recovery for Android. Это приложение можно найти в Google Play. На момент написания статьи программа предоставляется бесплатно и, по многочисленным положительным отзывам, является одной из лучших в своем роде. Единственной отрицательной стороной данной программы можно считать то, что требуются root-права.

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

На данном этапе наберитесь терпения, процесс сканирования может продолжаться до 30 минут, в зависимости от объема телефона. Как только сканирование завершится, на экране появится список всех найденных файлов. Выберите необходимые и нажмите Next.

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

Меры профилактики

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

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

Заключение

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

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

29.10.2012 Мишель Пуле

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

Мишель Пуле (mapoolet@mountvernondatasystems.com)-редактор журнала SQL Server Pro, соучредитель компаний Mount Vernon Data Systems и Six Sigma Uptime.

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

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

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

Частота резервирования базы данных зависит от того, как долго она будет восстанавливаться из резервной копии. Чем чаще выполняется резервирование базы данных, тем меньше времени займет восстановление. График резервирования и восстановления можно настроить индивидуально для каждой базы данных. Тип резервирования зависит еще от объема базы данных и количества транзакций, выполняемых за единицу времени. Основными типами резервирования являются полное, журнальное и инкрементальное. Более подробные сведения о режимах восстановления приведены во врезке «Модели восстановления баз данных», команды по резервированию SQL Server описаны во врезке «Стандартные команды для резервирования».

Полное резервирование

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

Больше всего полное резервирование подходит для «небольших» баз данных – назовем так базы данных, резервирование которых может быть завершено за отведенное для этого время. Когда SQL Server осуществляет полное резервирование базы данных, сначала выполняется сохранение на диск всех экстентов (экстент представляет собой восемь идущих последовательно страниц, размер каждой составляет 8 Кбайт). Затем SQL Server резервирует журнал транзакций, чтобы все изменения базы данных, которые могли произойти за время резервирования, также были сохранены в файле полной резервной копии.

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

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

Для выполнения полного резервирования базы данных выполните следующий код:

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’WITH INIT, NAME = ‘AdventureWorks Full Db backup’, DESCRIPTION = ‘AdventureWorks Full Database Backup

Параметр DISK определяет целевой файл резервной копии. Вы можете выполнять резервирование на диск или на ленту (в данном случае – на диск). Перед началом резервирования убедитесь, что папка для хранения резервной копии существует. В большинстве случаев резервирование на диск происходит значительно быстрее, чем на ленту, но стоимость дисковой памяти существенно выше. Для обеспечения дополнительного уровня защиты можно выполнять резервирование на диск, а затем сохранять резервную копию на ленту. Параметр WITH INIT указывает, что файл резервной копии должен быть перезаписан. Этот метод подходит в том случае, если резервирование Windows выполняется после каждого резервирования базы данных. NAME – имя резервной копии, до 128 символов. Если имя не указать, поле имени останется пустым. DESCRIPTION – более полное и подробное описание, которое может помочь, например, через длительный промежуток времени выяснить, что это за резервная копия и зачем она была создана.

Для полного восстановления базы данных выполните следующую команду:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.BAK’ WITH RECOVERY, REPLACE

WITH RECOVERY предписывает SQL Server отменить все незавершенные транзакции, которые могли быть в журнале транзакций, и оставить базу в рабочем состоянии. REPLACE означает перезапись любого существующего файла с тем же именем. Более подробно об этом рассказано во врезке «Замена базы данных».

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

BACKUP LOG AdventureWorks WITH TRUNCATE_ONLY

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

Полное резервирование с сохранением журнала

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

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

Если не указано обратное, после завершения резервирования журнала неактивные записи в нем «удаляются» (в действительности они помечаются для перезаписи). При запуске команды BACKUP LOG вы можете добавить параметры NO_TRUNCATE или COPY_ONLY, чтобы при резервировании записи в журнале не изменялись. Но мы не рекомендуем использовать эти параметры, если только вы не знаете наверняка, для чего это может понадобиться.

SQL Server 2005 имеется режим резервирования копии заключительного фрагмента журнала (tail-log backup), то есть резервирование после краха базы данных в том случае, если журнал транзакций не был испорчен. В этом режиме осуществляется резервирование последних транзакций, выполненных с момента последнего резервирования журнала. Более подробно об этом режиме рассказано во врезке «Что такое резервные копии заключительного фрагмента журнала».

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

Если в базе данных массовые обновления носят регулярный характер, возможно, имеет смысл использовать модель восстановления с неполным протоколированием (bulk logged recovery). Поскольку отдельные записи, включенные в массовую операцию в этом случае не журналируются, этот подход сокращает накладные расходы на ведение журнала SQL Server. Хотя вы можете получить заметное увеличение производительности при выполнении массовых операций, вы рискуете потерять данные при восстановлении, если исходные данные для повторного выполнения массовых операций окажутся в момент восстановления недоступны. При применении простой модели восстановления резервирование журнала также невозможно, так как в этом случае происходит обрезание журнала до контрольной точки.

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

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’ WITH INIT, NAME = ‘AdventureWorks Full Db backup’, DESCRIPTION = ‘AdventureWorks Full Database Backup’

А затем следует выполнить резервирование журнала с помощью команды:

BACKUP LOG AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak’ WITH NOINIT, NAME = ‘AdventureWorks Translog backup’, DESCRIPTION = ‘AdventureWorks Transaction Log Backup’, NOFORMAT

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

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

1. Если база данных в состоянии онлайн, ограничьте доступ к ней, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Таким образом доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
2. Исправьте ошибку, вызвавшую крушение базы данных.
3. Если возможно, примените все сохраненные в резервных копиях журналы транзакций с параметром NORECOVERY.

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

BACKUP LOG AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak’ WITH NORECOVER

Для полного восстановления из полной резервной копии необходимо сначала восстановить файлы базы данных с помощью команды:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’ WITH NORECOVERY

Параметр NORECOVERY сообщает SQL Server, что частичные транзакции должны быть оставлены как есть, не нужно пытаться отменить их. При последующем восстановлении журналов транзакций будут восстановлены данные, позволяющие завершить эти частичные транзакции. При использовании параметра NORECOVERY база данных остается в нерабочем состоянии. Сразу за полным восстановлением должны быть восстановлены все резервные копии журналов транзакций с параметром NORECOVERY, как показано ниже:

RESTORE LOG AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak’ WITH NORECOVERY

Наконец, выполните восстановление заключительного фрагмента с параметром RECOVERY:

RESTORE LOG AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak’ WITH RECOVERY

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

Полное плюс разностное резервирование

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

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

Рисунок 3. Расписание заданий на разностное резервирование

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

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak’ WITH INIT, DIFFERENTIAL, NAME = ‘AdventureWorks Diff Db backup’, DESCRIPTION = ‘AdventureWorks Differential Database Backup’

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

1. Если база данных в состоянии онлайн, ограничьте к ней доступ, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Тем самым доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
2. Выполните резервирование заключительного фрагмента журнала.
3. Исправьте ошибку, вызвавшую сбой базы данных.
4. Выполните восстановление полной резервной копии с параметром NORECOVERY.
5. Выполните восстановление последней имеющейся разностной резервной копии с параметром NORECOVERY.
6. Выполните восстановление резервной копии заключительного фрагмента журнала с параметром RECOVERY.

Для восстановления разностной резервной копии (выполняется после восстановления полной копии) введите команду:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak’WITH NORECOVERY

Затем восстановите заключительный фрагмент журнала с параметром RECOVERY, с помощью приведенной ранее команды.

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

Комбинирование стратегией

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

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

Альтернативные стратегии резервирования

Резервирование в SQL Server не сводится только к полному, разностному и журналу транзакций. Более сложные стратегии, включающие резервирование файлов или групп файлов, стратегию частичного резервирования и резервирование только путем копирования.

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

Резервирование базы SQL Server является онлайн-процессом, все хранящиеся в SQL Server данные во время операции резервирования доступны. Операции изменения базы данных, предложения INSERT, UPDATE и DELETE доступны точно так же, как выборка данных (SELECT). Во время резервирования нельзя изменять структуру базы данных или файловую структуру – предложения ALTER DATABASE, ADD FILE или SHRINKFILE во время резервирования выполняться не могут. Если для базы данных включен режим автоматического запуска уменьшения файла базы данных (auto-shrink), возможен конфликт во время выполнения резервирования. Так, если в процессе выполнения резервирования запустится автоматическое уменьшение файла базы, то обе операции могут завершиться отказом. Та операция, которая стартует раньше, установит блокировку файла, а следующей операции придется ожидать снятия блокировки. Если первая операция снимет блокировку, то начнется выполнение второй. Если же произойдет тайм-аут блокировки первой операции, вторая операция завершится отказом. Такой подход может показаться неправильным с точки зрения исполнения второй операции, которая вынуждена ожидать отказа, и только после него выдаст отказ. Но если учесть, что работа второй операции зависит от успеха первой, если при выполнении первой операции произошел отказ, выполнение второй не имеет смысла. Для предотвращения такой проблемы следует отключать автоматическое уменьшение файла базы данных перед выполнением резервирования.

В большинстве случаев восстановление базы SQL Server является автономной операцией, во время которой доступ пользователей к базе невозможен. При использовании SQL Server 2005 Enterprise Edition с моделью полного восстановления частичное восстановление и восстановление неосновных групп файлов по умолчанию являются онлайн-операциями. Части базы данных, которые не должны восстанавливаться, например группы файлов с доступом только для записи, могут быть доступны пользователям на всем протяжении выполнения операции восстановления. Группы файлов для чтения/записи доступны, если они не были переведены в автономное состояние для восстановления. Эта возможность очень полезна для больших баз данных, работающих в режиме 24x7x365. Дополнительную информацию можно найти в документации SQL Server 2005 BOL, «Performing Online Restores» (http://msdn.microsoft.com/ru-ru/library/ms188671.aspx), а также во врезке «Почему восстановление базы данных не может выполняться онлайн».

Подведем итоги

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

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

Резервирование баз данных доступно ограниченному кругу лиц. По умолчанию разрешение дается членам определенных групп системных администраторов серверов и ролям базы данных db_owner и db_backupoperator. При использовании устройств резервирования, дисков или лент необходимо обращать внимание на то, кто является владельцем и какие установлены разрешения. SQL Server должен иметь возможность чтения и записи на устройство. Если учетная запись, от имени которой работает SQL Server, не обладает правами доступа к устройству, вы узнаете об этом только в случае сбоя при выполнении операций резервирования или восстановления. Хранимая процедура sp_addumpdevice, выполняющая добавление записи об устройстве резервирования в системные таблицы, не выполняет проверку прав доступа на уровне файлов.

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

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

Настройка модели восстановления определяет, какая часть данных может быть восстановлена в случае краха базы данных. Для каждой базы данных можно установить собственную модель восстановления в зависимости от того, какую потерю данных вы готовы допустить. Чтобы установить модель восстановления базы данных с помощью SQL Server Management Studio (SSMS), щелкните правой кнопкой нужную базу данных, откройте окно свойств Properties, перейдите на страницу Options и выберите нужную модель резервирования из выпадающего списка.

Существует три типа моделей восстановления: полное, простое и с неполным журналированием (full, simple, и bulk-logged). Полная модель восстановления наиболее использует все возможности журнала транзакций и позволяет восстановить базу данных с высокой степенью точности на заданный момент времени. Все операции, такие как транзакции данных, структурные изменения базы данных, операционные инструкции типа завершения транзакции или отмена, большие объекты и массовые операции, сохраняются в журнале. Журнал транзакций пополняется до тех пор, пока не будет выполнено резервирование журнала транзакций.

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

Модель восстановления с неполным журналированием занимает промежуточное положение между «крайними» моделями полного и простого восстановления. Хотя название bulk-logged может навести на мысль о журналировании массовых операций, в действительности они сохраняются в журнале лишь частично. Во время массовых операций, которые часто заключаются в добавлении большого числа записей за короткий промежуток времени, SQL Server устанавливает на каждом затронутом обновлением экстенте базы данных битовый флажок, но на самом деле вставленные записи не добавляются в файл журнала. Во время последующего резервирования журнала транзакций SQL Server проверяет этот флажок и записывает в резервную копию журнала транзакций сами экстенты базы данных, которые были изменены массовой операцией в добавление к обычным записям о вставке и удалении. Таким образом, резервная копия журнала в модели восстановления с неполным журналированием содержит результаты выполнения массовых операций, а не действительно выполненные отдельные транзакции.

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

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

Стандартные команды для резервирования

В SQL Server 2005 и SQL Server 2000 имеются две команды для выполнения, в сущности, одного и того же действия – DUMP и BACKUP (то есть DUMP DATABASE или BACKUP DATABASE и DUMP LOG или BACKUP LOG). Команда DUMP сохранилась со времен SQL Server 6.5, когда резервирование базы данных означало просто копирование базы данных в состоянии на момент перед началом операции резервирования. При этом изменения в базе данных, которые могли произойти после начала резервирования, не попадали в резервную копию.

Начиная с версии 7 SQL Server может выполнять настоящее «динамическое» резервирование, а это означает, что изменения, внесенные после начала процесса резервирования, записываются в журнал транзакций и сохраняются в файле резервной копии. Таким образом, резервная копия представляет собой «снимок» базы данных на момент завершения операции резервирования. Команда DUMP сохраняется для обратной совместимости, но Microsoft не рекомендует ее использовать в новых разрабатываемых системах. Когда-нибудь эта команда будет исключена, и разработчикам придется избавиться от нее в тех фрагментах программного кода, где она еще используется.

Тем, кто всегда тщательно следил за резервированием баз данных SQL Server и стремился изучать нововведения SQL Server 2005, следует продолжать внимательно следить за резервными копиями: в SQL Server 2005 нет привычной команды DBCC REPAIR. «Заменой» для этой команды служит DROP DATABASE.

Замена базы данных

При восстановлении базы данных на новом сервере используйте параметр REPLACE, который отключает обычные проверки безопасности и позволяет перезаписывать существующие базы данных, даже если их имя отличается от имени восстанавливаемой базы. Например, предположим, что была сделана резервная копия базы данных D, расположенной на сервере A. Эта резервная копия должна быть восстановлена на сервере B. Сначала на сервере B следует создать пустую промежуточную базу, при этом имя и размер базы не имеют никакого значения. Далее, надо восстановить базу D с параметром REPLACE на сервере B поверх только что созданной промежуточной базы. Если же восстановление должно быть произведено обратно на сервер A, на прежнее место, параметр REPLACE указывать не требуется. По умолчанию операция восстановления базы данных выполняет встроенные проверки безопасности, например если в нормальной ситуации нельзя выполнить восстановление базы поверх другой существующей базы данных. Аналогично, запрещено восстановление базы данных, зарезервированной в режиме полного резервирования или резервирования с журналированием массовых операций, если отсутствует резервная копия заключительного фрагмента журнала.

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

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

Резервирование заключительного фрагмента журнала – новый режим резервирования в SQL Server 2005. В этом режиме в резервную копию дописываются записи журнала транзакций, которые добавлялись с момента последнего резервирования файла журнала. Когда вы пытаетесь восстановить базу данных на момент отказа, перед началом восстановления выполните резервирование заключительного фрагмента. Резервирование последнего не нужно делать в том случае, если вы собираетесь восстановить базу данных по состоянию на момент до последнего резервирования журнала транзакций, или переносите базу данных с одного экземпляра сервера на другой, либо перезаписываете базу данных. Возможна ситуация, когда журнал транзакций поврежден – в этом случае выполнить резервирование заключительного фрагмента невозможно, и восстановление придется выполнять без него.

Как восстановить базу данных по состоянию на заданный момент времени

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

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

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

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

При восстановлении базы данных по состоянию на некоторый момент времени выполните полное резервирование с установкой NORECOVERY, как показано ниже:

RESTORE DATABASE AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak" WITH NORECOVERY

Затем примените все резервные копии журналов с установкой RECOVERY и указанием даты и времени требуемой точки во времени в каждом предложении RESTORE LOG:

RESTORE LOG AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak" WITH RECOVERY, STOPAT = ‘ Dec 10, 2007 8:10 PM’

Резервирование файлов/групп файлов

Эта стратегия резервирования подходит только в том случае, если база данных состоит из нескольких файлов или групп файлов. Если размеры базы или требования к производительности делают полное резервирование базы данных невозможным и если необходимо быстрое восстановление в случае отказа, стоит принять во внимание стратегии резервирования файлов/групп файлов.
Эта стратегия может использоваться для SQL Server 2005 или SQL Server 2000, при этом при выполнении каждой операции требуется указать, какие файлы, группы файлов или комбинации будут резервироваться. При этом следует выполнить полное резервирование базы данных вскоре после создания, после чего выполнять регулярное резервирование файлов или групп файлов. Если для конкретной базы данных необходимо задействовать простую модель восстановления, все доступные для чтения/записи файлы и группы файлов должны резервироваться одновременно. Для минимизации потерь данных при восстановлении выбирайте модель полного восстановления или модель восстановления с неполным протоколированием, при этом необходимо включить в стратегию резервирование журнала транзакций.
Восстановление базы все равно означает ограничение доступа к базе данных, но на меньшее время, чем при полном восстановлении базы данных. Во время восстановления доступ ограничивается только к группам файлов, восстанавливаемым в данный момент.
В худшем случае, если требуется восстановление всей базы данных и вы используете модель полного восстановления, потребуются все резервные копии журналов транзакций с момента создания базы данных. Кроме того, если необходимо восстановление базы на определенный момент времени, потребуется полный набор резервных копий журналов транзакций.

Частичное восстановление

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

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

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

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

Восстановление после частичного резервирования все равно подразумевает ограничение доступа к базе данных, но на меньший интервал времени, чем при полном восстановлении базы данных – и только для первичной группы файлов, групп для чтения/записи и групп только для чтения, которые были частью резервирования. Более подробную информацию можно найти в документации SQL Server 2005 Books Online «Частичные резервные копии» http://msdn.microsoft.com/ru-ru/library/ms191539.aspx.

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

Иногда возникает потребность выполнить резервирование для решения специальных задач, например чтобы создать презентацию для демонстрации клиенту. При этом вы не хотите, чтобы был нарушен нормальный порядок файлов, необходимых для восстановления базы данных. В этом случае можно воспользоваться возможностью создания резервной копии состояния базы данных. Такая копия может быть создана вне зависимости от того, какая стратегия восстановления базы будет использована – полная, массового копирования или простая (bulk-copy, или simple).

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

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

При резервировании журнала транзакций состояния базы данных журнал транзакций не обрезается, в отличие от обычного резервирования. Резервирование состояния также не оказывает влияния на цепочку журналов, которая используется для полного резервирования с журналом восстановления. Резервные копии состояния вообще не включаются в список резервных копий журналов при восстановлении. Более подробные сведения можно найти в документации SQL Server 2005 BOL «Резервные копии состояния» по адресу http://msdn.microsoft.com/ru-ru/library/ms191495.aspx.

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

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

Процесс восстановления обычно начинается с копирования данных, журналов и индексных страниц с резервного носителя на место файлов базы данных. Затем наступает черед фазы повторного исполнения – применения сохраненных в журнале транзакций к данным, сохраненным на момент резервирования базы; этот процесс часто называют «повторять изменения». Эти зафиксированные в журнале транзакции представляют собой изменения в базе данных, которые были выполнены после последнего резервирования базы перед сбоем. Сначала SQL Server копирует данные и структурные изменения в журнал транзакций, а затем выполняет эти изменения на реальной базе данных. Повторение изменений обеспечивает применение к базе данных изменений, которые были сделаны в журнале.

На этой стадии в базе данных обычно содержатся незавершенные транзакции, и база данных не может использоваться для доступа. Далее для SQL Server 2005 Standard Edition наступает фаза последней отмены, в ходе которой выполняется отмена всех незавершенных транзакций. После завершения этой фазы база данных полностью восстановлена и готова к работе. Редакция Enterprise Edition работает немного по другому – база данных готова к использованию сразу после повторения изменений, не дожидаясь фазы отмены незавершенных транзакций.

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

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

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

Основные принципы

1. Регулярность и частота

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

Раздельность

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

Перепроверка

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

Различение

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

Зачастую программы резервного копирования делают так называемые «образы» (image). Они выглядят как один единственный файл. Так вот в каждый такой образ лучше сохранять различные данные.

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

Резервное копирование данных

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

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

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

Куда делать backup

1. Внешний жесткий диск. Часто можно купить прямо в коробке. Бывают ноутбучные - такие диски маленькие по размеру, но более дорогие. Обычные жесткие диски можно сравнительно дешево купить объемом в 2 Тб - тогда за место на диске долго не придётся беспокоиться.

Достаточно надежный (если не ронять и не трясти чрезмерно)
+ Относительно недорогой

Необходимо самому не забывать подключать диск для бэкапа
-Не очень удобно переносить (не относится к ноутбучным дискам)

2. USB-stick - подойдет как дополнительное средство, когда данные хотелось бы переносить с одного компьютера на другой и/или иметь под рукой. Так же если сами данные не хочется хранить на компьютере.
Есть одно большое но - у флешки ограничено число записей, так что если на ней хранить данные приложения, которое будет интенсивно записывать, то флешка (usb stick) довольно быстро прикажет долго жить. К тому же, по моему личному впечатлению, они достаточно часто ломаются. Мой знакомый, покупая самые дорогие флешки, которые позиционировались как «не убиваемые», получал сломанную флешку за месяц-другой. Справедливости ради, надо сказать что у меня до сих пор ни одна флешка не сломалась, некоторые работают уже лет 5. Тем не менее, только на одном только usb-stick`e я бы хранить данные не стала.

Мобильное хранение
+Занимает мало места
+Очень дешево

Непредсказуемая надежность

3. Хранение данных на удаленном сервере (или в облаке).

Есть свои плюсы и минусы:

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

Желательно шифровать данные, так как неизвестно кто к ним может получить доступ
-Тратится большой объем трафика (если он ограничен, то возникают проблемы)
-Зачастую бесплатно можно хранить только данные до 2 Гб. Так что, такой backup - это дополнительная статья расходов

Список с хорошим описанием сервисов можно найти

Чем делать backup

Приведу список приложений, на которые стоит обратить внимание (по моему мнению), при резервном копировании на жесткий диск.

Из бесплатных пользуются популярностью

1. Genie Backup Manager - очень удобная программа, но немного тормозит при работе
2. Handy Backup - простой интерфейс, работает быстро.

Дополнительно

Часто в настройках программ по backup есть опция - сделать инкрементальный или дифференциальный backup. Практическое различие довольно простое. При дифференциальном резервном копировании можно сэкономить на месте которое он занимает. Зато есть только две возможности восстановления: данные в том состоянии, когда был сделан полный backup + данные на тот момент, когда был сделан дифференциальный.

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