Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1441 сообщений
Cообщения с меткой

восстановление данных - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

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

Пятница, 19 Мая 2017 г. 11:06 (ссылка)





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



Что может быть не так с файлом бэкапа



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



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



Неконсистентный бэкап. Такое может случится, когда выбрали неподходящее средство резервного копирования. Например, на виртуальной машине работает база данных, для бэкапа которой администратор решил использовать резервное копирование ВМ без поддержки целостности приложения (application aware backup).

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

При использовании специальных агентов резервного копирования такого не произойдет.



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



Зачем тестировать



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



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

Так что если рассматривать весь путь восстановления “от двери до двери”, то скорее всего RTO получится больше, чем просто “чистая” скорость восстановления данных.



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

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



Как тестируем



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

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



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


  • сбой аппаратуры: отказал диск, сервер с исходной информацией;

  • программный сбой: неудачное обновление, вирус;

  • человеческий фактор: администратор удалил нужный файл.





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

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



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



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



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

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



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



На всякий случай: тестируем восстановление в отдельной песочнице, не рискуя продуктивом.



И еще: интересно, как часто вы тестируете восстановление из бэкапа, и делаете ли это вообще?




И еще: интересно, как часто вы тестируете восстановление из бэкапа, и делаете ли это вообще?






































Никто ещё не голосовал. Воздержавшихся нет.





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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/329046/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как система управления инженерными данными спасает файлы от уничтожения криптовирусами

Среда, 17 Мая 2017 г. 19:20 (ссылка)

Может ли Pilot-ICE спасти данные от вирусов-шифровальщиков? Чтобы ответить на этот вопрос, мы провели экспериментальное заражение нашумевшим вирусом Wana Decrypt0r 2.0 изолированной тестовой системы, на которой запущен сервер Pilot-Server и клиент Pilot-ICE. Другие криптовирусы действуют по схожему принципу, отличается только способ заражения. Рассматриваем самый экстремальный случай, когда резервной копии нет.







Рассказывает Дмитрий Поскребышев — руководитель отдела разработки систем управления инженерными данными.

Читать дальше →

https://habrahabr.ru/post/328898/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Следует ли покупать память ECC?

Четверг, 11 Мая 2017 г. 19:36 (ссылка)

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




  • В Google не использовали ECC, когда собирали свои серверы в 1999 году.

  • Большинство ошибок ОЗУ — это ошибки систематические, а не случайные.

  • Ошибки ОЗУ возникают редко, потому что аппаратное обеспечение улучшилось.

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





Давайте рассмотрим эти аргументы один за другим:

Читать дальше →

https://habrahabr.ru/post/328370/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Новая версия HPE Recovery Management Central 4.0 доступна для скачивания

Среда, 10 Мая 2017 г. 10:42 (ссылка)

Новая версия HPE Recovery Management Central (RMC) 4.0 доступна для скачивания через официальный сайт Hewlett Packard Enterprise. Не знаете, что такое RMC? Это программное обеспечение, объединяющее две (а теперь уже три) платформы систем хранения HPE в единую структуру, позволяющую не только эффективно обрабатывать транзакции и хранить оперативные данные (3PAR и StoreVirtual VSA), но и обеспечивать их резервное копирование и восстановление (StoreOnce). Подробнее об обновлении – под катом.

image
Читать дальше →

https://habrahabr.ru/post/328060/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA

Среда, 10 Мая 2017 г. 09:02 (ссылка)

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

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


  • RPO (recovery point objective) – допустимая потеря данных. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) защиту своих данных от потери выше приемлемого уровня.

  • RTO (recovery time objective) – допустимое время восстановления данных Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.



Часто эта пара показателей отображается в виде одномерного графика вдоль оси времени.

Но в таком одномерном графике нет самого главного, на что ориентируется бизнес – денег! О том, как рассчитывать RTO и RPO, исходя из требований бизнеса, я расскажу под катом.





Читать дальше →

https://habrahabr.ru/post/328068/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Восстановление данных из поврежденного массива RAID 5 в NAS под управлением Linux

Суббота, 06 Мая 2017 г. 15:57 (ссылка)

