• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Can a SSD replace raid, for reliability?

R

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,223
Assume a very low I/O Linux server where most of the data I/O happens on a remote disk, and I just want a single drive for an OS.

Would a SSD be more reliable than a single HDD? I'm guessing the answer is yes, but just want a second opinion. Currently I don't use hardware raid for my servers, and I'm looking on a way to give me more reliability for the OS drive. While I don't store data on there, it's still a pain to rebuild and reconfigure a system should the drive fail. Would also lower power consumption for small servers, such as the 1U atom box I have, making it into a solid and reliable appliance box, more or less.
 
As much as I've read about SSDs totally bricking themselves, I can't help but be a bit timid about trusting them. But for your scenario the answer is pretty easy... just set up a daily (or hourly) rsync cron job to copy everything to the remote HDD for your backup. No need for fancy-pants RAID.
 
In theory.... SSD do not have as many failure modes as HDDs.

HDDs can fail in all sorts of spectacular mechanical that SSDs are not vulnerable to.

In practice... SSD controllers have proven to be horribly faulty, and have data corruption/failure rates similar to HDDs.

Nothing RAID for high availability, and backups for data safety.
 
jwcalla said:
As much as I've read about SSDs totally bricking themselves, I can't help but be a bit timid about trusting them. But for your scenario the answer is pretty easy... just set up a daily (or hourly) rsync cron job to copy everything to the remote HDD for your backup. No need for fancy-pants RAID.
Click to expand...

It's an OS drive though, so I can't really rsync the entire thing and hope it will still boot. Though I will be taking an acronis image of it either way.

Did not realize they had lot of corruption issues though, I might back out of this and stick with the spindle drive. At least when they die, they die, and it's the end of it.
 
For linux you can get away with an rsync backup but the restore process adds a couple more steps which can be done through a Live CD:

1) Create the ext4 partition on the new drive.
2) Rsync the backup to the new partition.
3) Edit the /etc/fstab on the new drive and change the UUID of the mount point to that for the partition created in step 1. (If you're using NFSv2 or NFSv3 you may need to likewise fix /etc/exports.)
4) Install the GRUB bootloader on the new drive.

I've done this myself a couple times, e.g. when I moved from an HDD to an SDD, and it's a surprisingly painless process.

Yay linux.

Though if you have a different partitioning scheme (/, /home, /swap, /jabroni, etc.) then it would be more complex. You'd have to do steps 1-3 for each partition. Taking an image of the whole drive will certainly get the job done. The downside is that it's a lot longer and the file size is pretty big so you might be inclined to make a backup less frequently (which might fit your needs perfectly anyway).
 
jwcalla said:
For linux you can get away with an rsync backup but the restore process adds a couple more steps which can be done through a Live CD:

1) Create the ext4 partition on the new drive.
2) Rsync the backup to the new partition.
3) Edit the /etc/fstab on the new drive and change the UUID of the mount point to that for the partition created in step 1. (If you're using NFSv2 or NFSv3 you may need to likewise fix /etc/exports.)
4) Install the GRUB bootloader on the new drive.

I've done this myself a couple times, e.g. when I moved from an HDD to an SDD, and it's a surprisingly painless process.

Yay linux.

Though if you have a different partitioning scheme (/, /home, /swap, /jabroni, etc.) then it would be more complex. You'd have to do steps 1-3 for each partition. Taking an image of the whole drive will certainly get the job done. The downside is that it's a lot longer and the file size is pretty big so you might be inclined to make a backup less frequently (which might fit your needs perfectly anyway).
Click to expand...

What about permissions though? Like when I copy the files back and forth wont the permissions end up being different? Lot of stuff is very strict about permissions being set a certain way.
 
I think rsync has a flag to keep permissions, or maybe it keeps permissions by default and there is a flag to ignore permissions. either way, you can keep permissions.
 
Red Squirrel said:
What about permissions though? Like when I copy the files back and forth wont the permissions end up being different? Lot of stuff is very strict about permissions being set a certain way.
Click to expand...

Yes it depends what filesystem you're backing up to. If it's NTFS, then it won't work and you should just do the image thing. If it's ZFS there might be a way to make it work but it might not be worth the trouble.

If you're doing ext4 -> ext4, then rsync maintains permissions, ownership, timestamps, etc. if the -a (archive) flag is used and the operation is run as super-user.

From the man page:

Code: 
        -a, --archive               archive mode; equals -rlptgoD

        -r, --recursive             recurse into directories
        -l, --links                 copy symlinks as symlinks
        -p, --perms                 preserve permissions
        -o, --owner                 preserve owner (super-user only)
        -g, --group                 preserve group
        -t, --times                 preserve modification times
        -D                          same as --devices --specials
        --devices                   preserve device files (super-user only)
        --specials                  preserve special files

The options I use are: -aqxhW --delete --stats

which correspond to:

Code: 
        -a, --archive               archive mode; equals -rlptgoD
        -q, --quiet                 suppress non-error messages
        -x, --one-file-system       don't cross filesystem boundaries
        -h, --human-readable        output numbers in a human-readable format
        -W, --whole-file            copy files whole (w/o delta-xfer algorithm)
        --delete                    delete extraneous files from dest dirs
        --stats                     give some file-transfer stats
 
You must log in or register to reply here.
Back
Top