Prior to version 0.94.6, the only way to backup or clone a table was to use CopyTable/ExportTable, or to copy all of the hfiles in HDFS after disabling the table. The disadvantage of these methods is that you can degrade region server performance or you must disable the table, which means no reads or writes can occur.
HBase Snapshots allow you to take a snapshot of a table without much impact on Region Servers. Snapshot, clone, and restore operations don't involve data copying. In addition, exporting a snapshot to another cluster has no impact on region servers.
To turn on snapshot support, set the hbase.snapshot.enabled property to true. (Snapshots are enabled by default in 0.95+, and are off by default in 0.94.6+.)
<property> <name>hbase.snapshot.enabled</name> <value>true</value> </property>
You can take a snapshot of a table regardless of whether it is enabled or disabled. The snapshot operation doesn't involve any data copying. As shown in the following example, start the HBase shell, and then clone the table:
$ hbase shell hbase> snapshot 'myTable', 'myTableSnapshot-122112'
List all snapshots taken (by printing the names and relative information).
$ hbase shell hbase> list_snapshots
You can remove a snapshot, and the files associated with that snapshot will be removed if they are no longer needed.
$ hbase shell hbase> delete_snapshot 'myTableSnapshot-122112'
From a snapshot you can create a new table (clone operation) with the same data that you had when the snapshot was taken. The clone operation does not involve data copies. A change to the cloned table does not impact the snapshot or the original table.
$ hbase shell hbase> clone_snapshot 'myTableSnapshot-122112', 'myNewTestTable'
The restore operation requires the table to be disabled, and the table will be restored to its state when the snapshot was taken, changing both data and schema if required.
$ hbase shell hbase> disable 'myTable' hbase> restore_snapshot 'myTableSnapshot-122112'
![[Note]](../common/images/admon/note.png) | Note |
|---|---|
Because Replication works at the log level and snapshots work at the file system level, after a restore, the replicas will be in a different state than the master. If you want to use restore, you need to stop replication and redo the bootstrap. In case of partial data loss due to client issues, you can clone the table from the snapshot and use a Map-Reduce job to copy the data that you need from the clone to the main one (instead of performing a full restore, which requires the table to be disabled). |
If you are using security with the AccessController Coprocessor, only a global administrator can take, clone, or restore a snapshot. None of these actions capture ACL rights. Restoring a table preserves the ACL rights of the existing table, while cloning a table creates a new table that has no ACL rights until the administrator adds them.
The ExportSnapshot tool copies all the data related to a snapshot (hfiles, logs, and snapshot metadata) to another cluster. The tool executes a Map-Reduce job, similar to distcp, to copy files between the two clusters. Because it works at the file system level, the HBase cluster does not have to be online. The HBase Snapshot Export tool must be run as the hbase user. The HBase Snapshot Export tool uses the temp directory specified by hbase.tmp.dir (for example, /grid/0/var/log/hbase), created on HDFS with hbase user as the owner.
To copy a snapshot called MySnapshot to an HBase cluster srv2 (hdfs://srv2:8020/hbase) using 16 mappers:
$ hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot MySnapshot -copy-to hdfs://yourserver:8020/hbase_root_dir -mappers 16
