About storage
Each DataMiner System requires its own system data storage. This data storage serves as a repository for configuration data, historical parameter information, and alarm data.
The recommended system data storage architecture is Storage as a Service (STaaS) on dataminer.services. With StaaS, you do not need to maintain the databases yourself, and all the scaling and complexity is taken care of for you.
| self-managed | Skyline-hosted (SaaS) | all features available | scalable | easy installation | automatic backups | effortless maintenance | |
|---|---|---|---|---|---|---|---|
| Storage as a Service (STaaS) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
| Dedicated clustered storage | ✔️ | ✔️ | ✔️ | ||||
| Storage per DMA | ✔️ |
Though this is not recommended, you can also host and manage the DataMiner storage yourself. In that case, you will need to configure a dedicated clustered storage setup, using a Cassandra-compatible database service and an indexing database (i.e. a Search Cluster). While all features are also available with this setup, managing and maintaining it is a great deal more complex.
Instead of a dedicated clustered storage setup, older systems often still use storage per DMA with Cassandra or (prior to DataMiner 10.6) MySQL, but this is setup is considered obsolete and not all DataMiner features are available if it is used. We highly recommend migrating to a STaaS setup instead. Note that this requires a migration to Cassandra first, which must be done using a DataMiner version prior to 10.3.0 [CU6]/10.3.6, as this migration is no longer supported from these DataMiner versions onwards.
Tip
See also:
Note
- When the main database is offline, file offloads are used to store write/delete operations. You can configure a limit for the file size of these offloads in the file DBConfiguration.xml.
- You can also configure data offloads to a separate database or to files, for example in order to produce all kinds of reports without interfering with the live DataMiner System.