Обычный будний день в одной организации перестал быть обычным после того, как несколько десятков человек не смогли продолжать свою деятельность, так как замерли все привычные процессы. Прекратила свою работу CRM, перестала откликаться база менеджеров, аналогичная картина была с бухгалтерскими базами. На системного администратора обрушился шквал звонков пользователей с сообщениями о проблемах и требованиями срочного вмешательства. Системный администратор, который сравнительно недавно начал карьеру в этой компании, попытался подключиться к NAS и обнаружил, что устройство не откликается. После отключения питания и повторного включения NAS вернулся к жизни, но запуска виртуальных машин не произошло. Для пользователей оказалось доступным только общее хранилище файлов. Анализ проблем системным администратором показал, что один из двух RAID массивов не содержит томов и является чистым неразмеченным пространством. Какими были дальнейшие действия системного администратора, история умалчивает, но достаточно быстро он осознал, что у него нет четкого плана действий по восстановлению данных и рабочей среды компании. На данном этапе шесть накопителей на жестких магнитных дисках (2 HDD – 3 TB HDS5C3030ALA630, 4 HDD – 4 TB WD4000FYYZ-01UL1B1) из этого NAS поступают в наше распоряжение. В техническом задании нам предлагается «восстановить таблицу разделов».





Читать дальше →

https://habrahabr.ru/post/328134/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Восстановление файлов после трояна-шифровальщика

Суббота, 29 Апреля 2017 г. 16:26 (ссылка)

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





рис. 1



Последующие попытки запуска рабочей среды 1С также не увенчались успехом. Бухгалтер связалась с компанией, обслуживающей вычислительную технику их организации, и запросила техническую поддержку. Специалистами обслуживающей организации выяснено, что проблемы куда более масштабные, так как кроме того что файлы базы 1С Бухгалтерии 7.7 были зашифрованы и имели расширение “BLOCKED“, зашифрованными оказались и файлы с расширениями doc, docx, xls, xlsx, zip, rar, 1cd и другие. Также обнаруживался текстовый файл на рабочем столе пользователя, в котором сообщалось, что файлы зашифрованы с использованием алгоритма RSA 2048, и что для получения дешифратора необходимо оплатить услуги вымогателя. Резервное копировании 1С баз осуществлялось ежедневно на другой жесткий диск установленный в этом же ПК в виде создания zip архива с папкой 1С баз, и копия архива помещалась на сетевой диск (NAS). Так как ограничения доступа к резервным копиям не было, то вредоносное программное обеспечение имело доступ и к ним.



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



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



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



Поэтому сразу приступаем к анализу файлов, структуры которых хорошо известны. В данном случае удобно использовать для анализа DBF файлы из базы 1С, так как структура их весьма предсказуема. Возьмем файл 1SENTRY.DBF.BLOCKED (журнал бухгалтерских проводок), размер данного файла 53 044 658 байт





рис. 2



Рассматривая шифрованный DBF файл, обращаем внимание на то, что первые 0x35 байт не зашифрованы, так как присутствует заголовок, характерный для данного типа файлов, и наблюдаем часть описания первого поля записи. Произведем расчет размера файла. Для этого возьмем: WORD по смещению 0x08, содержимое которого равно 0x04C1 (в нем указан размер заголовка DBF файла), WORD по смещению 0x0A, содержимое которого равно 0x0130 (в нем указан размер одной записи в базе), DWORD по смещению 0x04, содержимое которого равно 0x0002A995 (количество записей), и 0x01 – размер конечного маркера. Решим пример: 0x0130*0x0002A995+0x04C1+1=0x0032965B2 (53 044 658) байт. Размер файла, согласно записи файловой системы, соответствует расчетному на основании информации в заголовке DBF файла. Выполним аналогичные проверки для нескольких DBF файлов и удостоверимся, что размер файла не был изменен вредоносным ПО.



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





рис. 3



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



Начиная со смещения 0x00132CB5 обнаруживаем отсутствие признаков шифрования до конца файла, выполнив проверки в иных крупных файлах подтверждаем предположение, что целиком шифруются только файлы менее 0x00132CB5 (1 256 629) байт. Многие авторы вредоносного ПО выполняют частичное шифрование файлов с целью сокращения времени искажения пользовательских данных. Руководствуются вероятно тем, чтобы их вредоносный код за минимальное время нанес максимально возможный ущерб пользователю.

Приступим к анализу алгоритма шифрования





рис. 4



