KNIME Documentation

Disaster recovery and resilience ​

What data is stored ​

The following types of data are stored within your Knime instance:

  • Workflows — workflow files uploaded or deployed to the platform, and files uploaded into spaces
  • Job outputs — results and intermediate data from workflow executions
  • Configuration data — execution context settings, customization profiles, team settings
  • Logs — execution and audit logs
  • Metadata — item metadata, version history, access records
  • User accounts — usernames, roles, team memberships

Storage principles ​

Knime manages the cloud infrastructure that stores your data. Persistent data is offloaded from the Kubernetes cluster onto cloud-managed services. Workflows, components, files, models, and space data are stored in Amazon S3 or Azure Blob Storage, depending on your chosen cloud, and relational data sits in a managed Postgres service. Storage survives node failures and uses the provider's built-in backup, replication, and scaling.

Data is encrypted both in transit and at rest, and storage containers are private by default. File names and paths in object storage are obfuscated, so your data isn't directly identifiable through storage metadata. Access to the underlying storage is restricted to a small group of authorized Knime operations personnel under strict role-based controls, performed only when necessary, for example for incident response or support. Every access is logged and auditable.

Backup behavior ​

In Knime, backup and recovery are fully managed for you. Restores are initiated by submitting a support request. Persistent data in databases and physical volumes is captured every 4 hours through the snapshot and backup capabilities of the underlying managed cloud services, and stored within the same region. Versioning is enabled in object storage so workflows, components, files, models, and any space data can be restored to a prior point in time. The baseline disaster-recovery capability is included with every subscription. It covers the failure of a single Availability Zone, loss of a physical volume, or a database crash with data loss or corruption.

For protection against a full region outage, the optional Premium Disaster Recovery add-on provides continuous cross-region replication and a defined failover process with contractual recovery commitments. See Premium Disaster Recovery add-on for details.

Premium Disaster Recovery add-on ​

The Premium Disaster Recovery add-on is an optional feature for Knime, available only with a Private environment deployment. It extends the standard backup behavior with continuous cross-region replication and a defined failover process, protecting against a full cloud region outage. The standard backup behavior covers single Availability Zone failures, volume loss, and database crashes. The Premium Disaster Recovery add-on covers the loss of an entire cloud region.

The add-on includes contractual recovery time and data recovery point objectives. The specific targets are defined in the Premium Disaster Recovery Service addendum.

Premium Disaster Recovery covers your Knime instance as operated by Knime. It doesn't extend to your own network, identity providers, or third-party services integrated with the instance — reconnecting these after a failover may require reconfiguration on your end.

Definitions ​

  • Primary region — the cloud region where your production Knime instance runs
  • Secondary region — the cloud region where data is replicated from the primary region, with a pilot light deployment ready for failover
  • Pilot light — a disaster recovery strategy that keeps a minimal, continuously running core of infrastructure and data replication in the secondary region, ready to scale up to full production capacity during a failover
  • Data replication — continuously copying and synchronizing data from the primary region to the secondary region to minimize data loss during a failover
  • Failover — transferring operations from a failed primary region to the secondary region to restore service availability
  • Failback — transferring operations from the secondary region back to the primary region once it's fully restored and verified
  • CloudOps — Knime's team responsible for managing, monitoring, and optimizing the cloud infrastructure behind your instance
  • Designated contact — the person your organization names as the point of contact for failover communications and decisions

How failover works ​

When a regional outage is detected, Knime follows this process:

  1. Detection — Automated monitoring alerts CloudOps. CloudOps engages within 15 minutes of the initial alert.
  2. Assessment — CloudOps determines whether the cloud provider has published information about a regional failure and whether it has given an estimated time of recovery. If the provider indicates imminent recovery, Knime waits rather than triggering an unnecessary failover.
  3. Notification — Once the failover conditions are met, Knime immediately notifies your designated contact. The notification includes, at minimum:
    • Confirmation that Knime has declared a failover event
    • The expected timing for failover activities
    • Contact information so you can acknowledge, defer, or decline the failover
    • The estimated time to recovery
  4. Your response — You have 30 minutes to confirm, defer, or decline the failover. If you don't respond within the time limit, Knime proceeds with the failover. Knime provides ongoing status updates to your designated contact through resolution of the incident.
  5. Failover — Recovery begins after your confirmation. In the secondary region, Knime:
    • Configures and deploys the required infrastructure
    • Restores the latest backup data to databases and disk volumes
    • Deploys the application referencing the recovered data sources
    • Runs tests to confirm the application is healthy
    • Updates DNS records to route traffic to the secondary region
    • Notifies your designated contact with the failover status and data recovery point
  6. Failback — Once the cloud provider restores full operational service to the primary region, Knime coordinates a controlled failback and gives you advance notice of the planned timing to minimize disruption to your workloads.

What you need to do ​

  • Agree with Knime on one or more emergency communication channels for notifications, such as an email address or phone number.
  • Designate a technical contact during onboarding. Knime uses this contact for all failover notifications.
  • Provide the designated contact's information as part of onboarding.
  • Respond to failover notifications within the response window. If you don't respond, Knime proceeds with the failover automatically.

When recovery objectives do not apply ​

The RTO and RPO commitments do not apply in these situations:

  • The cloud provider outage affects both the primary and secondary regions at the same time
  • The outage falls within a scheduled maintenance window for which Knime gave advance notice
  • Your account was suspended or terminated
  • You chose to defer or decline the failover, for the duration of the deferral or for the entire declined event
  • Your designated technical contact was not assigned or did not respond within the response window

INFO

For the complete procedure, service credit schedules, and remedies, see the Premium Disaster Recovery Service addendum. The add-on is subject to additional fees.

Data export and customer exit ​

Export during an active subscription ​

Export your data from Knime at any time as part of normal usage, independent of any backup, restore, or end-of-subscription process. Download workflows and components directly from the interface as Knime workflow (.knwf) or workflow group (.knar) archives, for backup or to import into another Knime instance. Download files held in spaces, such as datasets, models, and supporting documents, individually through the same interface. Use the REST API to script bulk or repeated exports. Your existing permissions apply throughout — you can only access and export content within your teams and spaces.

Export after termination ​

When you terminate your Knime subscription, you may have your data returned rather than destroyed. This follows the Data Processing Agreement between you and Knime AG. The export covers the content held in your instance, including workflows, components, files, models, and space data. Coordinate the format, delivery mechanism, and timing of the export with Knime support at the time of termination — this can be tailored to your environment and security requirements. Once you receive and accept the export, Knime decommissions your instance and applies the deletion process described in Deletion after termination to the remaining data.

EU Data Act

Knime supports your access to user-generated data — including workflows, model outputs, configuration data, logs, and metadata — in structured, commonly used formats, in line with EU Data Act requirements.

Deletion after termination ​

When you terminate your Knime subscription, your data is handled according to the Data Processing Agreement between you and Knime AG. Under the DPA, your data is either returned to you or destroyed upon contract termination, at your election. Knime decommissions your instance, including the managed database and the associated object-storage containers holding workflows, components, files, models, and space data. No data remains in the active environment. Any residual copies held in backups and cross-region replicas are removed according to the retention schedule defined in the DPA.

Personal data

Processing of personal data is governed exclusively by the Data Processing Addendum (DPA). For details on categories of personal data, data subjects, subprocessors, and processing instructions, refer to the DPA.