With the Oracle Cloud we have the option of doing an instance snapshot as well as storage snapshot. This is equivalent to cloning our existing instance and having it ready to provision when we want. This is different from a backup. A backup traditionally assumes a fixed computer architecture and we can restore our operating system bits and application code onto a disk. If we suddenly change and add a virtual private network for communications with our on premise data center the backup might or might not have that configuration as part of the bits on the network disk. Many customers found that this was the case with VMWare. When you can redefine the network through software defined networks, create virtual disks and virtual network interfaces, these additions are not part of a ufsdump or OS level backup. You really need to clone the virtual disk as well as the configurations.
Oracle released snapshots of storage as well as snapshots of instances in the May/June update of cloud services. There really are no restrictions on the storage snapshots but there are a few on the instance snapshots. For the instance snapshot you need to make sure that the boot disk is non-persistent. This means that you don't pre-create the disk, attach it to the instance and boot from it. The disk needs to have the characteristic of delete upon termination. This sounds very dangerous up front. If you create customizations like adding user accounts to /etc and init files to the /etc/init directory these get deleted on termination. The key is that you create an instance, customize it, and create a snapshot of it. You then boot from a clone of this snapshot rather than a vanilla image of the operating system.
First, let's look at storage snapshots. We can find more information in the online documentation for the console or the online documentation for the REST API and command line interface. There are some features in the REST API that are worth diving a little deeper into. According to the REST API documentation you can create a snapshot in the same server to allow for faster restores by specifying /oracle/private/storage/snapshot/collocated as a property when you create the snapshot. From this you can create a storage volume from a snapshot. We can do most of these functions through the compute console. We select the storage volume and select the Create Snapshot menu item.
We can now restore this snapshot as a bootable disk and can create a new instance based on this volume. We restore by going to the storage snapshot tab, selecting the snapshot, and selecting Restore Volume from the menu. We can see the restored volume in the storage list.
We can create an instance snapshot as well. The key limitation to creating a snapshot from an instance is that the disk needs to be non-persistent. This means that we have a disk that is deleted on termination rather than created and mounted as part of the instance. This is a little confusing at first. If you follow the default instance creation it creates a storage volume for you. You need to delete this storage volume and have it replaced by a ROOT disk that is deleted upon termination. If we walk through an instance creation we have to change our behavior when we get to the storage creation. The default creates a storage instance. We want to remove it and it will be automatically replaced by a nonpersistent volume.
Once we have this hurdle removed, we can create an instance snapshot. We select the instance and click on the Create Snapshot from the menu item. If the menu item is greyed out we have a persistent storage volume as our boot image.
We can create a bootable image from this snapshot by clicking on the menu for the snapshot and Associate Image with this snapshot. This allows us to create an instance from our image.
The key to using instance snapshots is we create a bootable instance, configure it the way that we want and then create a snapshot of this instance. This gives us a golden master of not only the boot disk but of the network and customizations that we have done to the instance. You have to think a little differently when it comes to instance snapshots. It is a little strange not having a persistent root disk. It is a little strange knowing that any customizations will be lost on reboot. It is a little strange knowing that default log files will be wiped out on reboot. You need to plan a little differently and potentially reconfigure your logs, configurations, and customizations to go to another disk rather than a default root disk. If you think about it, this is not a bad thing. The root disk should be protected and not customized. Once you have the customized it should be frozen in time. One key advantage of this methodology is that you can't really insert a root kit into the kernel. These types of intrusions typically need to reboot to load the malware. Rebooting reverts you back to a safe and secure kernel and default libraries. This does mean that any packages or customizations will require a new snapshot for this customization to be persistent.
In summary, snapshots are a good way of freezing storage and an instance in time. This is good for development and test allowing you to create a golden master that you can easily clone. It also adds a new level of security by freezing your boot disk with packages that you want and locks out malware that requires reboot. It does add a new layer of thought that is needed in that any package or root file customization requires a new golden image with a new snapshot. Hopefully this helps you think of how to use snapshots and create a best practice methodology for using snapshots.