Table of Contents

STaaS features

Data location and redundancy

DataMiner STaaS relies on Azure Storage, which stores multiple copies of your data to make sure it is always available even in case outages or disasters occur. Different storage redundancy setups are possible. STaaS supports zone-redundant storage (ZRS) and geo-redundant storage (GRS).

When you use the installation wizard or contact Skyline to register your system to use STaaS, you can include your preferences as to the region(s) where your data should be stored and the type of storage redundancy that should be used.

Region Location Status Geo-Redundancy Pair for GRS (on request)
West Europe The Netherlands Live North Europe (Ireland)
UK South London, UK Live UK West (Cardiff)
Central US Iowa, USA Live East US 2 (Virginia)
Southeast Asia Singapore Live East Asia (Hong Kong SAR)
UAE North Dubai, UAE On request (no extra charge) UAE Central (Abu Dhabi)
Australia East New South Wales, AUS On request (no extra charge) Australia Southeast (Victoria)
Other Regions See full list Supported on request (extra cost) See full list
  • Zone-redundant storage (ZRS) copies your data synchronously across three Azure availability zones in one region. Each availability zone is a separate physical location with independent power, cooling, and networking. By default, DataMiner STaaS uses ZRS.

  • Geo-redundant storage (GRS) copies your data synchronously three times within a single physical location in the primary region and then also copies your data asynchronously to a single physical location in the secondary region. Only specific regions can be combined in such a setup, e.g. if the primary region is Switzerland North, the secondary region can only be Switzerland West. For an overview of the supported regions, see Azure paired regions. GRS is available upon request, but will result in additional charges. If you wish to use DataMiner STaaS with GRS, contact support@dataminer.services.

Tip

For detailed information, see Azure Storage redundancy on learn.microsoft.com

Data resilience and backups

To ensure data resilience for potential recovery scenarios, protecting against user errors and accidental changes, your data is backed up with a granularity of 1 day. Backups are stored for 30 days.

  • Daily backups: STaaS performs backups with a granularity of 1 day and maintains a 30-day rolling snapshot of your data.

  • Data restoration and support: In the event a rollback is necessary, our support team will assist you. To submit a rollback request, contact the support team by sending an email to support@dataminer.services. They will guide you through the necessary steps to ensure a successful data restoration.

Important

When you disconnect a system from dataminer.services or remove a DaaS system, all STaaS data for that specific system, including backups, will be removed 7 days after you take this action. Upon request, all STaaS data can be recovered within those 7 days.

Data security and availability

With STaaS, the data for a specific DMS is isolated in a logical partition. You can only ever access the logical partition dedicated to your own DMS, and all partitions are strictly isolated from each other.

To access your data, you use a connection authenticated with a Service Principal. With this connection, you can only access the logical partition dedicated to a specific DMS, which means that all data of a DMS is strictly isolated.

The data is encrypted both at rest and in transit.

If ZRS is used, STaaS has an expected availability of 99.90%. With GRS, it has an expected availability of 99.95%. For more information, please contact sales@skyline.be.

TTL

In the table below, you can find the default time-to-live (TTL) values for each data type.

Data type TTL
Real-time trending 7 days
Average trending (short – default 5 min.) 3 months
Average trending (medium – default 1 hour) 2 years
Average trending (long – default 2 hours) 10 years
State changes 5 years
Spectrum traces 1 year
Alarm events 1 year

Custom configuration of TTL values can be requested via a support ticket.

Throttling

If your system is pushing too much load for a specific data type, that data type will be throttled. This could for example happen when you have an element that is continuously saving parameter updates.

From DataMiner 10.4.0 [CU14]/10.5.0 [CU2]/10.5.5 onwards, when this happens, an alarm will be generated in Cube with information about the data type or types that are being throttled. For example:

ThrottlingAlarmExample

If you encounter such an alarm, to ensure smooth operation of your DataMiner System, try to identify and resolve the root cause of this higher load.

Limitations

To migrate existing data to STaaS, the following limitations apply:

  • Migration is supported from DataMiner 10.4.0 [CU2]/10.4.5 onwards.

  • Migration of a setup with multiple OpenSearch/Elasticsearch clusters is not yet supported.

  • Direct migration from a MySQL setup is not supported. We recommend using .dmimport files (also known as "DELT export packages") to migrate your data, or contacting support for assistance with the migration.

  • Migration using a proxy is supported from DataMiner 10.4.6 onwards.

  • If you start the migration while an element with a logger table is stopped, the data of that element will not be migrated.

In addition, the following other limitations currently apply: