You can use snapshots to create almost instant open systems backups. Say you are hosting AIX data on an EMC symmetrix. All you need to do, is split off a BCV for that data, then mount it on a different server. That gives you an instant backup and a complete full copy of your data. Restores simply require that files are copied from the BCV back to the original server.
At this point it is worth having a quick review of why we need backups. We need to be able to recover data to be able to manage file failures, hardware failures and site failures. This BCV is a single point in time copy of the data, but we will need several PIT copies as we may need to wind the data back several days. If you use BVCs then can you afford to keep 10 full copies of all your data online?
The solution is space efficent snapshots, which are explained in detail in the snapshot section. In brief, snapshots are not real copies of data, they are pointers to the original data. In a Copy On Write (COW) implementation, as that data changes, the original data is copied to a snapshot area to preserve the PIT snapshot and the snapshot pointers are changed to point from the original data to the copied data. Snapshots are very fast, they can create a backup of a multi terabyte disk is seconds, and will create a good PIT copy. As they are space efficient, you can take and keep several snapshots without filling up your disks, so they are perfect for keeping older copies of files. This will protect you from deleted files, corrupted files, and some virus and ransomeware encryption attacks.
A snapshot can cope well with file failures, but a snapshot must happen within the same hardware system, and maybe even the same disk. So if disk breaks, the data and the snapshot are both gone. A site failure is even worse, as then you have lost all your data with no way to recover it.
Also, snapshots are not really suitable for keeping data for any length of time. Most implementations are COW, so the snapshot area will grow as the original data gets updated. If your data update rate is high, then the snapshot area can fill up, and then your oldest snapshot will be invalidated, which will mean you are keeping fewer backups than you planned.
You then have 2 options. You could copy the data off the snapshot with a backup product or you can replicate all your data, including snapshots, to another site. The first option requires a backup product that can run from snapshots and there are many of them about. The second option requires a data mirroring facility, and a complete second data center.
Before we discuss some specific products, there is one scenario where snapshots are perfect, and that is for a pre-change backup. It is a standard requirement in change control that if you change something, then you must be able to get back to where you started from if things go wrong. In this case, a snapshot is fast, so it does not impact your change window, as is temporary as you can delete it once the change is tested and proven. Just don't remove it too quickly, give your change plenty of time to bed in first.
Volume Shadow Copy Service (VSS) is explained in detail in the Shadow Copy Page. It was introduced in Windows 2003 and is supported up to Windows 10. It is equivalent to hardware 'snapshot' functions like Flashcopy or Timefinder, but it is an operating system component that works at software level. VSS works by making a block-level copy of any changes that have occurred to files since the last shadow copy. Try a right click on a folder in File Explorer, then look for 'Restore Previous Versions'. You should see previous VSS snapshot versions that you can recover a file from.
VMware uses snapshots extensively to make copies of an entire Virtual Machine (VM). This is not just a backup of the data on disk, it includes the memory contents and virtual NICS. Also included is the status of the machine; powered on, powered off, suspended. A VM snapshot contains the following files:
a VMDK, which contains the raw disk data
-deta VMDK, the changes since the last snapshot
VMSD, snapshot information including child relationships
VMSN, machine status and memory
The VM people say that snapshots should not be considered backups as they are on the same storage as the primary disk. They should also be considered short term, with a lifespan of 24-72 hours. Yoo therefore need a backup product like Netbackup or TSM that can work from the VMware snapshot and move the data off to backup storage. The TSM VMware page explains how TSM does this.
Databases need special handling as it is essential that all the files be in a consistent state when they are backed up. A DBMS backup will ensure database consistency and they can work with snapshots directly. For example a DB2 backup command has a 'use snapshot' parameter, and Microsoft Azure can use file snapshots. On the other hand, Oracle do not encourage the use of snapshots as they claim they are not as secure as backups taken with the RMAN utility.
If you run databases under VMware, then you can use the VMware tools Pre- and Post-Processing Scripts to quiesce databases before taking a VM snapshot. These consist of scripts, which for Linux VMs are called /usr/sbin/pre-freeze-script and /usr/sbin/post-thaw-script and for Windows the scripts should be placed in C:\Program Files\VMware\VMware Tools\backupScripts.d\. The process works for DB2, MAXDB, Oracle, Sybase and MySQL databases, and generally comprised two pairs of scripts, pre-freeze and post-thaw-scripts located in the directories above, that are executed by VMware, and write_suspend and write_resume scripts that are exectued by the DBMS and are usually located in the database directory.
For example, DB2 scripts would work like this on Linux:
the /usr/sbin/pre-freeze-script will be executed by VMware once a VM backup is made, but before VM creates a snapshot.
if [ "$(id -u)" -eq "0" ]; then
exec su - db2inst2 -c /db2home/db2inst2/write_suspend
VMware will then take a snapshot, then run the /usr/bin/post-thaw-script
if [ "$(id -u)" -eq "0" ]; then
exec su - db2inst2 -c /db2home/db2inst2/write_resume
The write_suspend and write_resume scripts should really be controlled by your DBA, but the relevant commands, once the database connections are established, would be
$INSTHOME/sqllib/bin/db2 set write suspend for database
$INSTHOME/sqllib/bin/db2 set write resume for database