Пользователи хранят на Айфонах огромное количество информации, потеря которой крайне нежелательна. Поэтому резервное копирование – это операция, которая должна войти в привычку. Зная, как восстановить iPhone из резервной копии, можно быстро вернуть утраченные данные, независимо от того, что стало причиной их удаления. Разберем два способа возврата данных, чтобы вы понимали, какой метод вам будет удобнее применять.

Способы восстановления

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

• Через iTunes.
• Через хранилище iCloud.

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

Восстановление в iTunes

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

Подключите iPhone к ПК и зайдите в iTunes. Перейдите на основную страницу устройства и проверьте раздел «Резервные копии». Отыщите параметр «Автоматическое создание копий» – если выбран пункт «Этот компьютер», то можно восстановить информацию с жесткого диска через iTunes. Если выбрано значение «iCloud», то возвращать данные придется из облачного хранилища – об этом подробно рассказано ниже.

Рассмотрим порядок восстановления информации из копии, которая хранилась на жестком диске. Телефон уже подключен к ПК. Что делать дальше:

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

Главное не забывать делать резервные копии, тогда никаких сложностей как потери важных сообщений и контактов не возникнет.

Восстановление через iCloud

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

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

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

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

При активации (язык, регион, установление подключения к беспроводной сети) выберите режим «Восстановить из iCloud». Для авторизации в iCloud напишите пароль от Apple ID.

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

Традиционно, пользователи 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 автоматически сохраняет в составе точки восстановления. Предыдущие версии иногда называют теневыми копиями. Для операционной системы Windows XP функция восстановления предыдущих версий файлов недоступна. Для остальных операционных систем семейства Windows набор действий для восстановлений будет различен:

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если 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 из бэкапа на другой компьютер с использованием программных средств Acronis. И для адаптации операционной системы под новое железо применили . В этой статье снова будем говорить о переносе операционной системы на другой ПК или ноутбук, и снова о технологии Universal Restore, но только уже от другой компании-разработчика - AOMEI. Итак, как сохранить наработанную систему при «переезде» на другое железо? Ниже с помощью средств AOMEI Backupper создадим бэкап текущей Windows, развернём его на другом компьютере и применим технологию Universal Restore.

О технологии

AOMEI Universal Restore – это технология, суть которой заключается в отвязке драйверов комплектующих на этапе восстановления Windows. Разработана для случаев:

Развёртывания системы на множестве корпоративных устройств;

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

Переноса рабочей системы – с настройками, программами, профилем и личными данными - на другой компьютер.

Universal Restore от AOMEI проще своего аналога от компании Acronis. Тогда как последняя являет собой механизм установки драйверов новых комплектующих, Universal Restore от AOMEI только обеспечивает сброс драйверов восстановленной из резервной копии операционной системы. И Виндовс, по идее, сама должна установить всё, что ей нужно, при первом запуске. Технология какого разработчика лучше? В большинстве случаев можно обойтись и применением упрощённой Universal Restore от AOMEI. Но у технологии от Acronis всё же больше шансов запустить восстановленную из неродного бэкапа систему в отдельных случаях. Благодаря тому, что Acronis Universal Restore может внедрять драйверы до запуска Windows, её можно переносить между устройствами с разными контроллерами жёстких дисков. А, как известно, драйверы при смене таких контроллеров система ещё не научилась менять без переустановки.

• Примечание: друзья, ни технология Universal Restore от AOMEI, ни таковая от Acronis, ни штатная утилита отвязки Виндовс от железа Sysprep не помогут, если операционную систему нужно перенести с MBR-диска на GPT-диск и наоборот. Поскольку этот вопрос лежит в области разметки дискового пространства и затрагивает аспекты загрузки системы.

AOMEI Universal Restore доступна в платных выпусках AOMEI Backupper – Professional, Server и Technician.

https://www.backup-utility.com/downloads.html

Но, друзья, для использования Universal Restore триалки не годятся, потребуется полнофункциональная редакция одного из этих выпусков. Я буду работать с AOMEI Backupper Professional. Кстати, русифицировать программу можно . Внутри AOMEI Backupper Professional мы создадим загрузочный носитель. И с его участием будем осуществлять поставленные в статье задачи.

Создание загрузочного носителя

Идём в раздел программы «Утилиты». Кликаем пункт «Создание загрузочного носителя».

Выбираем среду WinPE.

Выбираем тип носителя в зависимости от режима BIOS – UEFI или обычный.

Выбираем, каким образом нужно создать носитель – записать на оптический диск, на флешку или сохранить в образ ISO. Здесь, друзья, обратите внимание, можно добавить в состав ПО носителя драйверы, например, для портов USB 3.0 или для сети, если для хранения резервной копии вы используете сетевое хранилище.

Резервное копирование на исходном компьютере

Бэкапить Windows на исходном компьютере можно как с использованием установленной программы AOMEI Backupper, так и с загрузочного носителя. Но последний способ занимает чуть меньше по времени из-за полной отдачи скоростного потенциала записи данных жёсткими дисками процессу бэкапа. Что же, приступим. Подсоединяем к исходному компьютеру, с которого нужно перенести Windows, вместительную флешку, USB-HDD, прочего типа накопитель. Если и исходным, и целевым компьютером является сборка ПК, бэкап можно сохранить на внутреннем жёстком диске первого. А дальше на время восстановления бэкапа подсоединить этот жёсткий диск ко второму, целевому компьютеру. Друзья, кто не знает, как подключать внутренние жёсткие диски ПК, смотрите эту статью.

Загружаем исходный компьютер с носителя AOMEI Backupper, если выбран способ резервного копирования с его участием. Создаём новый бэкап.

Кликаем «Резервное копирование системы».

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

Запускаем создание бэкапа.

Восстановление Windows на целевом компьютере

Подтверждаем догадки AOMEI, что выбрана резервная копия операционной системы.