На рис. 4 на месте заголовков полей DBF файла присутствуют почти одинаковые последовательности из 16 байт (смещения 0x50, 0x70, 0x90), также видим частичное повторение последовательностей из 16 байт (смещения 0x40,0x60,0x80), в которых есть отличия только в байтах, где должно прописываться имя поля и тип поля.



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

Исходя из особенностей строения заголовков DBF файлов и изменений байт в последовательностях, можно сделать предположение, что шифрование выполнено посредством XOR операции над данными с неким паттерном. Также можно сделать предположение, исходя из длины повторяющихся последовательностей, что длина паттерна 16 байт (128 бит). Заголовок базы равен 0x04C1 байт, размер описания одного поля в заголовке 0х20 (32) байт. Из этого следует, что заголовок данного DBF файла содержит (0x4C1-0x21)/0x20=0x25 (37) описаний полей. На рис. 4 подчеркнуты красным фрагменты записей двух полей начиная со смещения 0x10, которые в случае 1С как правило имеют нулевые значения, кроме самого 0x10 (так как по этому смещению указывается размер поля), на основании этого можно полагать, что уже имеем 15 из 16 байт ключа шифрования 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xXX 0xAF 0x45 0x6A 0xB7.



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





рис. 5



На рисунке 5 обратим внимание на нулевой столбец, точнее на его нешифрованную часть, и видим, что там преобладает значение 0x20 (код пробела согласно ASCII таблицы). Соответственно, и в шифрованной части столбца будет преобладать некое одинаковое значение. Легко заметить, что это 0xFA. Для получения оригинального значения недостающего байта ключа необходимо выполнить 0xFA xor 0x20=0xDA.



Подставив полученное значение на недостающую позицию, получим полный ключ 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xDA 0xAF 0x45 0x6A 0xB7.

После выполнения процедуры xor операции с полученным ключом над шифрованными участками получили оригинальное содержимое файла





рис. 6



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



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



Наряду с подобными простыми случаями встречаются трояны-шифровальщики, которые действительно будут использовать современные криптографические алгоритмы и в случае их атаки подобное простое решение в принципе невозможно. Посему будьте предельно осторожны при открытии любых файлов, полученных по электронной почте даже от доверенных источников. Регулярно обновляйте антивирусное ПО и делайте резервное копирование таким образом, чтобы ваши данные во всех копиях не были доступны кому-либо единовременно.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/327618/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Восстановление 1С базы после форматирования

Среда, 26 Апреля 2017 г. 13:04 (ссылка)

Люди в погоне за комфортными для них условиями работы зачастую не задумываются о безопасности и сохранности своих данных и рано или поздно сталкиваются с вопросами их утраты. Рассмотрим обращение клиента с USB Flash 2Gb Transcend. Со слов клиента, в один из дней при установке накопителя в USB порт компьютера было предложено ее отформатировать. Как утверждает клиент, он отказался от этого и обратился за помощью к системному администратору. Системный администратор, обнаружив, что при подключении USB накопителя «подвешивается» компьютер, не придумал ничего лучшего, чем согласиться с предложением операционной системы отформатировать его (никогда этого не делайте!). Далее системный администратор использовал популярную программу автоматического восстановления R-Studio. Результат ее работы в виде безымянных папок был скопирован клиенту на другой накопитель. При просмотре результата клиент обнаружил, что около четверти файлов не могут быть открыты и, что хуже всего, 1С Бухгалтерия 7.7 отказывалась запускаться с восстановленной базой, ссылаясь на отсутствие файлов.





рис. 1



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





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



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

Открываем LBA 0 (0x0 в файле образе) и проверяем там наличие таблицы разделов, либо наличие Boot сектора файловой системы.





рис. 2



В нашем случае видим по смещению 0x1C2 типа раздела 0x0B, означающее, что на данный момент на USB накопителе есть раздел FAT32, который начинается с 0x80 сектора (DWORD по смещению 0x1C6), длиной 0x003C2000 секторов (DWORD по смещению 0x1CA). Переходим к boot сектору описанного раздела в сектор 0x80 (в файле образа байтах 0x10000)





рис. 3



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

