Восстановление файла без $MFT

druoleg · 23.04.2019, 19:19

Добрый день!
В одном из регионов нашей необъятной случилась ситуация при которой:
1. сервер с бекапами не выполнял свою функцию;
2. RAID-контроллер (9361-8i) подвергся воздействию "квалифицированных" специалистов (навтыкали вместо участников массива дисков из других массивов - по логам контроллера видно, что запускалась переиниализация);
3. тип RAID и состав дисков не известен, ФС развалена.
Осталось админов сжечь, тогда можно сказать, что вообще ничего не существовало.

Я не специалист по восстановлению данных, вывезти диски за пределы серверной не представляется возможным (не спрашивайте почему), поэтому копаем HEX в Read-only. Все попытки совместить диски, найти разделы, $MFT, файлы оказались безуспешны.
В ходе раскопок был выявлен начальный сектор mdf-файла (MS SQL база), из которого удалось извлечь примерно 70% информации. Как я понимаю, остальная конфигурация находится в других секторах, список которых хранится в $MFT.
Есть надежда, что $MFT был убит не полностью и мы сможем прочитать информацию по данному файлу. Но поиски пока ни к чему не привели.
Я понимаю, что это нетривиальная задача, но возможно кто-то сможет подсказать направление раскопок. Возможно, имеются иные признаки или ссылки между блоками секторов одного файла?

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

9285 · 23.04.2019, 19:39

Чем уже проводились поиски? Поиск проводился на каждом потенциальном участнике массива?

druoleg · 23.04.2019, 20:05

Икали DMDE, R-Studio, WinHex и проч.

Судя по всему $MFT таблица потеряна окончательно. Нашел только пару записей FILE0, и те созданы при попытке восстановления загрузчика "женскими докторами".

Опытным путем посмотрел на тестовом стенде хранение данных в $MFT на примере БД в 10 ГБ. Она состоит из двух кластеров, в начале каждого находится запись "INDX(" (49 4E 44 58 28 00).
Копаю в этом направлении. Надеюсь, верном.

9285 · 23.04.2019, 20:30

Что касается собственно вопроса, то без его записи можно восстановить по результату сигнатурного поиска, но если файл фрагментирован, то восстановится лишь первый фрагмент.
Но это если нет записей вообще, хотя не факт что это так - это я исходу из того, что (судя по сообщению с другого места) поиск производился по начальной сигнатуре файловой записи. Но в случае каких то сбоев бывают различные ситуации, в том числе такие, при которых файловая запись смещается на несколько байтов, или бывает вкрапление мусорных байтов.
Если же какие то записи всё таки найдены, то хоть и суперничтожный, но шанс имеется. Это относится к сильнофрагментным файлам; причём таким, которые подвергались дефрагментации штатными средствами винды. В этом случае запись о размещении файла находится в нескольких записях и если даже нет начальной, то можно найти остальные (главное знать номер родительской записи). В случае недефрагментированного файла здесь можно уповать лишь на то, что потеряна лишь начальная запись, в которой хранятся данные только первого фрагмента и именно его уже нашли. Если же дефрагментация делалась, но тут может образоваться квазиконструкция при которой файл будет записан практически одним фрагментом, но при этом иметь кучу записей, в каждой из которых будет запись об одном фрагменте. Это связано с тем, что виндовый дефрагментатор не может избавится от расширенного атрибута.
Ну и всё это, конечно же, актуально для файла расположенного на определяемом адресном пространстве - типа одного физического диска или собранного массива.
PS. Кстати, в другом месте тебе написали про "чудоторящий" DE и что с ним никто рядом не стоял. Спору нет, программа уникальная, но она сама ничего не сделает. Да и есть не факт что нужны суперспособности - а случаи когда та же R-studio находила участников массива тоже имеются.
PS. ответ написан до появления твоего сообщения и уже не буду менять его а добавлю следующее.
В DMDE смотрел результаты поиска не открытием тома а просмотром записей MFT, причём с включением и мелких?
Лог хотя бы одного поиска имеется?

Добавлено через 1 минуту

Цитата (druoleg) »

