На сервере при перестроении массива данных из Raid 1 в Raid 5
произошел сбой, сервер запустил rebuild.
В результате массив Raid 5 не собирается заново правильно.
Базы данных 1С не запускаются.
То есть сами файлы, базы и архивов перестроились и превратились в сбойные.

Можно ли как то восстановить файл базы либо файлы .dt, архивов?

(13) Обращались. Специалисты говорят.
Они ни чем не могут помочь.

Если есть битые файлы. Их никак не восстановить?

(16) Во многих случаях это либо нереально, либо встанет в астрономическую сумму.

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

(16) Ну если одни сказали, то идите к другим, из вашего объяснения ситуации ничего толком не ясно, видно вы сами не в теме. А по существу, есть проги восстановления удаленных данных, гуглится на раз. Они могут помочь.

(18) админа публично выпороть надо было ещё при первом случае))

(16) какое слово специалистов вам непонятно?

(19) Если на пострадавшем компе уже велась упорная самодеятельность, то вероятность восстановления специалистами резко упала.

(19) ну это восстановление данных на диске после форматирования скажем да?

(23)При форматировании данные не удаляются, и не повреждаются.
Поэтому после форматирования восстановить данные может даже школьник.

(24) Но только в том случае если после форматирования на диск ничего не писалось.

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

В данном же случае имеет место повреждение данных, а не удаление записи в ФС.
Это уже неизлечимо.

(21) Специалисты бывают разные.
В (19) правильно сказано. Сам раз так ноутбук отдавал в ремонт.
Одни сказали что все, только сдать за 1500р. его можно,
продержав месяц.
Другие же, запросив 4500р., продержав неделю вернули его в рабочем состоянии.

(25)Ну не обязательно.
Смотря сколько было записано, насколько большой объем диска, насколько фрагментированы были данные, и как повезло.

специалисты говорят:

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

(30) Ну так убирайте ошибки вручную кто запрещает?

Ждем фотку с празничным сжигаением того, кто обязан был настроить бекапы, но не сделал этого.

(31) он ждет, что мы ему их уберем.

(30) А они определили, что в базе, преимущественно, данные, а не случайный мусор, или даже не смотрели?

(29)

произошел сбой, сервер запустил rebuild.
В результате массив Raid 5 не собирается заново правильно.

не известно что это за процедура, равна ли она процедуре форматирования диска?

(31) Я и пытаюсь узнать как это сделать?!

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

(34) это более тяжелый случай, чем форматирование, но менее тяжелый, чем полное затирание всех данных))

(35) база файловая была

(34) ИМХО, теоретическая возможность восстановления есть, особенно если комп выключили сразу после сбоя и не включали, осталось найти хороших спецов, которые возьмутся это делать за астрономическую сумму.

(37) тогда почему до сих на базу пор не натравлен Tool_1CD?

(3) Просто классика жанра...

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

начало года, есть повод начать с ввода остатков...

+(39) вот хорошая статья на тему файловой базы: http://forum330.com/forum/303/all

(39)там скорее от оригинала осталось только название файла

(43) "Лучше, конечно, помучиться..."

Ребилд массива без предварительного бэкапа? Ну вы упоротые :)

(44) Судя по (0) я полагаю, что уже помучились, и теперь уже вряд ли есть смысл даже нести к специалистам.

Обратись к http://rlab.ru/

Если получится, возьмут очень много )

(40) Вопрос в сравнении стоимости утерянных данных и стоимости их восстановления по остаточной намагниченности блинов деленной на вероятность успешного восстановления.

(38) *теоретическая вероятность

(49) Где вы берете эти сказки про остаточную намагниченность?

https://cloud.mail.ru/public/KENm/DCTz52yL9

(52) вот это загруженная база в Tool_1CD

(49) разумеется это дорого... оборудование ведь дорогое, навык работы с оборудованием и ПО просто уникален - эти активы всяко нужно отбивать!

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

(54) Восстановление данных с убитых дисков - да дорого.
Но восстановление по остаточной намагниченности это сказки.

(47) А чем они помогут?
Там восстанавливают данные с дисков которые не читаются.
В данном случае - файл есть, он читается, просто он испорчен.

Вот это (52) , загруженное в Tool_1CD.
Можно как то далее реанимировать?
Что можно сделать?

(58) вангую - после суток секса с восстановлением - будет принято волевое решение вводить остатки в новую базу.

Ну или отослать базу опытным восстановителям (vde69)