Для этого нам нужны следующие параметры, описанные в boot секторе (будут указаны в виде смещения от начала сектора): размер сектора по смещению 0x0B — 0x200 (512 байт), количество секторов в кластере по смещению 0x0D — 0x08, размер кластера получается посредством перемножения размера сектора на количество секторов в кластере 0x08*0x0200=0x1000 (4096 байт), количество зарезервированных секторов до первой копии таблиц FAT — по смещению 0x0E=0x01FE (510 секторов), количество копий FAT — по смещению 0x10=0x02, размер одной копии FAT — по смещению 0x24=00000F01 (3841 секторов). Используя полученные параметры, произведем расчет положения начала области данных: 0x10000+0x01FE*200+0x00000F01*2*200=0x410000 (8320 сектор). Небольшой подвох от создателей FAT32 заключается в том, что на данный момент мы рассчитали начало области данных для раздела FAT32, но оно не является нулевой точкой отсчета, так как первые две записи в FAT таблице зарезервированы и не используются по прямому назначению, в связи с чем нулевой точкой принимается начало области данных за минусом 2 кластеров. В данном случае это будет 0x410000-0x1000*2=0x40E000 (8318 сектор)

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





Рис. 4



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

Далее необходимо оценить корневой каталог на предмет удаленных записей. Позиция первого кластера корневого каталога указывается в boot сектор по смещению 0x2C=0x00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.





рис. 5



По адресу, рассчитанному выше, мы видим корневую директорию (корневой каталог), в которой содержится единственная 32-байтная запись. По смещению 0x0B мы видим значение 0x08, которое указывает на тип записи – метка тома. Тот факт, что таблицы размещения файлов заполнены нулями, и в корневом каталоге нет намека на какие-либо иные записи, говорит о том, что данный раздел был отформатирован.



Для проверки предположения о том, что раздел не пересоздавался и все параметры файловой системы корректны, необходимо произвести поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20 (данное выражение признак начала директории FAT32).





рис. 6



При нахождении регулярного выражения необходимо удостовериться, что это действительно директория, по иным признакам, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом директории. Согласно информации на рис. 6, можно сказать, что данная директория начиналась с 3 кластера (номер текущего кластера директории DWORD содержится в WORD по смещению 0x1A (младшая часть) и WORD по смещению 0x14 (старшая часть)) и описывалась в корневом каталоге, так как по смещениям 0x3A и 0x34 содержатся нули (начальный кластер родительской директории). Проверим, соответствует ли номер кластера данной директории нулевой точке отсчета файловой системы, созданной после форматирования. Для этого номер кластера директории умножим на размер текущего кластера и прибавим к нулевой точке 0x03*0x1000+0x40E000=0x411000. Как видим, расчетный адрес соответствует фактическому нахождению. Установить имя данной директории возможно только в случае, если ранее корневой каталог состоял более, чем из одного кластера, и ссылка на данную директорию была не в первом кластере, так как содержимое первого кластера при форматировании было полностью уничтожено вместе с таблицами размещения файлов.



Далее продолжим поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20.





рис. 7



Повторяем все проверки: 0x04*0x1000+0x40E000=0x412000. Снова видим соответствие положения директории параметрам текущей файловой системы. Но, кроме этого, видим, что есть номер кластера родительской директории 0x03, что говорит о том, что данная директория была вложенной, и взглянув на рис. 6, можно установить имя директории, которая изображена на рис. 7. Итак, согласно рис. 6, по смещению 0x4B видим значение 0x10 — это означает, что данная запись указывает на директорию, а по смещениям 0x5A и 0x54 число 0x00000004 – указатель на 4-й кластер. По смещению 0x40 – имя директории «BIN». Именно таким образом устанавливается взаимосвязь директорий в поврежденном FAT разделе. После выполнения еще некоторого числа проверок директорий в разных участках образа можно сделать окончательный вывод о том, что на данном накопителе состоялось форматирование в границах предшествующей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей, то есть дальнейшие аналитические операции нужно проводить в рамках раздела, описанного в таблице разделов с учетом параметров текущей файловой системы.



Зная, что 1С база, состоящая из DBF файлов, должна содержать файл конфигурации 1CV7.MD, выполним поиск последовательности 0x31 0x43 0x56 0x37 0x20 0x20 0x20 0x20 0x4D 0x44. Для того, чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять в рамках 32-байтных блоков с нулевым смещением.





Рис. 8



