Backup Copy job with GFS to Linux repository

[corby]

Hello,
We just started using backup copy jobs, specifically so we can use the GFS feature.

Our target is using Ubuntu Linux with a Directly Attatched ZFS filesystem and presently has a CIFS share.

The GFS appears to be working, but it takes a long time and our 1GB connection is saturated during the process.

The user guide talks about using "Linux server with local, directly attached storage or mounted NFS" and says that "Veeam Backup & Replication deploys and starts the Veeam transport service on the repository"

My own Linux skills are pretty weak. I had a co-worker set up the current Ubuntu server with the CIFS share. Would there be a significant improvement if we creating an NFS share instead of the CIFS share? Will the Veeam Transport service configure itself if we create a backup respository on the NFS share? Is Ubuntu supported in this scenario? Can we use our existing data that is currently in the CIFS share if we convert it to an NFS share. Is there more documentation about this type of configuration?

Sorry for so many questions. I'm willing to try and make this all work if the end result is a drastic speed improvement, but I'm hesitant to try if the results aren't greatly improved and we are risking breaking a working, but sub-optimal configuration.

Thanks

[danswartz]

It's not entirely clear what your current setup is. It sounds like you have a ubuntu server with a NFS share from elsewhere (a NAS?) and that ubuntu server is the repository? If so, is it re-sharing the NFS data via CIFS? If so, that would suck, performance-wise, I would think. If you just treat the NFS data mounted on the ubuntu server as 'local storage', you would then give the ubuntu server to Veeam B&R as a backup repository, and it should 'just work'. If you are in fact re-sharing an NFS share via CIFS, you should be able to create the ubuntu server as a linux server, create a backup repository on that server with the pathname of the NFS share, and have B&R scan that NFS directory, and voila. You then change any jobs to use the new repository, and the delete the old CIFS repository. Does this all make sense to you?

[danswartz]

Also, not quite sure what part GFS plays in this?

[corby]

Hi Dan,

I didn't build the server, the storage is a jbod rack, directly attached to an Ubuntu box. The jbod is formatted using ZFS and then shared. I believe the person that built it needed a CIFS share for something else, so he installed SAMBA. He has far more storage available than he needs, so he is allowing me to use space on the existing CIFS share. I'm not sure what you mean by re-sharing an NFS share via CIFS. Are you suggesting that the share also exists as NFS and CIFS is layered on top of it?

GFS is a factor because it looks like all of the work to create transforms is occurring on the Veeam server itself and huge amount of I/O is going across a 1GB connection. I'm asking if NFS is used, would the processing to perform the transform then be running on the Ubuntu box?. The manual says "Veeam deploys and and starts the Veeam transport service on the repository". I'm really sure what that means, but it sounds like they might be saying the transform work would be done on the ubuntu box and therefore be much faster and would reduce the I/O across the 1GB connection.

Then if the CIFS share was replaced by an NFS share, would the existing backup data (now with a new repository) be used, or would a new chain of backup copies be created?

I hope I'm making sense.

Thanks

[veremin]

If those disks are directly attached to the Linux machine, just add it as Linux Server to a backup console, and assign repository role on it. In this case, all activity will be performed by Linux machine, where in case of CIFS share everything is done on the so-called gateway server (this role is assigned to a backup server, by default). Thanks.

[foggy]

Also, if you copy existing files to the new repository and point/map the jobs to them, the backup chain will be continued.

[corby]

Thank you both.

I had forgotten to ask...will a regular user that has read/write access to the NFS share on the Linux box be permitted to deploy the transport service to the repository?

[foggy]

The user also should be able to login via SSH and execute programs (to deploy our data mover agent).

[corby]

Ok...I can login via SSH. Is there an executable file I can manually try to see if it works? (I don't have an NFS share yet, waiting on the system's owner who won't be available until next week).

[veremin]

Can you add this server to a backup console as linux server? During this procedure our datamover should be installed. Given the process goes smoothly, the specified user has all required permissions.

[corby]

Indeed. That's what I did and it appears to work. It was a pleasant surprise to see all the steps automatically run.

Now I need to figure out how to convert an existing CIFS job to use NFS while maintaining my existing data, but I think that would be another topic or a call to support. A quick test shows that an attempt to convert the job will result in a new backup folder with _1 appended to it, and new backups being created.

thank you very much.

[foggy]

You would need to move backups to a new repository.