Skip to main content
  • EN

I created a previous post on Nimble Storage Integration with Veeam, discussing how you can potentially recover data even if a backup job’s Deleted VMs retention setting has passed. You can view the post here. For this post, I want to continue discussing Nimble Storage Integration, but provide you a security measure you can implement when configuring your Windows Proxies for Storage Integration or Direct SAN, as Veeam requires a Proxy to be configured with Direct SAN (or ‘Automatic Selection’) when using Backup from Storage Snapshots (BfSS).

A fellow Vanguard and I have occasional on-going discussions on how to best secure Windows Backup Proxies using Nimble (now called whatever...Alletra? 🙄 ) for Storage Integration. Several mos ago, we were trying to determine how best to present production storage to a Proxy, exposing as minimal amount of Nimble Volumes to a Windows OS as possible to prevent a catastrophic event, beit admin error or mal-intent. He and I were curious if Volumes used for Datastores really needed to be presented to the Windows Proxy OS. According to Veeam’s VMware User Guide here, when configuring your Proxy for Direct SAN mode (needed for BfSS), they state “SAN storage volumes presented as VMware datastores must be exposed to the OS of the backup proxy which works in the Direct SAN access transport mode.” I cannot speak for other storage systems/vendors, but I would hope it’s the same for them. For Nimble Volumes you use as Datastores, you do ***not*** need to present these Datastore Volumes to your Windows Proxy OS. All you need to do is configure access for these Volume(s) on your Nimble array with the Proxy(ies) IQN; and, configure the access on the array to apply to just “Snapshots Only”.

I won’t go into the full Windows Backup Proxy configuration process, but setting up your Proxies for DirectSAN/BfSS, you add the Microsoft File & iSCSI Services as a feature/role, and also install Nimble Connection Manager (NCM) and Discovery address to present your Nimble Volumes to the server. When you configure access to your Volumes on your array, your Volumes are not shown as being ‘presented’ to the Backup Proxy. This is exactly what we want. For Volumes used as Repositories (if you use your Proxies like I do as a ‘combo’ Proxy/Repo box), you select to ‘connect’ those Volumes. For your Volumes used as (production) Datastore storage, they will not be shown in NCM and thus not presented to the Windows OS. mitigating the potential of data removal. Notice no ‘disconnected’ Volumes in NCM below (which would be shown with a red ‘x’ icon on the Volume instead of a green check mark); but rather only my Repo Volumes:
 

 

Hope this helps you in implementing better security measures when using Storage Integration in your Veeam environment.

Cheers!

This is a great post @coolsport00.  I remember the days of using Nimble Storage at my previous job and the NCM used to connect the volumes.  I am sure we gave it too much permission back then but it worked like a charm for fast backups.  LOL

Thanks @Chris.Childerhose . As you all can probably tell, I love Nimbles! (I won’t ever call them Alletra’s 😂 ).

Yeah who’s bright idea was to rename them to that??  Yes I would call them Nimble no matter what! :joy:

It was HPE’s idea of course. That should tell you all you need to know. Since they bought them a few yrs ago, you knew something like this was going to happen sooner or later.

It was HPE’s idea of course. That should tell you all you need to know. Since they bought them a few yrs ago, you knew something like this was going to happen sooner or later.

Had to fight so hard to get my current company to sell Nimble as they got a loan one, then HPE acquired them and you couldn’t even get an account activated as they said all systems between Nimble & HPE were as good as manual for months 😩 such nice kit though!

Thanks @Chris.Childerhose . As you all can probably tell, I love Nimbles! (I won’t ever call them Alletra’s 😂 ).

Know what you mean! I still say LeftHand instead of P4000/VSA/StoreVirtual :joy:

So, now I read the whole post. Thanks for sharing! In times of ransomware this is important increas in security!

Do I get it right: you just need to export volumes as “Snapshots only”? If so I am wondering why SANdirect mode would work. Veeam does not take a hardware snapshot for this.

 

So, now I read the whole post. Thanks for sharing! In times of ransomware this is important increas in security!

Do I get it right: you just need to export volumes as “Snapshots only”? If so I am wondering why SANdirect mode would work. Veeam does not take a hardware snapshot for this.

 

