The Intel Raid is managed by the mainboard and/or driver. lvm tools dont even get to see the things.
Your Linux seeing sda and sdb means it saw through the raid setup of the mainboard, which is a bad thing (tm).
There´s several levels in a raid: 1) the hardware 2) what the raidcontroller makes of it 3) what the OS sees. In any reliable raid system, 2 and 3 are the same. If they arent the same, questions like yours arise, confusing even the most seasoned admins. In this case, it looks like you got lucky. You did the wrong thing, your raid setup ignored you, and now is doing (hopefully) the right thing.
This is not always the case. Equal chance is, you do the right thing, the mainboard raid ignores you, and does the wrong thing.
The only way to securely repair any kind of raid is through the tools of the raid system.
What the Intel driver is now doing, is a dd, calling it rebuild. Of course, it didnt see what your dd did! It doesnt have an idea where the data output of dd comes from, and cant now that it is, in fact, the correct data. So it has to do the copying itself. For all the poor thing knows, it could be grandma´s collection of turkey recipes.
For any good solid proper raid setup, things have to be deterministic. Mainboard raids usually arent (BIOS version, driver version, OS, etc). The admin has to train him/herself to repair the raids. If you put any kind of important data on a raid, you must work yourself through some of the failures of it. If you dont, you´d probably be better off without a raid. Turns out, most of the time, only OS software raids, or raid card raids are deterministic. The mixup of mainboard/driver raid that almost each board has is not much more than a placebo.
P.S. do you have a backup?
CAUTION The answer about changing the UNIX password for "postgres" through "$ sudo passwd postgres" is not preferred, and can even be DANGEROUS!
This is why: By default, the UNIX account "postgres" is locked, which means it cannot be logged in using a password. If you use "sudo passwd postgres", the account is immediately unlocked. Worse, if you set the password to something weak, like "postgres", then you are exposed to a great security danger. For example, there are a number of bots out there trying the username/password combo "postgres/postgres" to log into your UNIX system.
What you should do is follow Chris James's answer:
sudo -u postgres psql postgres
# \password postgres
Enter new password:
To explain it a little bit. There are usually two default ways to login to PostgreSQL server:
By running the "psql" command as a UNIX user (so-called IDENT/PEER authentication), e.g.: sudo -u postgres psql
. Note that sudo -u
does NOT unlock the UNIX user.
by TCP/IP connection using PostgreSQL's own managed username/password (so-called TCP authentication) (i.e., NOT the UNIX password).
So you never want to set the password for UNIX account "postgres". Leave it locked as it is by default.
Of course things can change if you configure it differently from the default setting. For example, one could sync the PostgreSQL password with UNIX password and only allow local logins. That would be beyond the scope of this question.
Best Answer
Generally best practices for databases would be to put the database on a RAID 10 or RAID 1, separate from the OS & swap partitions.
For PostgreSQL you may also want to plan on a small, fast RAID 1 for the WAL (pg_xlog) directory to live on, as this will keep the DB from getting bogged down if there are a large number of writes. Also if you think you'll have several high-traffic tables you may want to have separate arrays/spindles for those (putting them into different tablespaces).
How important all of this is depends heavily on your workload, but the above is a good start. The PostgreSQL wiki probably has other good suggestions - see http://wiki.postgresql.org/wiki/Main_Page