Best way to copy backups on Synology NAS to external drive

[ValiantMartian]

I have Veeam Agent backing up workstations to a NAS on-site (Synology Rackstation RS818+ as an SMB repository type). I want to get the most recent restore point onto an external drive to physically take off site every week or so. There are USB/eSATA ports right on the NAS that I could connect an external drive to.

Anyone have experience doing this on a Synology NAS? Am I able to make a USB drive visible to Veeam, and then add it as a new target for a "Backup Copy" job, or is there a better way?

[PetrM]

Hello,

am I able to make a USB drive visible to Veeam, and then add it as a new target for a "Backup Copy" job

I think that's exactly what you need to do, just add this drive as a repository, for example by creating a new folder and point backup copy job to it.

Thanks!

[ValiantMartian]

Thanks! I was able to add a shared folder on the USB drive from within the Synology OS (DSM). I am running a backup copy job to it right now. This does seem to work, but data copies FROM the NAS over to the Veeam server, then back onto the USB on the same NAS, so it seems like a lot of wasted processing, but I'm guessing this is the only way. Unless perhaps I can find/make a script to run right on the NAS that will copy the newest VBK from each workstation onto the USB drive...would I have functioning backups via an Import within Veeam if I could find a way to do this, or does everything really have to be copied by the Veeam server?

[Regnor]

Of course you could do scripting or task scheduling to copy the backups from the NAS to the external drive, but I wouldn't recommend to do so.
When the script fails or has some kind of logical error, you could end up with nothing copied on that drive. It's better to let Veeam do the job, while the process will be slower, you will have a better stability and visibility.

[PetrM]

+1 to the previous comment. In theory, these scripts can work and you can import backups later but please keep in mind that our QA do not test these scenarios explicitly, there are no guarantees that you won't encounter some corner cases with the script itself, with import etc., therefore we cannot consider it as a solid approach. But the backup copy job is designed exactly for the purpose to comply with 3-2-1 rule and I'd recommend to use backup copy.

The "wasted" processing exists due to the current architecture: the Data Mover on the gateway server needs to read data from one repository and write data to another one. I'd say that it's not a big issue as long as data is processed within the defined backup window and there is no negative impact for other services in your infrastructure.

Thanks!