I believe this would work for backups as Veeam would trigger the storage snapshot and then mount that volume, but for restores you’d be failing over to network mode, unless you changed the permissions.

So, now I read the whole post. Thanks for sharing! In times of ransomware this is important increas in security!

Do I get it right: you just need to export volumes as “Snapshots only”? If so I am wondering why SANdirect mode would work. Veeam does not take a hardware snapshot for this.

 

I believe this would work for backups as Veeam would trigger the storage snapshot and then mount that volume, but for restores you’d be failing over to network mode, unless you changed the permissions.

Veeam is just able to trigger a snapshot when the array is added to VBR. Without that it is still possible to use SANdirect mode. So how could this work to export Snapshot only for direct mode?

Veeam does take a storage snap in this config. You have the IQN (i.e. “permissions) of the Proxy assigned to the Volume on the Nimble; the same Proxy is added explicitly for the b/u job in VBR, a Storage Snap is triggered, and then a backup taken off of this Snap.

Thanks for the article. I can definitely see the security benefit.

Curious to know how would this setup work if you have more than one Veeam proxy server in this configuration?

Would you keep the Nimble Volumes dedicated to each proxy server separately?

Reason I ask because I would imagine only one iSCSI initiator (i.e. veeam proxy) should access the iSCSI target (i.e. Nimble backup Volume) at a time. 

That is correct. Isolate the Volumes to a single Proxy. This is what I have in my environment. Obviously, this is a SPOF, but easily rectifiable if a Proxy goes down...just add the IQN of any working Proxy to the Nimble Volume to make the Volume available again.

Cheers!

Great post @coolsport00 , really nice to see new things.

Appreciate it @marcofabbri !

Great post @coolsport00

Alletra is Latin for “you wiil be assimilated”.  I’m pretty sure the HPE sales team that lost way too many 3Par sales to Nimble (before they got smart and bought them) drove the rename and is sitting back laughing this very minute.  If you can’t them buy them.  Left Hand who?  As Veeam increases their storage integration footprint across more and more vendors, I think this type of security precaution should be first priority during setup.  I’ve repaired literally hundreds of bad Veeam installs just for performance issues, it needs to become second nature now to start checking off the security boxes like this.

Interesting topic, I think we are talking about Backup from Storage Snapshot and not Direct San Access.

If you do not have the Veeam Enterprise Plus License, you may want to retrieve data through the proxy in Direct San Access mode and I believe that like for other storage you need to present the volume to the proxy and that’s why Veeam set the SAN Policy to Offline Shared.

If someone can tell me if I’m right or not ?

Best Regards.

Interesting topic, I think we are talking about Backup from Storage Snapshot and not Direct San Access.

If you do not have the Veeam Enterprise Plus License, you may want to retrieve data through the proxy in Direct San Access mode and I believe that like for other storage you need to present the volume to the proxy and that’s why Veeam set the SAN Policy to Offline Shared.

If someone can tell me if I’m right or not ?

Best Regards.

Yes you are correct on this as you present the LUNs to the proxy for access and then Veeam reads from them to take backups. You also need to enable the integration within your jobs too and ensure that the failback to normal method is also enabled to ensure jobs complete successful if it cannot access the volume for direct SAN.

Interesting topic, I think we are talking about Backup from Storage Snapshot and not Direct San Access.

If you do not have the Veeam Enterprise Plus License, you may want to retrieve data through the proxy in Direct San Access mode and I believe that like for other storage you need to present the volume to the proxy and that’s why Veeam set the SAN Policy to Offline Shared.

If someone can tell me if I’m right or not ?

Best Regards.

Without Enterprise Plus, you are able to do storage snapshot-only backups.

Interesting topic, I think we are talking about Backup from Storage Snapshot and not Direct San Access.

If you do not have the Veeam Enterprise Plus License, you may want to retrieve data through the proxy in Direct San Access mode and I believe that like for other storage you need to present the volume to the proxy and that’s why Veeam set the SAN Policy to Offline Shared.

If someone can tell me if I’m right or not ?

Best Regards.

Without Enterprise Plus, you are able to do storage snapshot-only backups.