в начале каждого находится запись "INDX(" (49 4E 44 58 28 00)

Аналогичная запись имеется у индексов каталогов.

Добавлено через 8 минут

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

Добавлено через 13 минут

Цитата (druoleg) »

посмотрел на тестовом стенде хранение данных в $MFT на примере БД в 10 ГБ.

База рабочая? Если да, то посмотри её файловую запись на предмет фрагментации и если таковая имеется, то какие приращения (размеры фрагментов) фиксированные или нет.

druoleg · 26.04.2019, 12:35

Спасибо за помощь.
Данные восстановить не удалось. Но удалось выяснить, что перед поломкой RAID отработал DiscCrypt (злоумышленникам привет).
Очень качественный провал.

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

**Smirnoff** · 26.04.2019, 16:20

Цитата (druoleg) »

Очень качественный провал.

По совокупности вообще тянет на epic fail.

Цитата (druoleg) »

Осталось админов сжечь, тогда

Всячески одобряю.

9285 · 26.04.2019, 17:56

Цитата (Smirnoff) »

Всячески одобряю.

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

geran · 27.04.2019, 09:37

А что за тип рейда?
У меня бывало терялись данные и обычные программы для восстановления не доставали ничего кроме картинок. Но для дисков Seagate есть прога достающая всё вообще и без потерь. Seagate_FILE_RECOVERY_v2.0
рекомендуется. Работает на ура только с дисками Seagate.

**garniv** · 27.04.2019, 09:40

Цитата (geran) »

А что за тип рейда?

Выше было же:

Цитата (druoleg) »

3. тип RAID и состав дисков не известен

9285 · 27.04.2019, 10:21

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

geran · 27.04.2019, 13:20

Цитата (9285) »

Не стоит давать столь громогласные заявления

Да ну что Вы.. я тихонечко.

Цитата

Один из примеров подобного - то что переформатирование помогает восстановлению данных.

Да это как получится. Конечно в первую очередь надо без переформатирования. Но если не выходит я доставал некоторые огрызки и много картинок после форматирования. А что? Физически ведь данные не стираются.

9285 · 27.04.2019, 13:34

geran
Это никак не получится. Надо просто пользоваться нормальным ПО и всё возможное восстановится. А формат физически удаляет некоторый обьём данных - тут всё зависит от конкретной ситуации. Из более менее свежего - на хоботе был случай, когда кроме формата пострадавший ещё и переразметил диск в другом стиле, плюс ещё яндекс диск успел кое-что переписать. Как результат - примерно 170 тысяч записей MFT унеслись в нирвану.

geran · 27.04.2019, 14:02

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

9285 · 27.04.2019, 14:11

geran
А смысл если она динамично изменяется?
Или если произошли какие то деструкции при том же изменении размера раздела и часть даже свежих записей имеет неактуальные сведения? Бэкапить надо сами данные.
Ну а если всё таки хочется забэкапить MFT то это можно сделать в дисковых редакторах - в том же DMDE, в "папке" Metadata он есть целиком (не считая списков расширенных атрибутов).

Добавлено через 7 минут

Расположение записи и её фрагментация зависит от используемого форматера.
Воздействие последующего формата тоже зависит от него же.
При этом не стоит забывать что кроме перезаписи какой то части записей MFT перезаписывается, как минимум, поляна двух крупных метафайлов - $LogFile и $Bitmap. Первый занимает примерно 64 мега - и вот если он попадёт на бывший фрагмент MFT, то накроется 64 тысячи записи. Или не попадёт на записи MFT а на те же однокластерные файлы - прикинь сколько их уничтожится.
PS. Дело не в языке, а в том что надо знать хотя бы базовые моменты и то, что многое зависит от конкретной ситуации (как в случае используемых форматеров).

**Smirnoff** · 30.04.2019, 10:32

Цитата (9285) »

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

Скупердяев - сколько угодно; но ты внимательно читал 1-й пост данного топика?

Цитата (druoleg) »

1. сервер с бекапами не выполнял свою функцию;

