ybrestore Options ​

This section contains detailed descriptions of the ybrestore options. Many of these options work the same for ybbackup and ybbackupctl. See ybbackup Options. See also Common Options in ybtools.

To see all of these options in the online help, run the ybrestore --help and ybrestore --help-advanced commands.

-c STRING, --chain STRING

Name the backup chain to use for the restore. See ybbackup Options for information about backup chains.

--compatibility-mode BACKWARD | FORWARD | ALL | NONE

Allow/forbid running commands on backup bundles with newer/older bundle versions than the client tools bundle version.

• BACKWARD allows operating on backup bundles with bundle versions same as or older than the client tools bundle version.

• FORWARD allows operating on backup bundles with bundle versions same as or newer than the client tools bundle version.

• ALL allows operating on all backup bundles.

• NONE allows operating on backup bundles with the same bundle version as the client tools bundle version.

By default BACKWARD is chosen.

-d, --dbname STRING

Name the database to restore. The named database must not already exist on the target system.

-h, --host

The database server host (the target for the restore operation, which may or may not be the same system where the backup was taken). Alternatively, you can set this value with the YBHOST environment variable. Defaults to localhost.

--hot-standby [ ON | OFF ]

Put a restored database in HOT_STANDBY mode (ON) or take it out of HOT_STANDBY mode (OFF) when the restore operation is complete. The default is ON. If multiple restore operations are restored in a sequence, this setting is not applied until the last restore is complete. This option may not be used for single-table restore operations.

See HOT_STANDBY and READONLY Modes.

-a, --point STRING

Specify the restore point in one of three ways:

• latest or oldest backup in the chain
• Backup snapshot name (the value for --name when the ybbackup command was run). For example: PremDBFullBackup20190906 or DB1_Sept_06
• Backup timestamp in YYMMDD HH:MM:DD format. For example: 190906 12:00:00

--preserve-ldap

Preserve LDAP settings in the restored database. This means that the restored system will recognize and preserve LDAP authentication and synchronization settings that were configured for the source system. The default is not to preserve these LDAP settings. This option may not be used for single-table restore operations.

--security-mode ALL | NONE

Restore all security-related objects, including users, roles, ACLs, and privileges granted on objects. The default is NONE (restore none of these). Superuser privileges are not restored in either case. This option may not be used for single-table restore operations.

-t, --table

Name of a single existing table that you want to restore under a new name. You can restore a single table into the same database where it was backed up or into a different existing database. You can specify schema.name or just name. For example: public.match or match.

-tt, --target_table

New name of the table you are restoring, as specified with -t. You can specify schema.name or just name. For example: public.match_restored or match_restored. This setting must be used if you are restoring the table to its original database and schema, and the table named with -t still exists in that database and schema. If you are restoring the table to a different system or a different database, this setting is not required.

--temp-workdir STRING

Use the specified location as a temporary working directory for backup bundle processing. By default, the current working directory is used. Backup and restore operations that write or read from object storage require a writable local directory during processing. When processing is finished, this directory is empty.

--use-relative-location STRING

Specify a location that is used to override the base paths for all the backup files that will be restored. This option is useful when you have moved backups from local storage to object storage or vice versa, or from one local file system to another. When you come to restore those files, they can be easily found at the updated location. You do not need to use the ybbackupctl --fix-bundle-path option before running the restore (which could be a time-consuming operation).

This option has two limitations:

• It only works if the backup was stored in a single location. All data files are assumed to be in the same folder, relative to the metadata (metaDB.mv.db).
• If you want to run another backup on a folder after moving it, you do have to use the ybbackupctl –fix-bundle-path option.

--validate-locations-exist, --no-validate-locations-exist

Prevent a restore operation from proceeding if any of the specified backup locations are invalid. By default, this check does not occur (--no-validate-locations-exist).