Backup Server - more writes than reads

[MtK]

Hey,
I'm building a storage with 6 x 2TB drives, to act as a backup server where writes are significantly higher than reads, since the server itself makes backups for many other servers every day.

the actual backup (software) is done on a different machine and this storage would store the backups. better yet, I rather use that server with XenServer or VMWare so that the VM uses the storage itself.

I see three ways to set the pool:

1. RAID10 = (1 x 1) + (1 x 1) + (1 x 1)
2. RAID1 = 2 vdevs of 3 drives each.
3. RAIDZ2 = 1 vdev of 6 drives.

all three would give me sufficient redundancy in case of a disk fails (this machine can go down for repairs if needed, though I don't really want to lose data and start over).
again, I'm looking for speed, specially on writes, since restore from backups would hopefully won't be really needed too often (and if it does, I can wait for it a bit longer).


any thoughts?

 

[cyberjock]

Personally, assuming your system has sufficient RAM to allow ZFS to perform at good speeds, I'd go with a RAIDZ2. The others lose redundancy in the event of a single disk loss, so if one drive has even 1 read error while rebuilding, you will encounter problems. Not a good place to be, even for backups.

Other than that, you lack all the details to prove a good assessment. You only mentioned that the backup is software and that there will be more writes than reads.

 

[MtK]

Assuming there would be a seperate machine with XenServer, and this machine acting as its storage repository, storing one single VM running the backup script (linux). What other information is needed?

 

[cyberjock]

Telling me you are using a script isn't too useful either. Your script could be doing anything from copying some folders with an overwrite every time or executing a commercial software package that does the backup. How often are you doing this backup? How much data are you expecting to move each time the script is run?

Your question is quite complex. A lot of it is really based on what you can reasonably expect to backup and the needs of the server. Some people have no clue what they are doing and grab an old Pentium II and complain it won't work. Others build overly powerful systems and spend lots of money in the wrong areas. If you plan to move 5TB of data every day, then you need much more powerful hardware than a 50GB. If you have a script that simply runs by date/time or file size that has different server needs than an rsync. A simple date/time and file size checks doesn't need as beefy as a processor as an rsyncing server would need.

 

[MtK]

Just out of curiosity, if all this is encapsulated in a VM, does it really matter what's running inside?

 

[cyberjock]

Are you talking about the linux box or the FreeNAS machine?

For FreeNAS -
It matters.. bigtime. Running stuff inside a VM tanks performance.. badly. Reliability goes down the drain. Troubleshooting any issues becomes far more complex. It's just not a good idea to run FreeNAS in a VM except to figure out how it works before you drop cash on the actual hardware.

There's a reason why there's a thread titled "Please do not run FreeNAS in production as a Virtual Machine!"

There's a whole laundry list of don't for VMs with FreeNAS.

For the linux box - that's totally depending on your wants/needs and is beyond the scope of this forum.

 

[MtK]

Again, the FreeNas box is one independent machine, not a VM. the Backup software will most likely run in a separate box/machine having XenServer, and the software itself would run in a VM on that machine.