Best way to attach a NAS which is switched off most of the time

Hi @Karl Kunze ,

• what is the connection to the NAS? SMB, NFS?
  •  Don’t use it for Veeam Repository, it’s too unreliable.
  • Use an iSCSI connection if it’s possible. It’s much more reliable.
• Why is the NAS switched off the most time?
  • Cost issues? 
  • AirGap for your Backups? 
    • Not the best idea, because a SMB connected repository has no immutability and your backups are at risk at least at the next time the NAS is powered on.

As you mentioned yourself, there are too many painpoints in your setup, don’t do it.

If the NAS is being connected via SMB or NFS, there shouldn’t be too much of an issue as Veeam will connect to the device when the job runs since it’s a network protocol.  However, if you’re connecting via ISCSI, then that can be somewhat painful as Windows doesn’t always play nice with a missing drive when the NAS is off, and won’t necessarily reconnect automatically when the NAS is powered back on.

That said, if you are using ISCSI, be sure to pass the ISCSI traffic through your hosts to the VM using the Windows ISCSI initiator and MPIO if applicable within the VM.  I do not recommend using RDM’s and attaching the NAS to the host (IYKYK).  This generally works, but if the NAS is offline and your VM is powered off and back on, and that backing storage is not available, the backup server won’t boot because it can’t connect to that storage device.  That can create some pain points.

My assumption as to why you’re doing this is to create an air-gap effect.  Obviously there will be pain points.  My general suggestion is to instead use a Veeam Hardened Repository or Object Storage.  If you do go the route of a VHR attaching to the NAS via ISCSI, it’s going to be recommended that the VHR sit on a separate server, not a VM as console access to a VHR VM creates a security risk.

If it’s not for air-gapping, I’m curious as to the reasoning.

The NAS is switched off most of the time as a long-time storage with a little air-gapping in mind. The NAS served for a different purpose but is now free. That is where the idea with using it as an additional backup-device came from.

Right now it is not attached at all (after doing my tests with finding out about the pain-points). I am free to choose the connection-type, whatever serves best without hindering the normal operations.

Regards

Karl

My favorite way to operate this would be:

• take a small physical server
• attach the NAS via iSCSI to it
• install the server with the Hardened Repo ISO (you can find the link to it here in community)
• configure a hardened Repository on your Veeam server and use the advantages of Immutability and a completely separated repository server.

Difference to your approach is that the NAS would not be switched off. But the reliability and security advantages would outweigh this in my opinion...

Hmmm.

Having the NAS switched off “with plug pulled” feels more like my way to go.

Just an additional question: There is no way to backup stuff with keeipng some track without repository?

I looked through the options and “Replication” and “VM Copy” seem to be the only ways to backup without having a locally mapped drive/path at the Veeam-Server.

Regards

Karl

Ok, Replication is no backup, it's a disaster recovery method. With this you can replicate your VMs to the same or another cluster.

VM Copy can copy the data of your VMs to a path on a server defined as managed server in your Veeam environment. With this you cannot save multiple restore points of your VMs, each new VM Copy of a VM overwrites the last one.

When you want that Veeam maintains multiple restore points of your data and administers the jobe and backups in the configuration database you need a backup repository.

You can do your approach and write your backups to a SMB share and switch off your NAS each day after backup.

It's just not the recommended way...

Thanks for all the input.

I am not sure about which way to go.

But all your answers helped to narrow down the vector of approach.

Regards

Karl