Это - конкретный косяк админа. И никакие "хозяева-скупердяи" тут не при делах...
Про пп 2. и 3. - даже говорить бессмысленно; что толку обсуждать ушлёпков, возомнивших себя админами?

Цитата (geran) »

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

Беда в том, что нет (да и не будет никогда) такой программы для восстановления данных, чтобы там была лишь кнопка "сделать мне хорошо!". Когда пользуешься такими программами - нужно очень хорошо понимать, что именно ты делаешь и как оно вообще устроено. А вот это "как устроено" описать младенческим лепетом ну никак не получается...

9285 · 30.04.2019, 13:20

Smirnoff

СПОЙЛЕР »

Я читаю внимательно, в том числе и в других местах (*), к тому же знаю что не всегда стоит верить написанному.

Полугодовой бэкап то есть - а за полгода мало ли что сменилось. В том числе могли старых админов сократить а нанять таких, которые за миску супа не могут разобраться. Не, в "жирные" годы я бы согласился с тобой, но сейчас есть немало примеров когда и вполне серьёзные организации начинают экономить (в том числе на IT).
(*) Цитата с другого места (осзона)
Руководство не мое, я тут в роли "спасителя" после "женских докторов".
Для нашей организации это репутационные потери (хотя мы 3 года не допускались к этим серверам теми же безопасниками и уже спасали их 3 года назад после шифровальщика на том же сервере), а для заказчика кадровые.
Не хочется чтобы автор темы воспринял написанное в свой адрес (тем более что в жизни был случай когда я тоже "затыкал пробоину"), но если речь идёт о репутационных потерях, то почему не посылают человека понимающего типа того, что написано выше про MFT, а по большому счёту - спеца, в том числе со своим оборудованием (те же писи3000 есть и внешние), который может от имени фирмы поработать на месте? Дорого? А как же репутация?

**Smirnoff** · 30.04.2019, 16:56

СПОЙЛЕР »

Цитата (9285) »

почему не посылают человека понимающего

Да потому и не посылают, что

Цитата (9285) »

мы 3 года не допускались к этим серверам теми же безопасниками

А уж когда допустили - там всё было уже сделано...

9285 · 30.04.2019, 19:34

Smirnoff

СПОЙЛЕР »

Причём здесь безопасники и клиентские тараканы?
Ну да, админы-кАзлы и всё уже случилось. но если всё так серьёзно, то почему не посылается человек, который не будет спрашивать на форумах (не такие уж и сложные) вопросы? Тем более если речь идёт о репутационных "прибылях"?

**Smirnoff** · 02.05.2019, 13:03

СПОЙЛЕР »

Цитата (9285) »

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

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

9285 · 02.05.2019, 21:36

Smirnoff

СПОЙЛЕР »

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

26.04.2019, 16:20	[включить плавающее окно] #6
Smirnoff Модератор Регистрация: 30.12.2004 Адрес: Новосибирск	Цитата (druoleg) » Очень качественный провал. По совокупности вообще тянет на epic fail. Цитата (druoleg) » Осталось админов сжечь, тогда Всячески одобряю. __________________ С уважением, Олег Р. Смирнов

27.04.2019, 09:40	[включить плавающее окно] #9
garniv Модератор Регистрация: 29.06.2004	Цитата (geran) » А что за тип рейда? Выше было же: Цитата (druoleg) » 3. тип RAID и состав дисков не известен __________________ Хочешь помочь новичку — делай вместе с ним. Хочешь помочь старику — делай вместо него. Хочешь помочь мастеру — отойди и не мешай. А хочешь помочь Таргитаю — сам Таргитай.

27.04.2019, 14:02	[включить плавающее окно] #13
geran Общительный Регистрация: 31.10.2003 Адрес: Москва / GPON 100мбит	Да, всё плохо. А вот как забекапить MFT я так и не нашел. Я читал что запись MFT присутствует не ровно в самом начале а где-то со смещением и тогда вероятность перезаписи ее при быстром форматировании очень мала. Длинные файлы конечно не удасться восстановить а размером с кластер или последовательно ряд кластеров в одном файле это вполне. по моему Кабы не писали матерьялы по этому вопросу эзоповым языком то и всем было бы легче. Последний раз редактировалось geran; 27.04.2019 в 14:07.

