Service packs. Kernel patches. New module releases. What do all of these have in common? Restore points and backups. Before we, as BASIS administrators, do any of these we have to make sure we have a recovery point so if anything should go haywire, we have a point of recovery. Usually it involves communicating with the database administrators, operating system administrators, and backup teams to leverage the current backup technology.
If you are already a virtualization house, or are thinking about converting to be one, then you know about some of the new solutions available to you. The most basic, and most easily leveraged is that of the “snapshot”.
Snapshots allow us, in only a few clicks, to take a “backup” of the current state before we do anything else. In the case of a centrally installed instance, in one fell swoop we get the file system–including all relevant SAP files, the database, and the current state of the operating system stored as a frozen point in time. Distributed instances will obviously take a little more effort, but it certainly beats having multiple tape archives for each individual component.
From a technical standpoint, a snapshot starts a new virtual disk file (and associated virtual machine files). Any changes made to the virtual machine from that point on get written to these new files instead of the versions representing the machine state prior to the snapshot. Once your changes are complete and you are satisfied with the results, you simply “commit” the changes to the core virtual machine. You can think about it as a small disaster recovery asynchronous backup. A second set of data is created, changes to that second set are applied, and then the changes are synchronized with the original set. Once the changes have been committed, the snapshot files are then deleted and the physical disk space recovered.
Leveraging the snapshot technology is a wise decision for any admin for whom it is available. A recovery point can be created minutes before you start your tasks. Necessary communications with supporting teams is also reduced to just your Hypervisor management team. Keeping the database administrator and operating system teams in the loop is always a good practice, though!
With every good, there is a bad, however. Committing the changes to the core virtual machine files can be time consuming dependent on the scale of the changes made and availability of host system resources. If your physical host is approaching being resource constrained, the process can negatively affect the performance of the other virtual machines on the same host. The process also generates an incredibly large amount of disk I/O. If there are any bottlenecks in your SAN, this will probably find them.
A well-sized and maintained physical host/cluster should do well and see minimal impact. The bonuses of using snapshots for patching and massive change preparations far exceed any possible negatives for the BASIS Administrator.
