Scheduled copy

[Liberty4All]

When using scheduled copy I am noticing that a copy of an initial backup I have run takes approximately 5 hours. After doing a second backup when I do the scheduled copy it still takes 5 hours. The initial was one 16G backup file. The second had the new file with the changes which were about 1G, and the original file seems to be slightly modified. How come the scheduled copy takes the same time when I would think it would only do the changes? My understanding from the Demo I saw was that it would only send the changes over the wire. Can you clarify what happens? Thank you,

Paul

[Gostev]

Paul, are you talking about backup and incremental backup cycles? We have "scheduled file copy" jobs too, but what you are describing matches backup instead of scheduled copies.

[Liberty4All]

Gostev,
What I am doing is a VCB backup of 5 windows server nightly. The initial job creates a 16GB backup file. I then want to use scheduled copy to send it to a remote server for redundancy. The scheduled copy of the 16GB takes 5 hours. The second night my backup runs and the 16GB file is slightly modified and there is now another file that is 1GB that I am sure were the changes. When my second scheduled copy runs it still takes 5 hours to send to my remote server again. Shouldn't it take less than an hour to send 1GB if the 16GB took 5? The real issue is that I was told during a demo that only the changes would be sent over the wire using scheduled copy on a repeating bakcup job. So I want to know why it is taking so long if that is the case? Thank you,

Paul

[Vitaliy S.]

Hello Paul,

Basically, we do really use incremental changed blocks transfer during a backup/replica job, so only changed blocks are transferred during second/third (and so on) run of the backup/replica job session. As I correctly understood you, you're doing VCB backups every night, so it means only changes are transferred to your target storage every night, as for scheduled copy, it just copies the files you've selected to the destination storage, it doesn't send the changes, it sends the whole files initially, so incremetal changes refer only to backup/replica jobs.

As for your situation, if you want a redundancy, you can just copy a VBK file of your whole backup job (to reduce copying time), cause the VBK file is the most recent backup state, and if you have a situation when your primary VM gets damaged, your backup storage also gets corrupted, you can easily restore to the most recent state of the VM by importing your copied VBK file to Veeam Backup and Replication console.

[Liberty4All]

That clears it up for me. Thank you for your help.

[Gostev]

Paul, if you really need to perform incremental copies, you can consider using DFS-R or RSYNC as described in the following thread. Hope this helps.