Таким образом, находим все директории, содержащие в себе указатель на файл 1CV7.MD. В нашем случае обнаружилась только одна такая директория, что позволяет предполагать, что мы нашли первый кластер необходимой директории. Далее следует анализ положения родительских директорий, вплоть до корневой директории. Каждая найденная директория прописывается в таблицу FAT (сначала как директория из одного кластера, посредством записи FF FF FF 0F для соответствующего элемента таблицы). Также в корневой директории прописывается ссылка на дочерний объект.



На текущем этапе мы выполним копирование найденных файлов с предположением об их непрерывности, так как обе копии FAT не содержат информации о фрагментации (напомним, что они были безвозвратно уничтожены системным администратором в результате необдуманного форматирования USB flash). После копирования директории 1С базы анализируем количество файлов. Учитывая, что фрагмент директории был размером в один кластер, то извлекли мы не более 126 файлов, что явно намного меньше, чем должно быть в директории с DBF и CDX файлами, относящимися к 1С базе. Примерно такой же результат выдадут программы автоматического восстановления, о чем свидетельствует результат, полученный системным администратором посредством использования R-Studio.



Среди извлеченных файлов есть 1CV7.MD (файл конфигурации) и 1СV7.DD (файл словаря данных). После выполнения проверки целостности создадим у себя на диске временную папку, куда поместим 1CV7.MD. Укажем данный путь при добавлении новой базы и откроем конфигуратор, посредством которого создадим чистую базу на основании этой конфигурации. Сравним сформированный DD файл с восстановленным, если описания и количество справочников идентичны, то никаких дополнительных действий не требуется, и, имея полный список файлов, можно приступать к поиску остальных фрагментов директории 1С базы. Для этого необходимо осуществить поиск последовательностей из ASCII кодов символов, используемых в именах недостающих DBF файлов. По мере обнаружения фрагментов директории дописывать в таблицу размещения файлов продолжение цепочки. После каждой операции дополнения цепочки директории выполнять копирование файлов и анализировать, насколько сократилась количество недостающих DBF файлов, и вновь формировать последовательность ASCII кодов символов для поиска следующего фрагмента.





рис. 9



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

В данном случае выполнив поиск 5 последовательностей удалось найти все остальные фрагменты директории с базой 1С.



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



Основной метод контроля целостности DBF файла – это проверка информации, содержащейся в служебном заголовке и соответствует ли содержимое файла описанию в заголовке.





рис. 10



Первоначально проводится оценка заголовка: проверяется его длина, указанная по смещению 0x08, приводит ли указанное в нем смещение на конечный маркер 0x0D. Записи полей базы, начиная со смещения 0x20, описываются 32-байтовыми записями, в которых по смещению 0x00 следует имя поля, по смещению 0x0B тип поля, по смещению 0x10 – размер поля. Сумма размеров полей +1 (один дополнительный байт для каждой записи в базе является статусом записи в DBF) должна равняться содержимому по смещению 0x0A (размер одной записи в базе). На рисунке DBF файлы мы видим следующие длины полей: 0x09+0x10+0x10+0x10+0x10+0x10+0x01=0x5A. Проведем проверку корректности размера файла. Для этого выполняем умножение количества записей, которое указано в заголовке по смещению 0x04 на размер одной записи в базе по смещению 0x0A с последующим сложением с содержимым по смещению 0x08. 0x00000003*0x005A+0xE1=0x01EF. По полученному смещению должен находиться маркер окончания файла 0x1A.

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





рис. 11



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



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





Рис. 12



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



Необходимо проверить целостность каждого DBF файла, коих в одной 1С базе несколько сотен. По прохождении всех проверок и сборов фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятия.





рис. 13



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



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/327414/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

VHD Native Boot снаружи и внутри

Вторник, 25 Апреля 2017 г. 10:19 (ссылка)

Цель настоящей статьи — рассказать о моем опыте работы с весьма полезной и не слишком хорошо известной функцией Windows, которая называется VHD Native Boot, то есть способности загружаться с виртуального жесткого диска формата VHD/VHDx.

