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

Программы и восстановления данных: целесообразность использования

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

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

Основной принцип работы и варианты функционирования

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

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

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

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

«Родная» программа для резервного копирования Windows

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

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

Получить доступ к этой утилите проще всего можно из стандартной "Панели управления", где выбирается раздел резервного копирования и восстановления. Здесь можно использовать три основных пункта: создание образа, создание диска и настройку копирования. Первый и второй сложностей не вызывают. Зато третий достаточно интересен. Система предложит сохранить копию на съемном носителе, предварительно определив само устройство. Но если посмотреть на параметры, можно сохранить копию и в сети, что прекрасно подойдет для «локалок». Так что в некоторых случаях такая программа для резервного копирования системы станет неплохим средством для создания бэкапа с возможностью последующего восстановления Windows именно из этой копии.

Самые популярные утилиты

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

• Acronis True Image.
• Norton Ghost.
• Back2zip.
• Comodo BackUp.
• Backup4all.
• ABC Backup Pro.
• Active Backup Expert Pro.
• ApBackUP.
• File Backup Watcher Free.
• The Copier.
• Auto Backup и многие другие.

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

Acronis True Image

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

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

Вот что интересно: утилита показывает достаточно высокие показатели по скорости создания бэкап-копии, времени, сжатию. Так, например, на сжатие данных порядка 20 Гб понадобится в среднем 8-9 минут, а размер конечной копии составить чуть более 8 Гб.

Norton Ghost

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

Данная утилита примечательна тем, что с ее помощью можно создать на винчестере скрытый раздел, где будет храниться копия (причем из нее можно восстановить и данные, и систему). Кроме того, в ней можно изменять множество параметров: тип контроль считывания, тип записи, сжатие, число точек для одновременного доступа и т. д. Что же касается производительности, те же 20 Гб приложение сжимает до размера чуть более 7,5 Гб, что по времени занимает около 9 минут. В общем, результат довольно неплохой.

Back2zip

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

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

Comodo BackUp

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

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

Backup4all

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

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

Решения для серверных систем

Для серверных систем и сетей также имеются специализированные программы резервного копирования. Среди всего этого многообразия можно выбелить три самых мощных:

• Symantec Backup Exec 11d System Recovery.
• Yosemite Backup Standard Master Server.
• Shadow Protect Small Business Server Edition.

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

Вместо послесловия

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

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

Лучшая программа для резервного копирования

Я предложу Вам надежную, быструю и простую утилиту, которая бесплатно обеспечит Вас требуемым функционалом для работы с жесткими дисками и их разделами - Paragon Домашний Эксперт 12 . Отлично подходит для всех пользователей, даже с минимальным опытом работы на ПК и легко ответит на вопрос «Как сделать бэкап системного диска и файлов? «, а также восстановит данные, если вы что-то удалили или внесли некорректные изменения.

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

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

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

Как настроить бэкап на компьютере

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

Потом отметьте галочками следующие пункты: «Локальный диск С «, «Начальный трек жесткого диска » и «Главная загрузочная запись «.

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

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

Как сделать аварийный диск

Вот и завершилось создание резервной копии системы . Теперь нам нужно создать аварийный диск . Снова переходим к главному меню программы и выбираем пункт «Защита и восстановление данных l Создание аварийного диска» .

Нажмите «Далее» . В следующем окне укажите предпочитаемый загрузочный носитель. Доступны для выбора: флеш или CD/DVD. Если создание аварийного загрузочного диска производится для нетбуков, то выберите 1 вариант. Снова нажмите «Далее» .

Чтобы сделать загрузочную флешку , выберите 1 пункт - стандартный образ аварийного диска, поставляемый с программой. Нажмите «Далее» и укажите USВ-накопитель и опять «Далее» для начала процесса записи аварийного диска. Аналогичные действия и для загрузочного диска CD или DVD.

Как пользоваться загрузочной флешкой или диском

Мы записали аварийный загрузочный диск или флешку. Теперь, чтобы воспользоваться ими, например, восстановить загрузочный раздел Windows, вставьте оптический диск в привод или флешку в USB порт необходимого ПК. Загрузите компьютер, загрузив BIOS (как правило, клавиша «DEL» ) и укажите в настройках в качестве первого устройства для загрузки системы оптический привод или USВ-накопитель (CD-ROM или USB-HDD).

Сохраните настройки (найдите пункт со словами Save и Exit). Компьютер перезапустится и произойдет загрузка с флешки или оптического носителя. Теперь выберите в меню запуска программы режим «Normаl mode» (для корректной работы с мышью). Программа Домашний эксперт 12 проанализирует ПК на наличие подключенных к нему носителей информации. В результате откроется меню инструментов вашего аварийного диска. Выберите пункт «Мастер восстановления архивных копий» , дважды кликнув. Жмем «Далее» . В следующем окне кликните по кнопке, расположенной справа от поля «Выбрать файл образа» . Откроется новое окно со списком носителей на ПК. Выберите жесткий диск с архивными копиями. Нажмите «Далее» и найдите на выбранном жестком диске необходимый файл бэкапа. Снова жмите «Далее» для запуска процесса восстановления системного диска . Дождитесь окончания процесса и перезагрузите ПК, вынув аварийную флешку или диск.

Как восстановить операционную систему. Некорректная работа после восстановления

Допустим, что Windows запускается, но работает с ошибками. Вам понадобится восстановить системные файлы . Снова достаем аварийный USB диск или CD\DVD. Запускаем его в режиме «Normal Mode» . Выбираете в меню пункт «Восстановление загрузки Windows «, дважды кликнув. В появившемся
окне отметьте пункт «Поиск установленных копий Windows» и нажмите «Далее» . Выберите жесткий диск с ОС и кликните по кнопке «Далее» . Теперь подтвердите готовность к замене загрузочной записи и нажмите кнопку «Готово» , тем самым запуская процесс восстановления системных файлов.
Если Windows перестала запускаться, то для восстановления операционной системы выберите пункт «Изменить Master Boot Record (МВR — главная загрузочная запись)» . Доведите процесс до завершения и выньте аварийный диск из привода или извлеките флешку из USB порта. 3апустите ОС с жесткого диска и вы снова готовы к работе.

Восстановление данных. Восстановление операционной системы

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

Как восстановить файлы

Перейдите к главному окну утилиты и нажмите на кнопку «3ащита и восстановление данных» , затем .

В следующем появившемся окне укажите архив жесткого диска, нажмите на значок «+» , тем самым вы раскроете список каталогов.

Выберите необходимую папку или файл для восстановления и нажмите «Далее». Затем выберите путь для восстановления файлов , указав сохранить или удалить старую копию. Снова жмите «Далее» и «Готово» после восстановления данных.

Вам также будут полезны следующие материалы.

Традиционно, пользователи 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). Если этого не сделать, то наступят очень неприятные последствия.

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

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

Самый распространенный случай у пользователей — выход из строя операционной системы. Для того, чтобы восстановить прежнее состояние компьютера (программы, настройки и т.д.), необходимо потратить от нескольких часов до нескольких дней для инсталляции и настройки ОС 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. Благодаря ему вы сможете конвертировать образ реального жесткого диска, например системного раздела, и затем открыть его вместе со всеми данными и программами в виртуальной машине даже на другом компьютере.

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

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

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

В 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.