(58) ты уверен, что мы бросились за тебя читать ссылку в (42) и удаленно гадать, что там с файлом?

И.. кому понадобился 5-ый рэйд ? Это же самый тормоз, который вообще есть.

(61) им и бекап не нужен. Был.

Если RAID был зеркалка, то велика вероятность, что данные в хвостовых областях диска ещё остались, если, конечно, ребилд RAID-а всё не потёр.
Но, для RAID-5 нужно больше чем два диска, так что как-то странно.
То есть смотреть на низком уровне, что осталось на дисках - зеркалка обычно достаточно просто выглядит - только проблема в том, что в NTFS все данные о файлах хранятся в MASTERTABLE, которая в начале диска и чаще всего перезатирается.

P.S. если на дисках были BackUp-ы, то велика вероятность, что они записаны единым блоком - так как запись BackUp-а идёт последовательно - то есть искать этот файл - он обычно в конце таблицы (её могли не затереть) и из него доставать.

зато сэкономили на админе

пятый рейд под файловую БД и без бекапов, это же додуматься надо

(63) без вариантов, там данные в мелкий фарш

(61) Дает скорость без больших потерь объема.
Мы используем как временное хранилище архивов. SQL делает архив на raid-5, потом сжимается и копируется по сети.

+100
Вот что меня конкретно удивляет так это пятый рэйд.
Организация работает с файловой базой, бэкапы не делались полтора года, и при этом этим людям зачем то понадобился RAID5.

Вот это вообще в голове не укладывается.
По уму им вообще никакой рэйд не нужен.
Однако ж - пятый корячат.

(60) Сам почитал, нет средств что бы двигаться к восстановлению.
Пока я их не выявил (
(68) бэкапы делались, они убились вместе с базой

(67) 5й скорость дает?
Це шутка?
Ну если добротный контроллер с хорошим кэшем стоит, то скорость будет несколько больше чем у одного диска.

К тому же надежность у 5го нижен плинтуса, особенно если хранить на нем холодные данные.

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

(67) Скорость ?! :))))))))))))))

чудны дела твои, природа...

(71) тут было все убито, так все случилось
я не занимался администрированием этого
и как выше сказали, учитывая что база которую нужно восстановить, сама около 200Мб, причем тут эти рэйды, не уложу в голове

(70), (72) - raid-5 из трех дисков в 2 раза быстрее, чем raid-1 из двух.

(75) но на нем в 2 раза чаще бэкапится надо

(75)  не верю

(75) а еще круче он начинает работать когда один из этих трех винтов дохнет

(76) не чаще чем на 1. Если 5 на 3 дисках, надо потерять 2.
На 1 из двух тоже 2.(77) Там можно в резерв поставить ещё диски и он автоматом перестроиться.

(75) В RAID 1 чтобы данные записались на диск, происходит две операции на запись (по одной записи на каждый диск), и следовательно RAID 1 имеет два пенальти.

В RAID 5 чтобы записать данные происходит 4 операции (Чтение существующих данных, четность RAID, Запись новых данных, Запись новой четности) тем самым пенальти в RAID 5 составляет 4.

(79) Пока ты не дашь ему диск для ребилда он у тебя будет  работать в аварийном режиме, а когда дашь - он будет ребилдить столько, что выспишься.

(78) нормально он работает, если контроллер аппаратный и есть Spare диск. Главное не жмотиться если уж взялись строить Raid

на 3 дисках raid-5 это даже не смешно

(83)Конечно смешно, 5 не актуален. Раньше диски золотые были и за объем боролись. Сейчас начальный уровень 10 будет.

(83) не смешно, а стрёмно минимум 3 для данных+ 1 Spare и нормальный контроллер с батарейкой, тогда время аварийного режима ~ 10 минут, при работающей системе (медленно, но работаем - главное не дёргать диски до перестроения)

Странно, уточню у админов еще раз, сколько дисков поставили. Но точно стало минимум в 2 раза быстрее.

(75) В линейном чтении может быть немного быстрее в некоторых вариантах, но не в два раза.
При случайном доступе проигрывает по быстродействию.
В смешанном режиме при работе с БД например - вообще ужас, а не быстродействие.

Ну и надежность ниже.

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

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

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

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

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

(90) и еще кидают на этот же пятый рейд бекапы, как в (69), после чего идут на мисту с криками "оживите трупик плиз".