30.04.2019, 10:32	[включить плавающее окно] #15
Smirnoff Модератор Регистрация: 30.12.2004 Адрес: Новосибирск	Цитата (9285) » Во всех остальных случаях виновником является хозяин-скупердыяй. Ты же вроде сам админишь. Неужели до сих пор не сталкивался с таковыми? Скупердяев - сколько угодно; но ты внимательно читал 1-й пост данного топика? Цитата (druoleg) » 1. сервер с бекапами не выполнял свою функцию; Это - конкретный косяк админа. И никакие "хозяева-скупердяи" тут не при делах... Про пп 2. и 3. - даже говорить бессмысленно; что толку обсуждать ушлёпков, возомнивших себя админами? Цитата (geran) » Кабы не писали матерьялы по этому вопросу эзоповым языком то и всем было бы легче. Беда в том, что нет (да и не будет никогда) такой программы для восстановления данных, чтобы там была лишь кнопка "сделать мне хорошо!". Когда пользуешься такими программами - нужно очень хорошо понимать, что именно ты делаешь и как оно вообще устроено. А вот это "как устроено" описать младенческим лепетом ну никак не получается... __________________ С уважением, Олег Р. Смирнов

30.04.2019, 16:56	[включить плавающее окно] #17
Smirnoff Модератор Регистрация: 30.12.2004 Адрес: Новосибирск	СПОЙЛЕР » Цитата (9285) » почему не посылают человека понимающего Да потому и не посылают, что Цитата (9285) » мы 3 года не допускались к этим серверам теми же безопасниками А уж когда допустили - там всё было уже сделано... __________________ С уважением, Олег Р. Смирнов

23.04.2019, 19:39	[включить плавающее окно] #2
9285 Опытный Регистрация: 08.02.2019	Чем уже проводились поиски? Поиск проводился на каждом потенциальном участнике массива?

23.04.2019, 20:05	[включить плавающее окно] #3
druoleg Новенький Автор темы Регистрация: 23.04.2019	Икали DMDE, R-Studio, WinHex и проч. Судя по всему $MFT таблица потеряна окончательно. Нашел только пару записей FILE0, и те созданы при попытке восстановления загрузчика "женскими докторами". Опытным путем посмотрел на тестовом стенде хранение данных в $MFT на примере БД в 10 ГБ. Она состоит из двух кластеров, в начале каждого находится запись "INDX(" (49 4E 44 58 28 00). Копаю в этом направлении. Надеюсь, верном.

23.04.2019, 20:30	[включить плавающее окно] #4
9285 Опытный Регистрация: 08.02.2019	Что касается собственно вопроса, то без его записи можно восстановить по результату сигнатурного поиска, но если файл фрагментирован, то восстановится лишь первый фрагмент. Но это если нет записей вообще, хотя не факт что это так - это я исходу из того, что (судя по сообщению с другого места) поиск производился по начальной сигнатуре файловой записи. Но в случае каких то сбоев бывают различные ситуации, в том числе такие, при которых файловая запись смещается на несколько байтов, или бывает вкрапление мусорных байтов. Если же какие то записи всё таки найдены, то хоть и суперничтожный, но шанс имеется. Это относится к сильнофрагментным файлам; причём таким, которые подвергались дефрагментации штатными средствами винды. В этом случае запись о размещении файла находится в нескольких записях и если даже нет начальной, то можно найти остальные (главное знать номер родительской записи). В случае недефрагментированного файла здесь можно уповать лишь на то, что потеряна лишь начальная запись, в которой хранятся данные только первого фрагмента и именно его уже нашли. Если же дефрагментация делалась, но тут может образоваться квазиконструкция при которой файл будет записан практически одним фрагментом, но при этом иметь кучу записей, в каждой из которых будет запись об одном фрагменте. Это связано с тем, что виндовый дефрагментатор не может избавится от расширенного атрибута. Ну и всё это, конечно же, актуально для файла расположенного на определяемом адресном пространстве - типа одного физического диска или собранного массива. PS. Кстати, в другом месте тебе написали про "чудоторящий" DE и что с ним никто рядом не стоял. Спору нет, программа уникальная, но она сама ничего не сделает. Да и есть не факт что нужны суперспособности - а случаи когда та же R-studio находила участников массива тоже имеются. PS. ответ написан до появления твоего сообщения и уже не буду менять его а добавлю следующее. В DMDE смотрел результаты поиска не открытием тома а просмотром записей MFT, причём с включением и мелких? Лог хотя бы одного поиска имеется? Добавлено через 1 минуту Цитата (druoleg) » в начале каждого находится запись "INDX(" (49 4E 44 58 28 00) Аналогичная запись имеется у индексов каталогов. Добавлено через 8 минут Опять же, предположим что ты найдёшь все такие блоки и они будут относиться к базе. А есть ли в них что то, что позволит однозначно идентифицировать их расположение в структуре? Ну вот типа как у той же MFT есть номера записей (вариант того что могут быть дублирующие мусорные записи пока не рассматриваю).. Добавлено через 13 минут Цитата (druoleg) » посмотрел на тестовом стенде хранение данных в $MFT на примере БД в 10 ГБ. База рабочая? Если да, то посмотри её файловую запись на предмет фрагментации и если таковая имеется, то какие приращения (размеры фрагментов) фиксированные или нет.

