In that past year we started using a D2D network device to store our SQL Server backups. This device does dedup and compression. It looks just like any standard CIFS share (
\\d2d\sql_backups\...). Every thing works normally except we get horrible restore throughput. We only get 2-4MB/sec. We have worked extensively with the vendor. We are doing simple SQL Server restores like the following.
RESTORE DATABASE [test] FROM DISK = N'\\d2ddc2\sql_backup\test_backup_2013_02_10_210004_0520927.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 1 GO
When doing diagnostics the vendor tells us that the SQL Server restore is NOT reading the backup file sequentially but rather it skips forward at times and then back to read the data. This causes numerous buffer problems as the D2D is attempting rebuild the deduped data.
Can anyone confirm or deny this. I have searched extensively on MS, google, various other sites and can't find a definite answer. If it's not true can you point me some authority I can give to our vendor.
Just to clarify. I'm only concerned about how the actual
.bak is read. This has nothing to do with the database files or IO.