I am using Robocopy to copy some VBR synthetic full backup (as VBR going to remove reverse incremental backup).

So the idea is to retail the oldest Synthetic full backup (required by forward incremental backup), while only retaining the 2 latest synthetic full backup (created daily as additional task).

But the issue is that move is immediate but robocopy takes hours (as robocopy does a copy then delete, not a “move”).

Is there a way to “move” the files faster ? Thanks in advance…

So my batch file is as follow…
MD \VBR_server\Veeam\temp
robocopy “\VBR_server\Veeam\Daily-1” \VBR_server\Veeam\temp" *.vbk /minage:2 /maxage:5 /mov

6 Spice ups

Powershell?

Something like this:

Get-ChildItem -Path "\VBR_server\Veeam\Daily-1\*.vbk" | 
    where-object {$_.LastWriteTime -ge (get-date).AddDays(-5) -and $_.LastWriteTime -le (get-date).AddDays(-2) } | 
    move-item -destination "\VBR_server\Veeam\temp"
6 Spice ups

To test it, just remove the | move-item -destination "\VBR_server\Veeam\temp" and it will output a list of what it would move.

4 Spice ups

The weird or stupid thing is that I can only run .bat or .exe as “script after backup job completes” as to “schedule” the move after the backup job completes. At least we do not delete (or move) anything if the backup job fails (for any reason).

Unless there is a way for a .bat to call a .ps ??
Then I would have like a VBR_clear.bat that calls out VBR_move.PS then the script is \VBR_Server\Veeam\VBR_clear.bat

2 Spice ups

Is it possible that like patch file I have several “paragraphs” as to also move *.vbr from daily-1 and daily-2 (I may have like Daily-1 to Daily-10) ?

Get-ChildItem -Path “\VBR_server\Veeam\Daily-1*.vbk” |
where-object {$.LastWriteTime -ge (get-date).AddDays(-5) -and $.LastWriteTime -le (get-date).AddDays(-2) } |
move-item -destination “\VBR_server\Veeam\temp”

Get-ChildItem -Path “\VBR_server\Veeam\Daily-2*.vbk” |
where-object {$.LastWriteTime -ge (get-date).AddDays(-5) -and $.LastWriteTime -le (get-date).AddDays(-2) } |
move-item -destination “\VBR_server\Veeam\temp”

3 Spice ups

Should be able to launch it from a batch file.

powershell -file C:\scripts\myscript.ps1

5 Spice ups

If your moves are on the same server, use drive letters and local paths, not UNC paths.

Also note that all move operations on Windows, including PowerShell, CMD, the GUI and 3rd party tools are copy-then-delete commands.

2 Spice ups

Lower the retry and wait time defaults that are set in Robocopy:
robocopy -?
{about a page down in the “book of arguments” for RoboCopy}
:: Retry Options :
::
/R:n :: number of Retries on failed copies: default 1 million.
/W:n :: Wait time between retries: default is 30 seconds.

I set mine to /R:3 and /W:3 - adjust yours to suit your needs/servers best results.

2 Spice ups

A file “move” is altering the path or name within a volume. This is very fast as it is just changing metadata and pointers.

If you are changing the volume, then data must be copied from the volume where it exists, to another, where it does not yet exist in any form.

This is the default behaviour exhibited with the File Explorer GUI in Windows. If you drag files/folder from one volume to another, data is copied and then deleted. If it is within the same volume then data is “moved”. The metadata and file pointers are updated to make it appear in the new folder. No actual data is copied.

Robocopy only copies data, it does not “move”. If you want to “move” use Powershell as suggested above by @PatrickFarrell, and the caveats mentioned by @Rod-IT (run locally on the server hosting the Veeam storage, and use drive letters to improve performance).

You can use the old command-prompt “move” command if you are limited to using a .bat batch file to script the action.

2 Spice ups

As long as you’re copying to the same filesystem, you could create a hard link.

mklink /h <link> <target>

Or, in PowerShell:

New-Item -ItemType HardLink -Path $linkName -Target $targetPath

Note that modification of the file affects both “files” because both paths point to the same inode (data block on media). But deleting either does not delete the other; it only deletes the pointer.

2 Spice ups
1 Spice up

Bro…thanks…but the issue is that I have to place that “script” on the backup task (run after backup successfully completes) so I need the UNC path to move files within the backup repository.

This is the workaround as VBR is going to depreciate reverse incremental backup (where you get the latest full backup) as compare to forward incremental backup where the synthetic full is created at the end of retention period (but can also create daily synthetic full backups).

So I would need to move TBs of “full backups” to a folder then delete that folder…else the current backup repository will be full within a week (5 days to be exact).

The “move” operations (using move or PS with thanks to @PatrickFarrell) will not copy then delete but change the metadata as it is on the same volume, unlike robocopy.

1 Spice up

Thanks, I am aware how Veeam operates.

Glad you have a solution.

1 Spice up

But I am still grasping the change from Reverse Increments…and probably also from how forward increment works, mainly on the creation of the synthetic full which is “part of the active job”.

1 Spice up

Typical recommendations are to use Forward Incremental + Weekly Synthetic Fulls + Monthly Active Fulls.

You can look at the comparison here based on your backup sizes, VM uses and backend storage for backups.

3 Spice ups