One of the nice features of Server 2003 is the ability to make Shadow Copies of shared folders. Shadow Copy (aka VSS - Volume Snapshot Service) allows you to schedule snapshots of your data and then automatically save them. The users can then revert to a previous version of a file when they have a brain fart and overwrite or delete something accidentally.
While R2 of Server 2003 allows a new type of shadow copy called differential, which is actually much more efficient, we are still running Standard Edition SP2 on most of our servers. Thus we are stuck with the only option of scheduling a snapshot every so often - typically 7am and noon. You don't want to do it more often as it definitely affects I/O and therefore user annoyance.
While having a recent backup of a file elsewhere on the file server would come in handy, here's why we decided that implementing VSS would not be advantageous to our organization. VSS works best with a separate volume, preferably on a different physical disk. This improves performance and decreases the chances of data being overwritten on high I/O servers.
While we have about 150GB available on a 256GB array, it has all been configured in two volumes: the OS and data. We would have to completely wipe out and reconfigure our array in order to follow Microsoft best practices. I suppose I could turn on VSS with the existing volume configuration but with up to 64 available Shadow Copies disk space is quickly consumed.
Besides, how often do I really need to do a restore? I use Backup Exec and have a NAS with three days of backups always online. I can do a restore from any one of those or pull a tape from anytime over the past twenty days. My file sever is also overloaded with services right now so any more I/O while the shadow copies are created would be a real drag.
Conclusion: We decided that implementing Shadow Copies on our main file server is not a good idea for us a this time. If I were setting up a new file server and had the disk space to spare, I would set the array up properly and turn it on. Perhaps when we migrate to Server 2008 sometime next year we will take advantage of this cool feature.
While R2 of Server 2003 allows a new type of shadow copy called differential, which is actually much more efficient, we are still running Standard Edition SP2 on most of our servers. Thus we are stuck with the only option of scheduling a snapshot every so often - typically 7am and noon. You don't want to do it more often as it definitely affects I/O and therefore user annoyance.
While having a recent backup of a file elsewhere on the file server would come in handy, here's why we decided that implementing VSS would not be advantageous to our organization. VSS works best with a separate volume, preferably on a different physical disk. This improves performance and decreases the chances of data being overwritten on high I/O servers.
While we have about 150GB available on a 256GB array, it has all been configured in two volumes: the OS and data. We would have to completely wipe out and reconfigure our array in order to follow Microsoft best practices. I suppose I could turn on VSS with the existing volume configuration but with up to 64 available Shadow Copies disk space is quickly consumed.
Besides, how often do I really need to do a restore? I use Backup Exec and have a NAS with three days of backups always online. I can do a restore from any one of those or pull a tape from anytime over the past twenty days. My file sever is also overloaded with services right now so any more I/O while the shadow copies are created would be a real drag.
Conclusion: We decided that implementing Shadow Copies on our main file server is not a good idea for us a this time. If I were setting up a new file server and had the disk space to spare, I would set the array up properly and turn it on. Perhaps when we migrate to Server 2008 sometime next year we will take advantage of this cool feature.
No comments:
Post a Comment