The Textbook Things Gone Wrong in IT Thread
-
The CPU and memory were bare minimums to have from xbyte so... why not.
As for the drives they are physical file shares at the moment... so yeah....
-
@DustinB3403 said:
We'd then have to move all of our data over to it, remap our shares, and have our backup appliance backup a single server...
But never do this. It's all just a silly exercise to show how easy it would be to build an SSD SAN and/or NAS device.
You would always do your project with local storage. Same SSDs, same RAID 5. But never SAN or NAS.
-
@DustinB3403 said:
As for the drives they are physical file shares at the moment... so yeah....
Fix that too by going to a file server VM on the same device.
-
So build a massive XenServer with ton's of local SSD storage and then migrate the data into the VM. Consolidating it all into a single VM.
I'd really need a much larger CIFS file server to make my backups then ..... haha
-
@DustinB3403 said:
I'd really need a much larger CIFS file server to make my backups then ..... haha
Total backup size should not change from what you have to backup already. Just all from one place rather than from multiple.
-
@DustinB3403 said:
So build a massive XenServer with ton's of local SSD storage and then migrate the data into the VM. Consolidating it all into a single VM.
XenServer or HyperV, yes. One big server, one bit RAID 5 SSD array, everything a VM. Insanely fast (tens or hundreds of times faster than the same setup with a NAS/SAN connection), extremely reliable (more reliable than anything else discussed here) for super cheap and incredibly easy to manage.
-
Its a huge win, safe, fast and reliable while saving 90% of the money.
-
True, and I'd still be using the same appliance I have, and I suppose I could have 2 partitions on the VM the "C" drive for the OS, and a "D" for data with shares under it.
-
@DustinB3403 said:
True, and I'd still be using the same appliance I have, and I suppose I could have 2 partitions on the VM the "C" drive for the OS, and a "D" for data with shares under it.
For a file server yes you would often partition, although generally not necessary. For most things, like an app server, you would not even partition.
-
I wonder if I could use NAUBackup to snapshot a specific partition rather than the entire VM.
-
@DustinB3403 said:
I wonder if I could use NAUBackup to snapshot a specific partition rather than the entire VM.
You would not likely want to do that. You want your VM in sync with itself.
-
The reason I ask is so that should something afflict the VM C partition that I have some way to recover more rapidly that our Buffalo drive.
-
Without having to have a 4TB Snapshot sitting there, just waiting to be used.
-
@DustinB3403 said:
Without having to have a 4TB Snapshot sitting there, just waiting to be used.
If you recover the OS and not the data, what does that fix?
-
@DustinB3403 said:
The reason I ask is so that should something afflict the VM C partition that I have some way to recover more rapidly that our Buffalo drive.
You might want a faster restore mechanism. Is your file server currently a full 4TB? How do you recover currently?
-
There are 2 servers acting as file shares. The backup mechanism is via ShadowProtect
If I were going to propose this I would scale up the CPU and RAM to the max that the board can support as I'd also say virtualize everything onto this host. to consolidate our server footprint.
-
Well maybe not the maximum.
-
@DustinB3403 said:
There are 2 servers acting as file shares. The backup mechanism is via ShadowProtect
They are very good for file backups!
-
The data partition could be backup via ShadowProtect.
That or I scale up the CIFS server that is being used on our small XenServer to backup the few less critical VM's I have running there to be large enough to hold 12 TB of data.
I'd probably have to build one for that purpose as well as trunk a few NIC's to get a good throughput.
-
The goal is to get off of equipment that is at its EoWarranty.