Начиная с 7-й версии, в Windows появилась возможность создавать виртуальные диски VHD/VHDx (далее просто VHD), а также подсоединять и отсоединять их через графический интерфейс «Управление дисками» и утилиту командной строки diskpart. Кроме этого, Windows научилась с таких дисков загружаться, и все бы ничего, но этот самый Native Boot был доступен только обладателям старших версий, то есть от Pro и выше. Очевидно, что это было лишь маркетинговое ограничение, потому что с появлением Windows 10, а я проверял Anniversary Update (1607) и Creators Update (1703), никаких ограничений больше нет. Это работает и в Windows 10 Home, причем она может выступать как в роли хоста, так и в роли гостя. О том, как это выглядит и как это можно использовать вы узнаете ниже.

С давних пор меня интересовала идея использования виртуализации применительно к рабочему компьютеру, внутренней виртуализации, если так можно выразиться. Как полезны и удобны виртуальные машины для разработчиков-программистов, специалистов по безопасности, тестированию. А вот до уровня домашнего/рабочего компьютера и его операционной системы это дело все никак не доходило. Ну, очевидно же, что если операционная система — такой сложный и чувствительный компонент, нельзя огульно доверять ее пользователю, он ее так и норовит чем-нибудь заразить или повредить. Да, есть резервное копирование и восстановление из точек восстановления (то есть из теневой копии), и это отличные вещи. Но это весьма чувствительные к ошибкам компоненты, и могут не спасти, кроме того, многие зловреды умеют удалять теневые копии, не оставляя пользователю шанса. Хотелось бы что-то простое и банальное на уровне copy-paste, чтобы «упавшую» или «испортившуюся» систему вернуть в рабочее состояние в течение нескольких минут. Конечно, идеально было бы, чтобы решение было в самой системе, просто заложено в ней. Hyper-V все же не совсем то, хотя может быть его и допилят до требуемого уровня. Ведь хочется, чтобы все возможности машины, все ее железо, вся мощь были доступны, с минимальными жертвами.

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

Когда есть несколько (немного) типов компьютеров, достаточно установить систему и все требуемое ПО на VHD, а потом просто скопировать этот файл на все аналогичные компьютеры, сведя работы на местах к минимуму. Неплохо было бы иметь некую оболочку, без загрузки Windows, что-то типа «консоли гипервизора», позволяющую попадать в нее и работать с VHD на уровне файлов, копировать, заменять, обновлять и т.д. Тем более, что сама Windows такую оболочку в своем составе имеет, и называется она Windows Recovery Environment, далее WinRE. Давайте посмотрим, как все это выглядит на практике.



1. Установка Windows на VHD с нуля



Эта тема широко освещена в Сети, существуют десятки толковых руководств (см. ссылки в конце статьи), поэтому я остановлюсь лишь вскользь, попутно рассматривая возможные варианты.

В целом все сводится к нажатию волшебной комбинации Shift-F10 в момент, когда компьютер загрузился с установочного диска. Параллельно открывается окошко командной строки, где следует, используя diskpart, отформатировать и разметить реальный жесткий диск (если компьютер/диск новый) и создать VHD требуемого объема. Для простоты я буду рассматривать установку 64-разрядной версии и жесткие диски с MBR.

Итак, жесткий диск разбит, папка VHDs на соответствующем томе создана, теперь в diskpart надо создать виртуальный жесткий в этой папке, дав ему понятное имя, и выполнить присоединение, тогда тому виртуального диска будет присвоена очередная буква. Теперь можно вернуться в окно установки Windows и выбрать именно эту букву для установки. Всё, дальше программа установки все сделает сама. В том числе и добавит нужную запись в файл BCD.

Сразу скажу, что использовать bcdedit мне показалось уж слишком жестоким самоистязанием, поэтому я позволил себе использование одного стороннего инструмента для манипуляций, это утилита Bootice соответствующей разрядности. Предположим, он у вас есть на том же установочном диске. Если нет, в дальнейшем я покажу, как его можно «закинуть» в нашу оболочку «гипервизора».

Итак, для демонстрации пусть у меня есть один жесткий диск 25 Gb (я воспользуюсь любимым Virtualbox для показа), в нем один раздел, там папка VHDs, где я создал виртуальный диск, а на него установил Windows 10.



image



Вот так будет выглядеть меню загрузки системы в Bootice (раздел BCD, Easy Mode)



image