Can still do Veeam Explorer for Storage Snapshots without Enterprise Plus also.

I am setting up an additional Veeam backup proxy and trying to resolve some inconsistencies within our environment related to storage snapshot-based backups.

We are using HPE Nimble and Alletra 6000 series storage arrays.

Each proxy has two IQNs: one includes "Microsoft" in the name and the other includes "Veeam" in the name:

  • iqn.xxxxx.xx.com.veeam:proxy02.tech.com
  • iqn.yyyyy-01.com.microsoft:proxy02.tech.com

I need clarification on the following points:

  • During a storage rescan, Veeam utilizes both IQNs. What functions are assigned to the Veeam initiator, and what functions are assigned to the Microsoft initiator?
  • When configuring iSCSI volume access on the storage array, should the initiator used by Veeam be given "Volume & Snapshot" access, or just "Snapshot Only" access?

I don't believe the initiators are differentiated per function as it will just check for access.

You could assign snapshot only for the Veeam one and then test to see.  It might leverage the MS one for access if needed.

I don't believe the initiators are differentiated per function as it will just check for access.

You could assign snapshot only for the Veeam one and then test to see.  It might leverage the MS one for access if needed.

i think 

  • Veeam Initiator (iqn.xxxxx.xx.com.veeam:proxy02.tech.com): This initiator is specifically used by Veeam Backup & Replication for storage rescans. During rescans, Veeam needs to discover and update information about your storage for backup purposes. This initiator allows Veeam to "see" the storage and its contents.

  • Microsoft Initiator (iqn.yyyyy-01.com.microsoft:proxy02.tech.com): This initiator is most likely used for backup from storage snapshots. When using Veeam with storage snapshots (created by the storage array itself, not Veeam), the Microsoft initiator allows Veeam to access and process those snapshots for backups.

I don't believe the initiators are differentiated per function as it will just check for access.

You could assign snapshot only for the Veeam one and then test to see.  It might leverage the MS one for access if needed.

i think 

  • Veeam Initiator (iqn.xxxxx.xx.com.veeam:proxy02.tech.com): This initiator is specifically used by Veeam Backup & Replication for storage rescans. During rescans, Veeam needs to discover and update information about your storage for backup purposes. This initiator allows Veeam to "see" the storage and its contents.

  • Microsoft Initiator (iqn.yyyyy-01.com.microsoft:proxy02.tech.com): This initiator is most likely used for backup from storage snapshots. When using Veeam with storage snapshots (created by the storage array itself, not Veeam), the Microsoft initiator allows Veeam to access and process those snapshots for backups.

This could be correct.  I have not used iSCSI with Veeam for a long time as we use FC where I work.  So only way is to test at this point and see how things go.

I am setting up an additional Veeam backup proxy and trying to resolve some inconsistencies within our environment related to storage snapshot-based backups.

We are using HPE Nimble and Alletra 6000 series storage arrays.

Each proxy has two IQNs: one includes "Microsoft" in the name and the other includes "Veeam" in the name:

  • iqn.xxxxx.xx.com.veeam:proxy02.tech.com
  • iqn.yyyyy-01.com.microsoft:proxy02.tech.com

I need clarification on the following points:

  • During a storage rescan, Veeam utilizes both IQNs. What functions are assigned to the Veeam initiator, and what functions are assigned to the Microsoft initiator?
  • When configuring iSCSI volume access on the storage array, should the initiator used by Veeam be given "Volume & Snapshot" access, or just "Snapshot Only" access?

@Nikks - why have you configured 2 IQNs on your Proxy? I guess you’re using Windows OS? Did you install Nimble Connection Manager on your Windows Proxy? You should only need 1 IQN for your Proxy. How I set mine up (& back when I wrote this, I was using Windows, but now I use Linux) is I installed the MS Initiator, the Nimble NCM, then in opened the Nimble NCM to get the ONE IQN. I then added that ONE IQN to the ACL (Access) to the Volumes. As for what connection type to configure for the Access → if you’re using BfSS, you only need to configure Snapshot Only; if you want to use DirectSAN, you have configure Volume & Snapshot.

Hope that helps.

Comment


Terms & Conditions