Buffalo Terastation TS-RIX4.0/R5
-
@brianlittlejohn said:
The user manual is also on Buffalo's website. It looks like it is an ISCSI unit only.
I had no idea that Buffalo had a pure SAN unit. That's a good bit of reference material for all of those "that's a NAS, not a SAN, people."
-
@scottalanmiller I had no idea either.
-
Well I don't think that will work then.
Guess it's onto other plans.
-
I think that it is time for that stuff to get retired.
-
@scottalanmiller Yep, looks that way.
-
These days repurposing old hardware, especially storage, rarely has value.
-
If I did want to use an ISCSI target Synology does have a pretty straight forward guide to setting it up.
In this setup, I'd have to build a backup VM on the ISCSI device directly. Which is far less than ideal.
if the device goes offline, I'd lose all backup capabilities until it's restored.
-
@DustinB3403 said:
If I did want to use an ISCSI target Synology does have a pretty straight forward guide to setting it up.
In this setup, I'd have to build a backup VM on the ISCSI device directly.
Yup, should work fine as long as the gear is still good.
-
@DustinB3403 said:
In this setup, I'd have to build a backup VM on the ISCSI device directly. Which is far less than ideal.
if the device goes offline, I'd lose all backup capabilities until it's restored.
Why would you have to create a VM on it directly? Sure it might not be good to ISCSI mount it to an existing VM, but it's definitely possible.
-
This device can only be attached to XenServer as an ISCSI device, as DAS storage.
So with following best practice, and having XS run from a USB drive and then using the host or DAS storage for the working VM's. Meaning if the connection breaks between the host and the ISCSI device, you're VM's are down until it's repaired.
This isn't an ideal way of setting it up, and adds complexity for no gain.
-
@DustinB3403 said:
This device can only be attached to XenServer as an ISCSI device, as DAS storage.
DAS or SAN. XS can't tell.
-
@DustinB3403 said:
This device can only be attached to XenServer as an ISCSI device, as DAS storage.
So with following best practice, and having XS run from a USB drive and then using the host or DAS storage for the working VM's. Meaning if the connection breaks between the host and the ISCSI device, you're VM's are down until it's repaired.
This isn't an ideal way of setting it up, and adds complexity for no gain.
How does ISCSI make any difference here? You were saying you wanted SMB/CIFS or NFS. If the network connection goes down, you still don't have access to your backups until you fix it. I don't see this as worse other than you have to have a VM for the connection.
But instead of installing a VM on the iSCSI storage, you could install a VM on the XS other storage, then mount the Terastation via iSCSI inside that VM. The VM would run with the normal SR performance of the rest of the VMs, and only the backup storage would be running over the iSCSI connection.
-
Another way to look at this - you could get a two NIC Raspberry Pi, install Linux, one port to the Terastation (iSCSI) and the other to the network. Now you've just turned it into a NAS, assuming you've shared it with NFS or CIFS.
-
@Dashrender That adds even more complexity to the setup though.
And more Failure points.
-
@DustinB3403 said:
@Dashrender That adds even more complexity to the setup though.
And more Failure points.
Sure, the R-Pi does, but installing the VM on the main SR doesn't. The VM itself would only go down if the host goes down and wouldn't be affected by the network connection - but we're talking about backups.. so do we really care?
As for the two ways to do it 1) mount iSCSI to XS directly, install VM on iSCSI device or 2) in VM on XS RS, mount ISCSI inside VM - does the performance difference matter here?
-
The performance of the Pi doesn't matter, but the complexity does.
That simply is not a viable option in my opinion.
-
@DustinB3403 said:
The performance of the Pi doesn't matter, but the complexity does.
That simply is not a viable option in my opinion.
The second half of my previous post has nothing to do with a Pi. that would be option 3. And I agree, it's probably not with the hassle/complexity of bothering.
