![]() |
Как разбить raid 10 на логические диски?
Есть сервер 2012 работающий на raid 10 с 4-мя дисками. Кто-то изначильно сделал всего 2 логических диска С (system) и D (data). Очень нужен третий диск. Винда не даёт разбить D диск. Вернее позволяет из 1.5 Тб свободного места, забрать для нового диска только 20гб. Акронис и другие подобные проги боюсь применять, что бы не убить Raid.
Что посоветуете? p.s. контролер встроенный Intel(R) C600+/C220+ series chipset SATA RAID Controller маринка supermicro X11SSL-F |
Приветствую. Посоветую бэкапнуть данные и пересобрать новый рэйд.
|
Цитата:
|
Цитата:
s.i.p.a, вообще массив обычно бьётся на LUN'ы средствами самого RAID'а, которые с точки зрения ОС являются дисками - самостоятельными блочными устройствами "логических дисков" нет, есть разделы и тома |
Цитата:
|
Цитата:
Ну поставьте туда ещё диски... |
Цитата:
|
Цитата:
Цитата:
А если сервер 1u и там уже 4 диска, то куда их вкидывать? Там всего 4 слота. Либо есть другой вариант - перекинуть всю инфу с D куда-нибудь в резерв, D убить полностью и сразу создать нужного размера, переместить информацию на место. Тоже относительно простой метод. Конечно надо уточнить, что именно сейчас находится на D и нет ли чего-то критически важного. |
Всем спасибо. Сделал бекап. Разбил диск D прогой minitool partition wizard. Программа и рейды видит и на серверную ОС не ругается. Live CD не видел ни raid ни отдельно жёсткие диски, как бы я не пытался ему подсунуть драва.
p.s. Изначально сервер принёс человек, админ которого с менеджерами уволились и удалили данные с сервера. Но видно админ был так себе, данные не затирали поверху, все решения безопасности и доступа были сведены к тому, что у всех пользователей права администратора. При загрузке с win PE ни диски, ни raid не были видны. Driver'а подгружал - без толку. В итоге тупо два диска из рейда подключил к другому компу, запустил 10-ку винду, поставил драйвера raid'a и собрал виртуальный raid в проге R-studio. Данные восстановил. Диски обратно поставил. Клиент доволен. Про настройки безопасности уведомил, про важность бекапов рассказал. |
Цитата:
Не думаю что с файловой системой, отличающейся от NTFS (всё же это сервер). Убей бог не пойму, когда такая необходимость может возникнуть... Да и возможность присвоения буквы диска каталогу ещё никто не отменял — если дело в том, что какая-то г...программа имеет жёсткую привязку к букве диска.. |
mwz, да вполне классический подход: том с ОС и ПО, том с данными, том с логами.
|
Цитата:
Ещё одна классика — отдельный раздел под файл подкачки. :o И хотелось бы услышать, "в чём смысл жизни", у топикстартера. |
Цитата:
нередко сбой одной системы порождает массу логов в соседних, а иногда обновление ПО подразумевает изменение структуры данных и тоже порождает нетипичные объёмы логов |
Цитата:
PS Это я со своего серверочка списал. ;) При том, что места вагон. |
mwz, если приложение написано/сконфигурировано так, что без логов не должно работать, то "вагон места" для данных как раз позволяет корректно завершить начатую операцию. Либо корректно откатить.
Искренне считаю что "Unexpected error" в подобной ситуации - это ошибка в ПО. |
Цитата:
Цитата:
|
Busla, ну вот, поделился вскользь проблемой с "Unexpected error 0x70", посмотрел на запись об ошибке "со стороны", услышал полезное мнение — и решил-таки её. :)
Скрытый текст
Как и надеялся, проблема оказалась не в ПО (ну, скажем так — может она там тоже есть, но за годы проявилась лишь в этой ситуации), а в самой базе. Создал её резервную копию, а затем на исходной пожертвовал несколькими промежуточными бэкапами, удалив записи (не сами бэкапы), относящиеся к проблемному периоду этого компьютера, в т.ч. ту, которая вызывала ошибку. И запустил "Repair Database".
До удаления записей эта операция проходила очень быстро, с сообщением "Проблем нет". Здесь же работа пошла посерьёзней, заметно дольше, с финальным сообщением "Не удалось восстановить часть бэкапов", относящимся только к удалённым вручную сведениям. И после этого всё заработало без проблем, а размер базы сжался чуть не на полтерабайта, причём не только за счёт очистки от неактуальных бэкапов: при возникновении проблемы обработка базы происходила не полностью, и дедупликация работала не в полном мере — раздув тем самым объём базы. Поиск в интернете как по этой, так и по связанной ошибке (которую я не привёл как менее информативную) полезной информации не дал, хотя сообщения о таких ошибках, и не одно, нашлись сразу. |
слейте инфу, пересоздайте в чем проблема? зачем писать?
|
Время: 04:04. |
Время: 04:04.
© OSzone.net 2001-