The basis of this article is to assist in restoring your configuration from a backup in the event of an appliance replacement or new VM installation.
The major hurdle for restoring a backup onto a new/replacement appliance is the use of a UUID (universally unique identifier) as an identifier for the system. The Web Gateway backup contains all configurations and policies for your entire central management cluster. The UUID identifies the configuration part (IP, DNS, routing and so on) for each individual machine. If an appliance gets replaced (due to hardware issues or model upgrades), the UUID changes and the backup cannot be restored with default methods. This article will describe how you can manually restore the backup and enforce the configuration of the old UUID to the new/replacement appliance (new UUID).
In order to restore the configuration, we will need a backup from the old appliance along with its UUID. It is very important to have a record of the old UUID in case the appliance gets damaged or you are otherwise unable to obtain the UUID in the future.
After logging into the GUI, go to Troubleshooting > Backup/Restore > select Backup.
Note: Backups can also be encrypted, once you choose the destination, you will be prompted to enter a password if you wish to encrypt your backup. Leave it blank if you do not want encryption.
To take a backup from the CLI, the following mwg-coordinator commands can be used:
/opt/mwg/bin/mwg-coordinator -B "file:in=ACTIVE,out=/opt/mwg/storage/backup_cache/default/temp.backup"
/opt/mwg/bin/mwg-coordinator -B "file:in=ACTIVE"
To get the UUID from the UI navigate to Configuration > Appliances, then it is available under Appliances Information:
To get the UUID from the CLI, use mwg-info:
mwg-info uuid
If your appliance has died, and you're not sure what the UUID is, but you have a backup file, you can use the to get the UUID from the backup file.
We are covering scenarios for both standalone and clustered appliances in this section. For both scenarios you need to have command line access as "root" to the appliances.
If you only have one appliance or your appliance is not part of a central management cluster, proceed with these steps:
1. The backup will need to be copied to the new/replacement Web Gateway using a tool like WinSCP. In the example below, the backup file is named 'backup.old' and was copied to /var. It does not need to be placed there if there are any disk space concerns.
2. The command to restore the backup is shown below:
/opt/mwg/bin/mwg-coordinator -u mwgc:mwg -R "file:in=/var/backup.old;options:forcedetachgui=yes,uuid=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Notes about the command:
a. /opt/mwg/bin/mwg-coordinator -u mwgc:mwg -R - This portion should always remain unchanged.
b. file:in= - This is the path on the file system to the backup file.
c. options: -There are two options set in the standalone version of the command; 'forcedetachgui' which forces the GUI to be closed and 'uuid' which is the UUID gathered above from the old appliance, not the UUID of the new/replacement machine.
3. It is recommended that you reboot the appliance after the restore has finished to ensure all settings are applied correctly.
Note: If the IP address of the appliance changes during the restore procedure, you will lose your SSH connection and it might appear as if the restore is not successful. Rest assured, it actually finished and your SSH client lost it's connection due to the changed Web Gateway IP address.
In case you have multiple appliances in a central management cluster, it is very important to do the restore steps in the correct order to ensure that there will be no conflicts in your cluster (the cluster also relies on UUIDs):
1. The backup will need to be copied to the new/replacement Web Gateway using a tool like WinSCP. In the example below, the backup file is named 'backup.old' and was copied to /var. It does not need to be placed there if there are any disk space concerns.
2. Before restoring a backup, ensure to remove the old Web Gateway appliance from the current cluster as seen below. This will ensure no issues are encountered when adding the new/replacement Web Gateway appliance back into the cluster after the configuration has been restored.
3. On the command line of the new/replacement appliance you can now restore the backup and at the same time force it to be a standalone machine:
/opt/mwg/bin/mwg-coordinator -u mwgc:mwg -R "file:in=/var/backup.old;options:forcedetachgui=yes,cluster=standalone,uuid=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Notes about the command:
a. /opt/mwg/bin/mwg-coordinator -u mwgc:mwg -R - This portion should always remain unchanged.
b. file:in= - This is the path on the file system to the backup file.
c. options: -There are three options set in this section; 'forcedetachgui' which forces the GUI to be closed, 'cluster' which configures the cluster settings which in this case is forced to standalone, and 'uuid' which is the UUID gathered above from the old appliance, not the UUID of the new/replacement machine.
4. It is recommended that you reboot the appliance after the restore has finished to ensure all settings are applied correctly.
Note: If the IP address of the appliance changes during the restore procedure, you will lose your SSH connection and it might appear as if the restore is not successful. Rest assured, it actually finished and your SSH client lost it's connection due to the changed Web Gateway IP address.
5. After the reboot, log into the GUI and verify that the settings under the Configuration page are what is expected, then log out. Then, log into a current cluster member and add the newly restored appliance back into the cluster as seen below, adjust the network group as needed:
You shouldn't use "cat /sys/class/dmi/id/product_uuid" to get the product uuid as this is a implementation detail that might be changed in the future. Use "mwg-info uuid" instead.
If you use a "Central Management" configuration for cluster over multiple datacenter, then make sure the other nodes also have the network groups properly set for configuration replication, otherwise the node cannot be deleted from the cluster.
calculate-in some time for the updates of the system (not OS level), i takes a while (20min) to get all AV files, CRL updates etc in place
and last: if you receive:
ERROR - COORDINATOR: checking new settings failed - Node configuration List is empty
ERROR - local binaries rejected the configuration
you probably did not backup properly before going through the whole procedure. make sure that in a cluster environment:
1. if the master node must be replaced (backup the configuration before anything else)
2. switch the master to a lower priority node
3. then delete the master node and procede as described
Hey guys!
If the backup file is encrypted, then what is the command in CLI to restore???
[root@mwgappl ~]# /opt/mwg/bin/mwg-coordinator -R usage
general format for restore configure strings:
file:in=<path_to_backup_file>[;options:[info=yes]|[uuid=UUIDSTRING][,cluster=standalone][,global=no][,apply=no][,forcedetachgui=yes][,mas=no]
file:in is a required value.
path_to_backup_file references the backup file to be restored.
options:info=yes is an optional value that cannot be used together with another option:xyz.
if given e.g. lists the UUIDs present in the backup file (and does NOT restore the backup).
options:uuid is an optional value.
if given sets an UUID to use for the local machine.
(USE ON YOUR OWN RISK): a configuration contains machine specific parts and restoring
a backup from another machine may have unwanted side effects.
options:cluster=standalone is an optional value.
if given it will make this machine a standalone machine.
options:global=no is an optional value that cannot be used together with another option:xyz despite 'internal'.
if given it will cause that current global configurations stay untouched.
options:internal=no is an optional value that cannot be used together with another option:xyz despite 'global'.
if given it will cause that current internal configurations stay untouched.
options:apply=no is an optional value.
if given it will cause that the configurations in the backup file are not applied.
files will be extracted into a newly created folder in storage.
options:forcedetachgui=yes is an optional value.
if given it will cause currently runnig gui to be detached. This is needed to avoid
configuration inconsistency if some user changes configuration from the gui while
restore is running. If this option is NOT given, a attached gui will cause restore to fail.
options:password=<password> is an optional value to decrypt an encrypted backup with the given password.
if option is used, an empty password is not allowed. Also spaces in the password and the special signs ':' '=' ';' are not allowed.
if the backup is not encrypted, the password will be ignored.
options:mas=no is an optional value.
if given and equal to 'yes' will lead to restoration of SSO credentials
NOTE: The restored backup will become active after successful extraction (if not overridden by options:apply=no).
HINT: pass the configure string within quotes to not confuse the shell.
So:
/opt/mwg/bin/mwg-coordinator -R file:in=<path>;options:forcedetachgui=yes,password=<pass>
or similar.
Michael
Attention: The backup/restore is NOT including the content in /opt/mwg/files, e.g. a wpad.dat that's stored there. Other than that, the above described procedure worked perfectly.
Different scenario: How do you transfert the whole config (Policies, List, Template, etc but not IP/Name/NTLM credential of the proxy ) from a lab server to a new production server?
!!! Missing command in the steps !!!
# chown mwgc /var/backup.old
Otherwise, the /opt/mwg/bin/mwg-coordinator -R "file:in=… fails with:
…Job queued with id: 1112
Job progress: .
Job finished.
Coordinator responded:
restore failed, unable to open backup: /var/backup.old
…
But, it did seem to apply the UUID.
With the chown, the final line of the output is “OK”.
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA