I am wondering how to improve the recovery time of a Windows file-level restore (copy to) job.
The restore of approximately 119K files totaling 11.7GB just took an hour and a half. Speed is averaging 2-3MB/s and peaks at 5MB/s.
I have version 7 on a VMWare 5.1 guest running Server 2008 R2 SP1 (Host is a quad core xeon single socket with 10K SAS drives and dedicated nic port for this guest). All resources seem fine. CPU is averaging 50% during the copy to process with plenty of RAM.
Backup repository is a Synology 1812+ with teamed 1Gbps NICs with RAID 10 on 6-2TB Seagate Constellation SATA drives and a standard share, not iSCSI
Attempting recovery of files in a Windows Server 2008 R2 guest job with a reverse incremental and selecting the copy to option...
Copy to target is a mapped network drive to a physical Windows Server 2008 R2 SP1 box with almost 0 utilization on network, RAM, CPU and 10KSAS drives.
The backup jobs for all my guests average 25-50MB/s. Why is this taking so long???
Veem 7 patch3
Reverse backup
Image pulled up in 10 seconds (it was the last reverse before the full, so no the reverse of 100 restore points ago)
File level restore and copy of a folder with a lot of small files, on the local Veeam server. 2GB folder.
Avarage speed 500KB/s. When i backup i get 80MB/s on the same server where i am pulling the data from.
On top of that, when restoring lots of small files, there will be an overhead of having to read larger backup file blocks. For example, to recover a single 1KB file, the engine needs to read 256-512KB of data (the entire compressed image block containing said file) before it can extract that 1KB file's data.
I tried to restore 45GB of files today from last night's incremental backup that is held on the repository/backup server. I was trying to restore to the same drive that the repository is on, both from Explorer view and the veeam guest file browser.
Although this restore comprised of 347 169 files, some of which are small text/csv files it was only restoring at 1-2MB/s. Is this expected or is there a faster way to carry out larger data restores.
Seems like a decent performance for restoring nearly half a million of small files. Remember that the restore is done from compressed and deduped backup, as opposed to raw storage. Although even with some raw storage, this would not be significantly faster (see my laptop reference earlier).
I am curious though what has triggered such a restore? How did you lose so many files so granularly? I mean, in most cases such a massive loss causes users to just perform the entire virtual disk recovery (and this would work much faster, too).
