My team is considering backing up all DBs to an Isilon NAS and we're conducting time trials to see if the restore time from the NAS is quicker than performing a copy to local storage before restoring. Besides considering the throughput of the source and target storage and the network link, what else should we consider before making a selection? Thank you!
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Feel free to restore across the network if it's stable. If it isn't, then it's much quicker to just copy it over first, then try to restore. With a copy you can use a robocopy type program to pick up where it left off in case of a network error/outage. Once it's copied over, you can just restore in SQL Server. SQL Server will not be able to 'pick back up where it left off' in case of network errors.
Backing up is more sensitive than a restore, your file will either fully restore or it will not fully restore; those are the only 2 options. Backups might get corrupted during many different parts of the process from disk IO sub system on the storage, copying across the network, disk at rest possibly, etc.
This is of course not saying your restored backup won't get corrupted after it was restored, or even if your database itself wasn't corrupted when backed up. :)
In my experience, there has been nothing to gain by copying files locally before carrying out the restore. If the target of the restore has sufficient IO capacity, you should be able to restore from the network share at very close to the speed of a file copy.