+(91) как говорят финны: "My?t?h?pe?" - когда кто-то что-то сделал дурацкое, а стыдно за это почему-то вам.

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

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

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

А вот бэкапы организовать это недорого, и спасает от всего.

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

5 рэйд это как страшный сон, особенно, если хотя бы один диск в контейнере разваливается.

Пробовали протестировать базу(желательно копию) штатной программой chdbfl.exe?

Или вот статья http://catalog.mista.ru/public/187832/ может там будет что полезное.

(95) у него ничего нет, ему восстанавливать не-че-го

Восстанавливал базу SQL MDF File Repair/
После того как админ вытащил диск из рейд массива со словами он красненьким горел.
Восстановил 80 процентов база не работала пока таблицы конфигурации и прочие системные таблицы не перелил с копии. Благо структура не сильно изменена была.
В результате база открылась но инфа там была не вся какие-то документы просто не открывались но уже что-то. Они там ручками фигачили смотрели в эту копию.
Короче после этой истории у всех моих клиентов бесплатно настраиваю бэкап на каждый день. Как бонус. Написал скриптов чтобы диск не переполнялся.
Короче без знания SQL и доли везения хрен что восстановишь.

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

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

P.S. если база 200 Мб, то никто не мешает её просто сохранить на переносной диск перед тем, как что-то делать с RAID-массивом - по крайней мере, у вас будет живая база, даже если сервер окажется мёртвый (что частенько бывает при отказе RAID-а).

Не забываем, что Rebuild Raid это самая серьёзная нагрузка на диски, что частенько приводит к их отказу, что, скорей всего, и произошло.

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

(100) К сожалению, у большинства мелких контор BackUp-ы льются на тот же диск, просто только потому, что у них в компьютере диск один, но, когда набивается несколько документов в день, то ввести месяц не такая уж и проблема, а раз в месяц скопировать BackUp на USB-flash может даже ленивый.
Ну и, самое главное, что BackUp-ы нужно проверять, что они разворачиваются, а то у 1С бывают ситуации, когда база выгружается, но уже никуда не загружается, причём не так уж и редко.

P.S. если кому-то очень не хочется делать BackUp, то настраивайте выгрузку данных - она может делаться без выхода из 1С, а также позволяет записать только важные документы, и из-за меньшего её размера её можно просто отправлять по почте, чтобы она не оставалась на текущей машине.

(98) Ну я почти у всех настраиваю. Ну кроме тех у кого админ в штате.
Настраиваю как правило бесплатно, а обслуживание платное.
В среднем около 500рублей в месяц.
И ничо.

(101) По уму бэкапы надо -
а)делать
б)проверять - а восстановить то с него можно?
с)контролировать - а делается ли он в данный момент.

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

(98) в основном да. систему поставить без проблем. а, с настройкой бэкпаов проблемы в основном, а зачем вообще админы нужны?
из 10 админов " выше плинтуса 2-3". Все остальные эникейщики или считающие себя пупом вселенной недоумки ))).
Аутсорс опять же.

(103) Когда пользователь про...л все документы с рабочего стола наличие BackUp-а базы данных 1С его нисколечко не спасает. Потому как, все контактные телефоны и все заказы почему-то оказываются в Excel.

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

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

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

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

(0) Организации экономящие на админах должны страдать.

(107) Почему должны?

Сильно страдать

(108) Не все созрели, что бы (109).

+(107) Бывают, конечно, и исключения - знаю одного из бородатых дядей,  у которых укуячился при ребилде 5ый рейд одного завода, на котором последний бэкап был месяца за 2 до событий... А там минимально 4000 отгрузок в сутки.

(108) а что им еще делать когда случается (0) :)

(0) Я бы таким админам писал в трудовую книжку "Не годен к системному администрированию". И "Никогда не брать админом".

3 правила админи, за незнание которых нужно убивать админа.
1.Сделай бэкап\настрой бэкапы.
2. Проверь, что бэкап рабочий
3. Перед любой работой с оборуодованием - сделай бэкап.

(103) а для этого - существуют регламенты.
1) "делать N раз в период", складывать на другой диск
2) "раз в некоторый период" писать на внешний носитель, и сдавать ответсвенному за базы (ИТ, ГБ, просто Диру)
3)"раз в другой период восстанавливать базу из бэкапа"
4) настроить контроль наличия бэкапа на время, контроль места на диске под бэкапы
5) раз в большой период - контролировать исполнение регламента и обновлять регламент.

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