Solved

Linux hardened repository - follow up and next steps

  • 1 November 2021
  • 4 comments
  • 281 views

Userlevel 2

Following on from the excellent advice on what kind of storage server (and direct attached storage within) to use for a hardened Linux repository, may I push my luck to ask for some more advise or where to go next. 

Presuming I can get my hands on a suitable storage server and storage (as recommended) could anyone shed some light on how we’d need to set this up so that Veeam is able to back up the data on our Infortrend SAN. 

Here’s some further details of our config.

We have a Windows server in our (remote) data centre that is running Veeam B&R v11. It is currently just making some physical backups of critical Windows and Linux hosts. These hosts are physically located in our office and there is a decent enough secure connection to make these backups over the line to the Veeam server in the data centre.

However, I want to expand our use of Veeam to make regular backups of the TB’s of data on our Infortrend SAN which is also based in our office and this is where my lack of experience/knowledge of Veeam is hurting.

The amount of data on our SAN is too great to be dragged across the line by the Veeam server in the data centre. 

What would I need in our office location (apart from the hardened Linux storage server) so that our Veeam server is able to backup the SAN data without having to drag it to the data centre? Is there some kind of Veeam agent/server required between the primary Veeam server and the Linux storage server. If so, should this run on the Linux storage server or should it run on a separate server Veeam “middle-man” server?

That kind of leads on to how Veeam is able to see and backup the data from the SAN. We’d like to be doing file/directory level backups and I’m not sure what the best approach to take is.

We currently expose the SAN data on a number of Linux servers as either iscsi volumes or NFS shares.

Should we mount the SAN storage on the new Linux storage server as NFS shares where the Veeam server/agent can access it to be able to back it up or is there a better option such as iscsi, samba etc?

Of course, I could be going down the completely wrong road and if so, are there better options to backing up this SAN data using Veeam?

Apologies for all the questions and any dumbassery on my part.

icon

Best answer by DChiavari 3 November 2021, 07:55

View original

4 comments

Userlevel 7
Badge +20

If you were to expose the SAN to the Windows server as iSCSI and then add it as a repository you could then set up a File Copy job if you don’t want to copy the actual Veeam backup files (VBK, VIB).  You could target the Linux repository for this and allow Veeam to move the data over.

File Copy Jobs here - Creating File Copy Jobs - User Guide for VMware vSphere (veeam.com)

Userlevel 2

Hi Chris, thanks for the info… But would that mean that the files/directories to be backed up from the SAN will get dragged to the primary Veeam (Windows) server in the data centre before being pushed back down to the Linux repo server in the office?

Userlevel 7
Badge +20

Hi Chris, thanks for the info… But would that mean that the files/directories to be backed up from the SAN will get dragged to the primary Veeam (Windows) server in the data centre before being pushed back down to the Linux repo server in the office?

They would not get dragged but the Windows Veeam server would process them to send them to the Linux repo.  Veeam would updated the inventory of the files on the Veeam server once you add the repo.  The files will still reside on the SAN itself and not specifically move to the Veeam server just be processed.

Userlevel 6
Badge +7

You can easily have a Veeam Backup Server which is “remote” and never takes part in any actual data moving - it manages the various roles/machines (proxy, repository, etc.), it’s only control traffic. Just make sure the Backup Server does not also act as a proxy/repository.

The data flow for all Veeam backup operations never includes the Veeam Backup Server:

  • VM backup: Backup Proxy → Repository
  • Agents: Agent → Repository
  • NAS Backup: File proxy → Repository 
  • Backup Copy Job: Source Repository → Target Repository

Side note: keep an eye on the gateway setting if you use NAS share repositories or dedupe appliances, as with “Automatic” selection the Backup Server might be selected to perform the gateway role, which is basically the receiving data mover. You can assign this role to a specific server, in the same site as the other data movers. 

In your scenario, if I understand correctly, this SAN exposes data in different ways to different machines: file shares, mounted LUNs. You can install Veeam Agents on the machines where LUNs are mounted and use NAS Backup for file shares. That would be rows #2 and #3 in the list above.

You can have the SAN, Veeam Agents, File proxies and Repository in the office and just the Veeam Backup Server in the remote data center. Backup data would never go across the WAN.

Comment