Full Backups
Bradley Beard · Apress eBooks · 2018
The concept of backing up data is one of those things that should be extremely intuitive, but is often implemented poorly, if at all. I know quite a few database administrators (DBAs) that don’t worry about regular, structured backups because their database server is on a SAN (storage area network) and the data is therefore backed up regularly. To me, this makes no sense at all, since there is absolutely no contingency for point-in-time restoration of data, outside of what happened to have been backed up as part of a complete Windows backup solution. If there were a catastrophic failure, and the DBA had to rebuild the database to the point of failure, it could not be easily done. The reason is because the entire Windows image would have to be rebuilt from the last Windows backup, which means that the database will only be current to that particular point of time, and not the desired point of time. For example, if the Windows image is run nightly, but the database backups are run hourly, then you will have a perfect set of hourly backups up to the point where the Windows backup is run. If Windows fails at 11:59 pm , then that entire days’ worth of database backups has been lost. The rule of thumb, generally, is to put backup files on a separate drive than the OS. This alleviates the issue outlined in the preceding, as long as the backup drive is not corrupted.