26.04.2019, 12:35	[включить плавающее окно] #5
druoleg Новенький Автор темы Регистрация: 23.04.2019	Спасибо за помощь. Данные восстановить не удалось. Но удалось выяснить, что перед поломкой RAID отработал DiscCrypt (злоумышленникам привет). Очень качественный провал. Базы рабочей нет, смотрели на полугодовой бекап.

26.04.2019, 17:56	[включить плавающее окно] #7
9285 Опытный Регистрация: 08.02.2019	Цитата (Smirnoff) » Всячески одобряю. Админ, пусть даже и плохой, может не очень правильно организовать систему бэкапа, но хоть какая то обычно бывает (не полугодовая). Во всех остальных случаях виновником является хозяин-скупердыяй. Ты же вроде сам админишь. Неужели до сих пор не сталкивался с таковыми?

27.04.2019, 09:37	[включить плавающее окно] #8
geran Общительный Регистрация: 31.10.2003 Адрес: Москва / GPON 100мбит	А что за тип рейда? У меня бывало терялись данные и обычные программы для восстановления не доставали ничего кроме картинок. Но для дисков Seagate есть прога достающая всё вообще и без потерь. Seagate_FILE_RECOVERY_v2.0 рекомендуется. Работает на ура только с дисками Seagate.

27.04.2019, 10:21	[включить плавающее окно] #10
9285 Опытный Регистрация: 08.02.2019	geran Не стоит давать столь громогласные заявления не уточняя подробности ситуации. Потому как подобное потом тиражируется и некоторые даже верят в истинность написанного. Один из примеров подобного - то что переформатирование помогает восстановлению данных. Не исключаю что одному из миллиарда такое и "помогло", но вот остальным это только ухудшило ситуацию.

27.04.2019, 13:20	[включить плавающее окно] #11
geran Общительный Регистрация: 31.10.2003 Адрес: Москва / GPON 100мбит	Цитата (9285) » Не стоит давать столь громогласные заявления Да ну что Вы.. я тихонечко. Цитата Один из примеров подобного - то что переформатирование помогает восстановлению данных. Да это как получится. Конечно в первую очередь надо без переформатирования. Но если не выходит я доставал некоторые огрызки и много картинок после форматирования. А что? Физически ведь данные не стираются.

27.04.2019, 13:34	[включить плавающее окно] #12
9285 Опытный Регистрация: 08.02.2019	geran Это никак не получится. Надо просто пользоваться нормальным ПО и всё возможное восстановится. А формат физически удаляет некоторый обьём данных - тут всё зависит от конкретной ситуации. Из более менее свежего - на хоботе был случай, когда кроме формата пострадавший ещё и переразметил диск в другом стиле, плюс ещё яндекс диск успел кое-что переписать. Как результат - примерно 170 тысяч записей MFT унеслись в нирвану.

