CX-300 Backup Time Improvements

If you attach the luns to a 2nd server as well, you will run into problems. A better way to do this is making clones (performance wise this is better, since the original luns aren't impacted) or snapshots. The clone / snap should then be attached to the backup host and since this is another "disk" than the original one, you should be fine here. It does hold an exact copy of your data though and from 1 specific point in time as well, so IMHO this way of backup up your data is even better than simply copying it from a host using agents. You should however take special care if you're running databases on the lun you're cloning / snapping, since it needs to be consistent at that moment, so think about stoping the database or put it into something like a hot backup mode state. Right after the clone or snap is there, you can continue the database.

You should NOT present LUNs being accessed by a host to another host simultaneously! The only time this is supported is if the hosts are a cluster and have a drive arbitration mechanism or if the LUNs are being replicated using an array/fabric based solution (SANCopy, RecoverPoint, et.).

As RRR pointed out, your best option is to use clones or snaps of production. Using a snap of production for backups is a common practice during periods of low production host i/o as all of the reads will be coming from the production LUNs.