Backup Copy on different Backup Server

[georgbrunner]

I've multiple backup servers on remote sites where I perform local backups. After the local backups complete i do a backup copy to my HQ-Backup-Server in company headquarters.
The backup copy is performed to a SMB share on the HQ-Backup-Server to limit the permissions the remote backup server needs to perform the copy.

Now I'd like perform a backup copy of "received" backup copies on the HQ-Backup-Server to tape and to imutable repository.
This does not seem to be possible because the HQ-Backup-Server is not aware of the backup-jobs of the server of the remote server.

I could do a file-backup and file-to-tape of the backup-share but this uses a lot more space than backup copies usally need.

Am I missing something?

[Mildur]

Hello Georg,

The backups on the SMB share need to be mapped to a job in order to use backup-to-tape or copy jobs.

May I ask why you are not using a single backup server to manage local proxies, repositories, and backup jobs on all remote sites?
This approach would allow you to copy the backups directly to the hardened repository and then write them to tape.
It must also make backup server management (monitoring, updates) much simpler by using a single deployment.

Another option, available for larger enterprise organizations, is to use Veeam Cloud Connect for Enterprise. This option must be requested and approved by your local Veeam Sales Team.
Cloud Connect allows you to receive the backups via a copy job and then use a "Tenant-Backup-To-Tape" job to write the backup files to tape.

Best,
Fabian

[maruv]

I've multiple backup servers on remote sites where I perform local backups. After the local backups complete i do a backup copy to my HQ-Backup-Server in company headquarters.
The backup copy is performed to a SMB share on the HQ-Backup-Server to limit the permissions the remote backup server needs to perform the copy.

Now I'd like perform a backup copy of "received" backup copies on the HQ-Backup-Server to tape and to imutable repository.
This does not seem to be possible because the HQ-Backup-Server is not aware of the backup-jobs of the server of the remote server.

I could do a file-backup and file-to-tape of the backup-share but this uses a lot more space than backup copies usally need.
Utilizing it support for nonprofit organizations like those offered by Digiscorp, is crucial for effective data management. Their affordable solutions can help ensure reliable backups for systems like the HQ-Backup-Server. With expert assistance, non-profits can enhance their data security and streamline backup processes, allowing them to focus on their core missions.
Am I missing something?

It sounds like you have a solid backup strategy in place with multiple remote servers and your HQ-Backup-Server. However, the challenge you're facing with tape backups and immutable repositories is common. Since the HQ-Backup-Server isn’t aware of the remote backup jobs, you might consider implementing a more centralized backup management solution that can recognize and track these jobs. Alternatively, you could explore using backup software that allows for incremental backups to tape, which would help reduce space usage compared to full file backups. Another option is to configure a scheduled job that manages the backup copies more efficiently.

[georgbrunner]

Thanks for your answers..
Currently the central backup-server doesn't have nor need admin-permissions on the remote sites and remote backup servers. I'd like to keep it that way.
Also I don't see an option to keep recent restore backups on the remote proxies for fast restore. So there would be a bandwith limit in restore scenarios.
So yes, I could implement more non-veeam scheduled jobs or I could migrate to another backup solution. I could wait for a Veeam-integrated solution like file-based-copy to immutable (with automatic retention).
hm...

[petesteven]

Even if you have a centralised backup server, you can still have a local repository at each location. You can then also create a backup copy to HQ from this local repo.

You may even be able to continue using the current local repos. Uninstall the VBR on the local server. In addition to the workloads, add the local server as a proxy and repo to the central VBR. Then you can create the backup jobs for the site and select the local repo as the primary backup target and use the old backups with a ‘map backup’ in the job as a basis.
Then create the backup copy job to HQ and then you can create the tape job for all locations via a single tape library.