That's the one. TYVM.
Originally Posted by arctia
Back up back up back up. For a database, the most important thing is having a back up that you can recover from if anything goes wrong. RAID 1 is nice, but be sure you are actually take database backup properly.
In case both of your SSDs gone poof at the same time, you should check with your manager/boss on what type of data loss is acceptable.
It's on me to set the policy about how much data loss is acceptable. When I inherited this responsibility, all our data was in a single off the shelf NAS (4x 500GB disks in 2x RAID1 arrays), data on one RAID1, and backups on the other RAID1 in the same NAS. It looked like it was set up for daily backups, but the NAS software must have been buggy because it was only creating a backup once per week.
Since then, I've built 3 file servers, designed a more reasonable backup schedule for them, and got some help installing FreeBSD.
There's a fileserver in our office that keeps hourly, daily, weekly, and monthly backups of the database, and provides private storage for personal projects. Five 3TB Greens in RAID6.
There's a second fileserver in the next building over that makes backups daily, weekly, and monthly as our off-site backup, and mirrors public and private projects data. Also five 3TB Greens in RAID6.
The data file itself lives on a third server which also provides public storage for collaborative tasks. RAID10 + hot spare using five 640GB Blacks on an Adaptec RAID card w/ 512MB of RAM (once upon a time, our data file was less than 512MB).
Some time ago, I chose to create a backup once per hour during business hours. The way I see it, there is a balance to maintain between frequency of backups and the performance hit taken while the backup is happening. Once I've got the SSD's in the third server, I'll see how long it takes to backup the datafile from the SSD to the RAID10, and consider more frequent backups based on the results.Edited by willis888 - 3/5/13 at 9:06pm