The SYSCS_UTIL.SYSCS_BACKUP_TABLE system procedure performs an immediate full backup of a table in your database to a specified backup directory.

ENTERPRISE ONLY: This feature is available only for the Splice Machine Enterprise version of our On-Premise Database product; contact Splice Machine Sales for information.

This procedure only works with internal, Splice Machine tables in your database. You can back up an external table using the Hadoop DistCp tool.


                               VARCHAR tableName,
                               VARCHAR directory,
                               VARCHAR type );


The name of the table’s schema.


The name of the table that you are backing up.


Specifies the path to the directory in which you want the backup stored. This can be a local directory if you’re using the standalone version of Splice Machine, or a directory in your cluster’s file system (HDFS or MapR-FS).

You must have permissions set properly to use cloud storage as a backup destination. See Backing Up to Cloud Storage for information about setting backup permissions properties.

Relative paths are resolved based on the current user directory. To avoid confusion, we strongly recommend that you use an absolute path when specifying the backup destination.


Specifies the type of table backup that you want performed. Currently, the only valid value is full.


This procedure does not return a result.

Backup Resource Allocation

Splice Machine backups run as Spark jobs, submitting tasks to copy HFiles. In the past, Splice Machine backups used the Apache Hadoop distcp tool to copy the HFile; distcp uses MapReduce to copy, which can require significant resources. These requirements can limit file copying parallelism and reduce backup throughput. Splice Machine backups now can run (and do so by default) using a Spark executor to copy the HFiles, which significantly increases backup performance.

You can revert to using distcp, which uses a MapReduce job that can run into resource issues. For more information, see the Understanding and Troubleshooting Backups topic.

Backup and Restore Compatibility

Note that you can only use specific restore procedures with specific types of backups. For example, you can use the RESTORE_TABLE procedure to restore from a backup created by BACKUP_TABLE, but you cannot use RESTORE_TABLE to restore from a backup created by BACKUP_DATABASE. The following table summarizes backup-restore compatibility:

If you backed up with this procedure: You can restore with these procedures:




Backing Up and Restoring Statistics

Note that statistics are also backed up and restored as of version (August 5, 2019) or later of Splice Machine. This means that if you restore a backup created with or later and the statistics were accurate when the backup was done, you do not need to use analyze to generate fresh statistics for the table immediately after restoring it. If the statistics were not accurate, you can run analyze to refresh them.

If you’ve restored from a table or schema backup and aren’t sure if statistics were restored, you can use the following query to determine if statistics are available, replacing <mySchemaName> and <myTableName> with the appropriate names:

WHERE schemaname='<mySchemaName>' and tablename='<myTableName>'

Execute Privileges

If authentication and SQL authorization are both enabled, only the database owner has execute privileges on this function by default. The database owner can grant access to other users.

JDBC example

The following example performs an immediate full backup of the TPCH100 LINEITEM table to a subdirectory of the /backup directory:

CallableStatement cs = conn.prepareCall
  cs.setString(1, 'TPCH100');
  cs.setString(2, 'LINEITEM');
  cs.setString(3, '/backup');
  cs.setString(4, 'full');

SQL Example: Backup, Validate, and Restore a Table

This example shows you how to back up a table, then validate and restore it, in these steps:

Backing Up the Table

This command line performs a full backup of the TPCH100 LINEITEM table to the /backup directory on HDFS:

splice> CALL SYSCS_UTIL.SYSCS_BACKUP_TABLE('TPCH100', 'LINEITEM', '/backup', 'full');
FULL backup to /backup

1 row selected

Examining the Backup

After the backup completes, you can examine the sys.sysbackup table to find the ID of your new backup:

splice> SELECT * FROM sys.sysbackup;
587516417      |2018-09-25 00:12:33.896  |2018-09-25 00:42:53.546  |SUCCESS    |TABLE     |false|-1                  |3

You can use the ID of your backup job to examine the sys.sysbackupitems and verify that the base table and two indexes have been backed up:

splice> SELECT * FROM sys.sysbackupitems WHERE backup_Id=587516417 ;
587516417   |splice:292000    |2018-09-25 00:12:40.512   |2018-09-25 00:32:14.856
587516417   |splice:292033    |2018-09-25 00:12:40.513   |2018-09-25 00:42:48.573
587516417   |splice:292017    |2018-09-25 00:12:40.512   |2018-09-25 00:41:25.683

3 rows selected

Validating the Backup

Before restoring the table, you can validate the backup:

splice> CALL SYSCS_UTIL.VALIDATE_TABLE_BACKUP( 'TPCH100', 'LINEITEM', '/backup', 587516417 );
No corruptions found for backup.

1 row selected

See the reference page for the SYSCS_UTIL.VALIDATE_TABLE_BACKUP system procedure for more information about backup validation.

Restoring the Backup

You can restore the table to another table on the same cluster, or on a different cluster.

This command restores the backed-up table to table named LINEITEM in the SPLICE schema:

splice> CALL SYSCS_UTIL.SYSCS_RESTORE_TABLE('SPLICE', 'LINEITEM', 'TPCH100', 'LINEITEM', '/backup', 587516417, false);
Statement executed.

See the reference page for the SYSCS_UTIL.SYSCS_RESTORE_TABLE system procedure for more information about restoring a backed-up table.

See Also