Здесь 25 Gb C: это тот «физический» диск, на котором я создал виртуальный размером 20 Gb и куда установил Windows 10. Все прекрасно, но дальше нам нужно создать оболочку для управления. Как известно, WinRE всегда устанавливается вместе с Windows и приходит на помощь тогда, когда обнаруживаются проблемы с загрузкой. Нам же она нужна для другой цели, я хочу попадать туда для работы с VHD-файлами. Добавим пункт WinRE в меню загрузки. Для этого в Bootice воспользуемся Professional Mode, последний объект в списке слева это как раз Windows Recovery, справа видно его расположение на VHD:



image



Этот объект, вернее, ссылку на него, надо добавить в список меню загрузки, выберем вверху слева ветвь Windows Boot Manager, в правой панели выберем пункт Display Order и добавим пункт про WinRE из выпадающего списка:



image



Теперь пункт Windows Recovery Environment будет показываться в загрузочном меню системы, в чем мы можем убедиться, вернувшись в Easy Mode:



image



Осталось перезагрузиться и выбрать второй пункт, начнется загрузка WinRE, а там нас интересует только пункт Поиск и устранение неисправностей, Дополнительные параметры, Командная строка. Все это напоминает и программу установки Windows, и прародителя WinRE, широко известную Windows Preinstallation Environment. Отсюда, собственно, и начинается работа с оболочкой, и не так важно, какую именно вы выберете, поскольку там все приблизительно одно и то же.

Наш основной жесткий диск оказывается в ней диском C:, в его папке VHDs обнаруживается наш master.vhd, и мы можем спокойно его куда-нибудь скопировать. В WinRE волшебной командой мы подключаем сеть:

wpeutil initializenetwork


автоматически выбирается и запускается драйвер сетевого адаптера, получается ip-адрес от сервера DHCP, и мы можем работать с сетью. В Virtualbox я могу подключить сетевую папку такой командой:

net use z: \\10.0.2.2\d$


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

Помимо Bootice легко добавляются Far Manager, 7-zip, а с ними уже как-то повеселее. Мне удалось найти даже работающий веб-браузер Palemoon Portable, а уж с ним загрузить из Сети необходимые компоненты совсем легко. Прекрасно установился cygwin64, что открывает путь для ssh/rsync в смешанных средах. Дальше понятно, у нас есть возможность спокойно архивировать и копировать файлы vhd. Если что-то не так в master.vhd, мы загружаемся в WinRE и забираем его резервную копию из сетевого хранилища, затем выходим из WinRE и получаем нашу систему обратно.

Прямо из оболочки WinRE при помощи diskpart или Bootice можно создать новый VHD диск, запустить программу установки Windows, если хочется добавить какую-то иную версию и установить эту новую Windows на новый VHD, нужный пункт в меню загрузки ОС добавится сам.

Осталось только подстраховаться на тот случай, если с master.vhd все настолько плохо, что и в оболочку WinRE не загрузишься, ведь она часть этого диска. Конечно, это не смертельно, всегда можно загрузиться с установочного диска Windows и нажать Shift-F10, но приложив определенные усилия, можно сделать так, чтобы WinRE находилась на нашем хост-диске, и грузиться в нее оттуда. Загрузочное меню будет выглядеть так:



image



2. Установка Windows на VHD на работающем компьютере



Не представляет никакой проблемы добавить на имеющемся компьютере дополнительную операционную систему, создав новый VHD и присоединив его, а затем запустив программу установки и выбрав букву, назначенную для присоединенного диска. Намного более сложной задачей будет перенос текущей конфигурации, уже установленной на физическом диске системы на диск виртуальный. Здесь приходит на ум несколько вариантов. Первый, о котором я вспомнил, это использовать Windows Backup, ведь он как раз создает файл VHD (vhdx) в режиме создания образа системы. Казалось бы, всё, что требуется — это добавить ссылку на такой VHD в меню загрузки и посмотреть, что выйдет. Так я и сделал, при первой загрузке Windows выдала ошибку, а при всех последующих старательно что-то загружалось, очень долго, и даже промелькивало окошко с картинкой экрана блокировки первоначальной системы, но так и исчезало опять. Не знаю почему, но с VHD-диска, полученного из backup'а, Windows загрузить не удается. Пришлось идти иным путем, воспользоваться Disk2vhd из комплекта Sysinternals.

Все довольно просто, выбираешь раздел физического диска, или весь диск, и Disk2vhd делает из него VHD-файл:



