On 06/14/11 16:37, wire:
P.S. Nehupujte zelezo ked je HW RAID tak tvrdy, ze OS nema informaciu
a pristup k jednotlivym diskom a stavu RAID, lebo o chybe sa dozviete az
ked
je neskoro :(
Len pre zaujimavost, o aky HW sa jedna ?
HW RAID tak tvrdy, ze OS nema tuseni v jakem je to stavu je treba
>> P.S. Nehupujte zelezo ked je HW RAID tak tvrdy, ze OS nema informaciu
>> a pristup k jednotlivym diskom a stavu RAID, lebo o chybe sa dozviete az
>> ked
>> je neskoro :(
>
Len pre zaujimavost, o aky HW sa jedna ?
--
Robert
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/li
Jozef Drahovsky wrote:
Uz niekolky krat riesim rovnaky problem
strata dat pri spadnutom HW RAID1.
RAID1 se mi rozpadnul uz mockrat (gmirror), ale nikdy jsem neprisel o
data - proste vypadek jednoho disku kvuli ATA timeoutu, nebo vadnym
sektorum.
Rozmyslam nad riesenim, ze system bude booto
On 06/14/11 09:50, Jozef Drahovsky:
Uz niekolky krat riesim rovnaky problem
strata dat pri spadnutom HW RAID1.
'sem myslel, ze RAID1 si clovek porizuje casto prave proto, aby riziko
ztraty dat snizil ;-)
Jestli je tedy on castou pricinou ztraty dat, jestli by nebylo lepsi se
ho zbavit a zvy
Ahoj,
Rozmyslam nad riesenim, ze system bude bootovat z USB flash disku,
na ktory bude v principe RO +/- editovanie konfiguracie
a ojedinele zapisy pri restarte ap.
provozuji neco podobneho bez USB, mensi SSD disk na / (RO), /var, /tmp, /usr,
swap na vetsim HDD + gmirror. Chodi to bez proble
Uz niekolky krat riesim rovnaky problem
strata dat pri spadnutom HW RAID1.
Rozmyslam nad riesenim, ze system bude bootovat z USB flash disku,
na ktory bude v principe RO +/- editovanie konfiguracie
a ojedinele zapisy pri restarte ap.
Vsetko ostatne ako tmp, var, usr/home atd, by bolo na nasled
