nislmigrate
is a command line utility for migration, backup, and restore of supported SystemLink services.
- This tool officially supports migration between SystemLink versions 21.0, 21.1, 21.3, & 21.5. Other versions have not been tested.
- We assume the server you are migrating to is clean with no data. Migrating to a server with existing data will result in data loss.
- Services that are supported with any caveats and exceptions are detailed in the Supported Services section below.
- This tool assumes a single-box SystemLink installation.
- This tool must be run on the same machines as the SystemLink installations.
- This tool requires Python 3.8 to run.
- The documentation in this repository assumes Python has been added to your PATH.
The latest released version of the tool can be installed by running:
pip install nislmigrate
To backup the data for a service listed in the Supported Services section run the tool with elevated permissions and use the capture
option with the corresponding flag for each of the services you want to back up (e.g. --security
):
nislmigrate capture --security
This will backup the data corresponding with each service into the default migration directory (C:\Users\[user]\Documents\migration\
). You can specify a different migration directory using the --dir [path]
option:
nislmigrate capture --security --dir C:\custom-backup-location
To backup the data for all supported services at once, the --all
flag can be used instead of listing out each individual service. Using --all
will require that you include the --secret
flag for services that require encrypting backed up data for security:
nislmigrate capture --all --secret <password>
⚠️ Restoring requires the--force
flag to explicitly allow overwriting the existing data on the server. Without it, the command will fail.
To restore the data for a service listed in the Supported Services section run the tool with elevated permissions and use the restore
option with the corresponding flag for each of the services you want to restore (e.g. --security
):
nislmigrate restore --security
This will restore the data corresponding with each service from the default migration directory (C:\Users\[user]\Documents\migration\
). If your captured data is in a different directory that can be specified with the --dir [path]
option:
nislmigrate restore --security --dir C:\custom-backup-location
To restore the data for all supported services at once, the --all
flag can be used instead of listing out each individual service. Using --all
will require that you include the --secret
flag for services that require encrypting backed up data for security:
nislmigrate restore --all --secret <password>
To modify entries in the database in-place without doing a restore run the tool with elevated permissions and use the modify
option. modify
currently only works to modify the --files
service database entries.
Using modify
with any other migrators (i.e. --tags
) will no do anything.
After moving the storage location of the files uploaded to the Files service the database will need to be updated to reflect the new location. The --files-change-file-store-root
argument can be used for this, either as part of a restore
operation or in-place as part of a modify
operation. When used with restore
the old root location is inferred from the database. When used with modify
the old root location must be specified with the --files-file-store-root
argument.
⚠️ modify
will modify the database directly. A backup of the database should be taken before any modifications usingnislmigrate capture --files --files-metadata-only
To modify the files root location after moving the files to a new drive:
cp -r -f C:\old\file\store X:\new\file\store
nislmigrate modify --files --files-change-file-store-root X:\new\file\store --files-file-store-root C:\old\file\store
To modify the files root location after moving the files to an S3 bucket:
aws s3 sync C:\old\file\store s3://my-systemlink-bucket/my-files
nislmigrate modify --files --files-change-file-store-root s3://my-systemlink-bucket/my-files --files-file-store-root C:\old\file\store --files-switch-to-forward-slashes
⚠️ Server B must be a clean SystemLink installation, any existing data will be deleted.
To migrate from one SystemLink server instance (server A
) to a different instance (server B
):
- Install the migration tool on
server A
andserver B
. - Follow the backup instructions to backup the data from
server A
. - Copy the data produced by the backup of
server A
onserver B
. - Warning: Ensure
server B
is a clean SystemLink installation, any existing data will be deleted. - Follow the restore instructions to restore the backed up data onto
server B
.
See CONTRIBUTING.MD
for detailed instructions on developing, testing, and releasing the tool.
The services that can be migrated with this utility along with short descriptions can be listed by running:
nislmigrate capture -h
Most services require migrating the --security
service at the same time for the migration to be successful, and some services have additional dependencies which are listed in the table below.
Supported Service | Argument Flag | Also requires migrating | Additional Notes |
---|---|---|---|
Security | --security |
||
User Data | --userdata |
--security |
|
Notifications | --notification |
--security |
|
File Ingestion | --files |
--security |
- Must migrate file to the same storage location on the new System Link server. - To capture/restore only the database but not the files themselves, use --files --files-metadata-only . This could be useful if, for example, files are stored on a file server with separate backup.- If files are stored in Amazon Simple Storage Service (S3), use --files --files-metadata-only .- If the file store path is different on the server you are restoring to, use the --files-change-file-store-root [NEW_ROOT] flag to update the metadata of all files to point to the new root during a restore operation.- If you have uploaded your local files to S3 and need to update the file path metadata, use --files-change-file-store-root [S3://<bucket-name>/<folder-path-if-applicable>] along with --files-switch-to-forward-slashes . |
Repository | --repo |
--security |
- Feeds may require additional updates if servers used for migration have different domain names |
Dashboards and Web Applications | --dashboards |
--security |
|
System States | --systemstates |
--security |
- Feeds may require additional updates if servers used for migration have different domain names - Cannot be migrated between 2020R1 and 2020R2 servers |
Tag Ingestion and Tag History | --tags |
--security |
|
Tag Alarm Rules | --tagrule |
--security --notification |
|
Alarm Instances | --alarms |
--security --notification |
- Cannot be migrated between 2020R1 and 2020R2 servers |
Asset Alarm Rules | --assetrule |
--security --notification |
|
Asset Management | --assets |
--security --files --tags |
|
Test Monitor | --testmonitor |
--security --file |
|
Systems | --systems |
--security --tags --file |
- WARNING: Captured systems data contains encrypted secret information and should not be copied to a publicly accessible location. - To capture/restore systems, a secret must be provided using the --secret <SECRET> command line flag. Captured systems data will require the same secret to be provided as was provided during capture in order to be able to decrypt sensitive data. |
There are plans to support the following services in the future:
- OPC UA Client:
--opc
- TDM
--tdm
- Cloud Connector
--cloud