Extremely poor performance backing up junction points

[bmekler]

I'm using PHD Virtual Backup for VMware to back up a vSphere environment. PHD uses hard links to create a deduplication store - it backs up 1MB blocks, and when a block has a duplicate somewhere else in the backup store, PHD creates a link rather than write the full MB. As a result, right now I have a partition with roughly 2.5TB of actual data but almost 30TB of "virtual" data created by hard links, attached by iSCSI to my backup server. I want to spool it off to my LTO4 tape for DR purposes. I created a job, selected the folders where PHD stores its data, unchecked "Back up files and directories by following junction points" and ran it. However, performance is absolutely dismal - the job has been running for about two hours now, it has backed up approximately 180MB of "real" data. It does list approximately 1.2 million backed up files, but those are almost all just links - why is it so slow?

[CraigV]

...if they are links, you've got a couple millions files to be backed up. At no stage will the tape drive be spooled up to an optimal speed.

It spins, stops, spins, stops etc. etc. with every single file. It therefore doesn't run at any decent speed, meaning your throughput is going to be poor.

If you were initially backing up to disk, you'd have *.bkf files, and these would be much faster to back up.

That said, try a backup with the juncture points option deselected and see what that offers you.

[bmekler]

That's what I'm doing in the first place, backing up with junction points deselected. I thought that with links being essentially entries in the MFT, they'd get backed up within minutes, but apparently it is not so.

By the way, it's a couple million actual files, and links are in tens of millions.

Right now I'm evaluating block-level backup-to-tape options, primarily Acronis True Image and HP Data Protector.