Using Robocopy on a share with Placeholders

[buzzbox]

Hi All,

We have a file share on a Win 2012 server where we, along with a Backup Exec to tape, also run a Robocopy script over to our backup server in a data centre.

What we noticed was, if a directory has a Placeholder of a file thats been archived, the file on the remote backup server does not get removed.

This causes the backup servers space to bloat up, using more disk space than it ideally should.

Is there any way to have Robocopy pick up on the fact that the Placeholder is not an actual file, and remove from the backup site?

This is our current robocopy script.

"\\localhost\share" "\\backup\share" /XA:O /ZB /mir /copyall /r:2 /w:2 /log:d:\logdirectory\logfile.log /ts /fp /ipg:10

We're discussing the idea of generating a list of Placeholder files, and removing them from the backup site before the Robocopy job runs, but we're not too sure how to go about this, or if its the best way to do it.

Any ideas or available Symantec tools that would help will be great!

Cheers!

[AndrewB]

i'm not a robocopy expert but if i understand correctly what you've essentially done here is an "incremental forever" copy job as a sort of DR process so yes, the behavior you describe would be expected when it comes to placeholders. perhaps an additional routine where once a week - or whatever frequency - you reset your backup server and do a new full copy to pick up the changes?

if you still want to go down the path of creating a list of placeholders and removing them from the DR site have a look at this thread where we discuss how to create that list https://www-secure.symantec.com/connect/forums/utility-create-file-listing-shows-offline-attribute

[buzzbox]

Hi Andrew,

Pretty much spot on!

As robocopy cant distinguish a placeholder from an actual file, it keeps the full sized file on the DR server intact which causes the bloat.

Thanks for that link to the powershell script, that is excellent!

I've also just discovered the March 2013 FSA server Consolidation white paper which i've started reading now, which is also great!

We did discuss the idea of reseting the DR server once a week / month or so, so we'll see how we go with this.

Cheers!

[AndrewB]

sure thing. keep us posted; i'm curious to know what you end up doing. 

[buzzbox]

Hi Andrew,

I was having a play with the powershell script when i noticed something.

I was testing that script against a directory that has long since been archived by the vault, so theyre all placeholders.

The script generated a list of all placeholder files just like i expected. As a test, i restored one file, ran the script again, but i still got the same result, all files were apparently placeholders, which wasnt right.

I then noticed that the attribute of the file i restored was no longer a ReparsePoint. I tried restoring a few more files, ran the script again, and noticed the ReparsePoint attribute for these files had also been removed.

I changed the script to change the the attribute check from this:

Get-ChildItem $fldr -recurse | Where-Object {$_.Attributes -ne 'offline'}

to this:

Get-ChildItem $fldr -recurse | Where-Object {$_.Attributes -like '*ReparsePoint*'}

This then gave me all the placeholders / stub files i was after.

So what we can do from here, is then parse this output through a script which will remove all those files from the DR site, which exist as complete files there.

If robocopy could copy the stubs / placeholders without downloading the file from the vault and sending that over to DR that would curb our bloating issue as well. From what i understand though, Robocopy cant do that without downloading the file.

[AndrewB · Accepted solution]

the only way to manage placeholders is with FSA utility but unfortunately you can't have multiple copies of the same placeholder on different servers

[buzzbox]

Thats what i thought so no biggie!

Thanks for your help Andrew!