Changed File Copy behaviour?

[Matts N]

Hello,
I mostly use File Copy to have a second copy of the configuration backup on a second server, but now I also have a case where File Copy is the only way to get a copy of a Windows Agent backup. For configuration backup copy, I always set the configuration backup repository as source (I use a dedicated repo for config backup, so no other files to worry about) and target a similarly dedicated repo on another server. For the agent backup file copy I set the folder in the repo as source.

In the past this lead to the target always being identical to source. That is, if I had 15 files in source, I would end up with 15 files on target. The file copy purged files from target that were no longer in source, so didn't have to worry about target growing uncontrolled. But from version 10.0.4854 P20201202 it seems this behaviour has changed. Now the target is not purged, it keeps growing, just adding the files from the source.

Is this change intentional? I sure hope not, because if it is, I now have to come up with some way to purge unwanted files...

TIA!

Matts

[foggy]

Hi Matts, will check whether the change was intentional and get back. Meanwhile, haven't you thought of using a backup copy job instead?

[Matts N]

Hello Foggy,
As far as I know you can't use a copy job for the VBR internal backup, can you? That would be a miss on my part.

As for the other backup, since it is a client side initiated and only stored on VBR, that is in no way controlled by the VBR server, it is not possible to create a copy job either. I tried, but the backups are not visible as a source.

Backup copy is always first choice, but when not possible file copy it is.

// Matts

[foggy]

Hi Matts, sorry for the delay with this - now I'm a bit confused as it looks like the file copy job never synced file deletions from source to target - just overwrote the existing files and appended the new ones. Syncing deletions would mean deleting a file backup in case you accidentally delete or corrupt some file on the source, so not the best strategy for backup software. Are you positive it was really the case in your setup?

[Matts N]

Hello Foggy,
I am more and more beginning to question my memory on this, to be honest. So at the moment, no, I am not sure at all.

Any chance we could have an option for that in the file copy job? A selection to keep them in sync or not? Feels a bit backwards to add scheduled scripts that deletes all files older than a number of days, if the backup software could do it for us. I do understand this is probably a much bigger change in code than it seems, so I have no real hope for that.

// Matts

[foggy]

We can file that as a feature request but judging on the priority it has low chances to get implemented in the foreseeable future. Thanks!