27.04.2019, 14:11	[включить плавающее окно] #14
9285 Опытный Регистрация: 08.02.2019	geran А смысл если она динамично изменяется? Или если произошли какие то деструкции при том же изменении размера раздела и часть даже свежих записей имеет неактуальные сведения? Бэкапить надо сами данные. Ну а если всё таки хочется забэкапить MFT то это можно сделать в дисковых редакторах - в том же DMDE, в "папке" Metadata он есть целиком (не считая списков расширенных атрибутов). Добавлено через 7 минут Расположение записи и её фрагментация зависит от используемого форматера. Воздействие последующего формата тоже зависит от него же. При этом не стоит забывать что кроме перезаписи какой то части записей MFT перезаписывается, как минимум, поляна двух крупных метафайлов - $LogFile и $Bitmap. Первый занимает примерно 64 мега - и вот если он попадёт на бывший фрагмент MFT, то накроется 64 тысячи записи. Или не попадёт на записи MFT а на те же однокластерные файлы - прикинь сколько их уничтожится. PS. Дело не в языке, а в том что надо знать хотя бы базовые моменты и то, что многое зависит от конкретной ситуации (как в случае используемых форматеров).

30.04.2019, 13:20	[включить плавающее окно] #16
9285 Опытный Регистрация: 08.02.2019	Smirnoff СПОЙЛЕР » Я читаю внимательно, в том числе и в других местах (), к тому же знаю что не всегда стоит верить написанному. Полугодовой бэкап то есть - а за полгода мало ли что сменилось. В том числе могли старых админов сократить а нанять таких, которые за миску супа не могут разобраться. Не, в "жирные" годы я бы согласился с тобой, но сейчас есть немало примеров когда и вполне серьёзные организации начинают экономить (в том числе на IT). () Цитата с другого места (осзона) Руководство не мое, я тут в роли "спасителя" после "женских докторов". Для нашей организации это репутационные потери (хотя мы 3 года не допускались к этим серверам теми же безопасниками и уже спасали их 3 года назад после шифровальщика на том же сервере), а для заказчика кадровые. Не хочется чтобы автор темы воспринял написанное в свой адрес (тем более что в жизни был случай когда я тоже "затыкал пробоину"), но если речь идёт о репутационных потерях, то почему не посылают человека понимающего типа того, что написано выше про MFT, а по большому счёту - спеца, в том числе со своим оборудованием (те же писи3000 есть и внешние), который может от имени фирмы поработать на месте? Дорого? А как же репутация?

30.04.2019, 19:34	[включить плавающее окно] #18
9285 Опытный Регистрация: 08.02.2019	Smirnoff СПОЙЛЕР » Причём здесь безопасники и клиентские тараканы? Ну да, админы-кАзлы и всё уже случилось. но если всё так серьёзно, то почему не посылается человек, который не будет спрашивать на форумах (не такие уж и сложные) вопросы? Тем более если речь идёт о репутационных "прибылях"?

02.05.2019, 13:03	[включить плавающее окно] #19
Smirnoff Модератор Регистрация: 30.12.2004 Адрес: Новосибирск	СПОЙЛЕР » Цитата (9285) » почему не посылается человек, который не будет спрашивать на форумах (не такие уж и сложные) вопросы? Если ты думаешь, что у любого дистрибьютора/интегратора серверов, СХД и прочего серверного барахла обязательно должен быть в штате специалист по восстановлению данных - так ты ошибаешься. Их работа как раз в том, чтобы услуги такого специалиста никогда не понадобились... __________________ С уважением, Олег Р. Смирнов

02.05.2019, 21:36	[включить плавающее окно] #20
9285 Опытный Регистрация: 08.02.2019	Smirnoff СПОЙЛЕР » Я думаю что уже написал ранее. Если их не допускали, то о каких репутационных потерях речь? Если нет штатного спеца, то таковой нанимается. Это если реально хочется подтвердить репутацию а не изображать херню".

Опции темы
Версия для печати Отправить по электронной почте
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид