HP VAN SDN Controller Administrator Guide

68
 Whether operating in a team or operating in standalone mode, each controller is
backed-up as a single system.
 When the controller is deployed in a VM, standard VM backup/restore tools (such
as Snapshot or Clone) can be used.
 When the controller is deployed on bare metal, standard Linux server-based
backup/restore tools (such as rsync, LVM snapshot, and Amanda/Zmanda) can be
used.
 To complete a teamed backup, no controller can be in a failed state. (A controller
team must have three controllers.)
 On any controller or controller team, only one operation can run at any given time
(backup, restore, upload, or download). Also, starting a new backup while another
backup is being downloaded creates an error condition and halts the new backup.
 Only authenticated users are allowed to create and restore backups. In some
cases the domain name is also required.
Notes
The default domain name is “sdn”. The default username is also "sdn".
The default password is "skyline".
The controller does not save a non-default domain, user name, or pass-
word across a backup. Changing these settings to non-default values and
later backing up the controller, resets these settings to their defaults in the
backup file. Later restoring the backup to the controller resets the domain,
user name, and password to their default settings in the controller.
For backup and restore of the Keystone configuration and database, see "Backup and Restore the Keystone
Configuration and Database" on page 74.
 If a new backup fails, the last successful backup remains in the system.
 If uploading a backup fails, then no backup version remains on the system.
 Starting a new backup replaces any earlier backup remaining in the controller. If a
backup is being downloaded when a new backup is started, the new backup halts.
 Metering time-series data is not encompassed by the controller backup process. There
can be a large amount of data, possibly tens of GBs in size, which is keyed to time. Not
only is the time series data impractical to back up because of its size, but upon restoring
it there is a likelihood that some of the restored data will not be usable because it will be
older than the "sliding window" of time that metrics are retained for on the controller.
However, there is one metering file that is backed up and restored. It contains a
mapping of metric descriptor information (such as the ID of the application that created a
metric and the metric's primary tag, secondary tag, and name) to the UID that was
assigned to each metric. When a restore is performed, this file is restored, and any
existing metering time-series data is deleted because it may not match the restored file.
The mappings that are restored may, depending upon time elapsed since the backup
was taken, be used to assign the same UID to a metric created following the restore (and
subsequent controller restart) that was assigned to the metric before the backup was
taken. This provides continuity for a metric across the time spanned between backup
and restore because all data for the metric will be keyed to the same UID. Thus, while
time-series data from before the restore was not retained during the restore, UIDs used to
key time-series data that was exported to external tools or storage before the restore will
continue to be used for the same metrics.