Ah, I nearly forgot this post!
Two boards? Synchronisation mechanism? (just interested)
Anyway, would be too expensive for too little gain. Not that paranoid
at the moment, sorry
Well, I already came to my conclusions about how should I do, just
details is quite uncertain.
Since that is not really a "hardware raid1" on my board (C7 CPU) and
there are lot more issues, if controller burns, I put ideas about
hardware raid away quite soon.
Linux software raid? Could be, but it still holds the risk of "what
happens if disk controllers write crap somehow"? (yes, yes, unlikely,
Since raid1 would be nearly two times slower for C7 board and I mostly
do not need immediate synchronisation (plus power consumption is very
limited), I figured out something interesting; at least for me: system
is mostly operating single disk, but periodically synchronises*
contents with second disk, that is not spinning in other times. For
extra safety, it would be very good, if there was moving backup in
RAM, which mirrors files matching paths in list. By "moving" I
understand filling some 500MB with those important data copies and
deleting oldest, that would be synchronised to second HDD, if used
* that should be done by maintaining changelog of filesystem since
last sync for all files - any suggestions how to do that?
And .. doest that seam an overkill, if I want that RAM mirror work
well and "move"?
On 10/21/08, Geoff Swan <firstname.lastname@example.org> wrote:
>> Which option is safer in general, when talking about small embedded
>> hardware or software raid1?
> In terms of recovering data after a crash I think software raid is
> safer, or
> at least easier to recover. The advantage being that the data storage on
> a software
> RAID1 disk looks like any other non-raid disk. Depending on the hardware
> RAID controller
> you may not be able to read the data on your disk without the hardware
> raid controller.
> - I think I think, therefore I possibly am -