image



Но дальше начинаются неудобства. Получившийся VHD, какого бы он ни был реального размера, сообщает о себе, что он размером с весь наш физический диск. То есть если у меня был физический диск 180 Gb, а я выбрал только первый раздел размером 100 Gb, VHD-файл получился около 50 Gb, но сообщает он о себе как о 180-гигабайтном. Проблема здесь в том, что если с такого VHD загрузиться, то Windows потребует 180 Гб места для его работы. То есть как его ни оптимизируй (defrag, sdelete -z), как ни сжимай (compact vdisk, shrink), от первоначальных характеристик, снятых Disk2vhd никак не избавиться. Пришлось пойти на сложное преобразование, создать пустой VHD, загрузить в Virtualbox PartedMagic, подсунув тому преобразованный и пустой VHD и при помощи Gparted (и Clonezilla, если не хочется возится с bootrec) перенести раздел. В результате получился VHD 20 Gb, с которого я сейчас и пишу данную статью.



3. Использование дифференциальных VHD



В особо ненадежных средах, на публичных компьютерах или при проведении каких-то опасных экспериментов, может пригодится возможность использования дифференциальных VHD-дисков, на которых записывается только разница, изменившаяся информация, а оригинальный VHD остается без изменений. Ясно, что для начала надо уже иметь работающую систему на VHD-диске, а потом добавить вариант с дифференциальным диском. Создать такой диск можно в diskpart или все в том же Bootice. Пусть master.vhd наш основной диск, создадим для него дифференциальный child.vhd, нажав кнопку Create:



image



Теперь нужно добавить/исправить в BCD пункт, отвечающий за загрузку с VHD, указав вместо master.vhd дифференциальный child.vhd

Для этого воспользуемся Professional Mode в Bootice, сделаем копию имеющегося пункта Windows 10 (правая кнопка мыши, Duplicate this entry) и переименуем новый в Windows 10 Child VHD. Теперь в этом пункте исправим ApplicationDevice и OsDevice, изменив имя vhd-файла:



image



Всё, теперь нужный пункт добавлен в загрузочное меню. Если выбрать Windows 10 Child VHD, Windows запустится и с этого момента будет все изменения записывать в child.vhd. Следует учесть, что под child.vhd в момент загрузки будет зарезервировано столько же места, сколько указано в master.vhd, то есть в нашем случае 20 Gb, пусть его реальный размер в сотни раз меньше. Время от времени имеет смысл выполнять процедуру слияния (merge), то есть отправлять накопленную разницу из child в master, чтобы ничего не потерять. Дело в том, что стоит вам загрузиться не в child, а в master или даже WinRE на основе master.vhd, то связь между master и child будет нарушена, придется чинить child, но Bootice и это умеет:



image



4. Рекомендуемая конфигурация физического диска при работе с загрузочными VHD



Я бы предложил разметить физический диск следующим образом.

Один раздел, достаточно большой, оставить под хранение файлов VHD, тут все зависит от того, сколько разных VHD вам понадобится. Минимально для установки Windows x64 требуется 20 Гб, можно создавать динамические диски, то есть увеличивающие свой реальный размер только по мере их внутреннего наполнения. Но еще раз подчеркну, в момент загрузки динамического VHD Windows резервирует под него место в соответствии с указанным максимальным размером.

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

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

А скрыть раздел можно при помощи вот такого нехитрого сценария для diskpart, с учетом выбранного диска и раздела для хранения VHD

sel disk 0
sel part 1
set id=17


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

А чтобы вернуть ларчик назад, достаточно в diskpart выполнить команду

set id=07
или

set id=27




Список полезных ссылок:



msdn.microsoft.com/ru-ru/windows/hardware/commercialize/manufacture/desktop/understanding-virtual-hard-disks-with-native-boot

msdn.microsoft.com/ru-ru/windows/hardware/commercialize/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference

gotch.techfaq.ru/archives/91

gotch.techfaq.ru/archives/115

winitpro.ru/index.php/2017/01/27/vosstanovlenie-sredy-windows-recovery-environment-winre-v-windows-10

technet.microsoft.com/ru-ru/library/cc766465(v=ws.10).aspx



Спасибо за внимание
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/327308/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<восстановление данных - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda