Back up Instaclustr for Apache Kafka to your own storage
Instaclustr (part of NetApp) runs unmodified open source Kafka across AWS, Azure, and GCP, and its documented cluster backups cover metadata and configuration — not the records in your topics. OSO Kafka Backup connects to your Instaclustr cluster as a standard Kafka client over SASL/SCRAM, then streams compressed topic records, consumer group offsets, and configuration into a bucket you control, and restores any of it to a precise moment in time.
Who backs up your data on Instaclustr
An instaclustr kafka backup has a narrower scope than most teams assume. Instaclustr's documented cluster backups capture Kafka metadata and configuration — the state needed to rebuild the cluster itself. The message data in your topics is not part of that backup. It is your data, under a conventional managed-service split: Instaclustr operates and secures the cluster; you own what flows through it.
Managed durability also is not the same thing as restore. Replication and automated failover protect against infrastructure loss, not against a bad deploy that poisons a topic or an accidental delete. Instaclustr's managed MirrorMaker 2 copies streams to another cluster, but replication forwards mistakes as faithfully as good records. The disaster recovery use cases cover the failure modes that need an independent point-in-time copy.
Because Instaclustr runs unmodified Apache Kafka, OSO Kafka Backup needs no Instaclustr-specific integration. It connects to the bootstrap servers from your cluster's Connection Info page and reads topics like any ordinary client.
Connecting to Instaclustr for Apache Kafka
Instaclustr's default client authentication is SASL with username and password, using SCRAM-SHA-256 over TLS when client-to-broker encryption is enabled. Download the cluster CA certificate from the console's Connection Info page, and add the backup host to the cluster's allowed addresses so the firewall admits it. Use port 9092 from the public network, or 9093 over the private network when the backup runs inside your VPC. Every key below comes from the configuration reference.
- Public network
- Private network (9093)
- Run it
mode: backup
backup_id: instaclustr-prod-daily
source:
bootstrap_servers:
- broker1.myclusterid.cnodes.instaclustr.com:9092
- broker2.myclusterid.cnodes.instaclustr.com:9092
- broker3.myclusterid.cnodes.instaclustr.com:9092
security:
security_protocol: SASL_SSL
sasl_mechanism: SCRAM-SHA256
sasl_username: ickafka
sasl_password: ${INSTACLUSTR_KAFKA_PASSWORD}
ssl_ca_location: /etc/kafka-backup/instaclustr/cluster-ca.pem
storage:
backend: gcs
bucket: my-kafka-backups
prefix: instaclustr/production
backup:
compression: zstd
mode: backup
backup_id: instaclustr-prod-daily
source:
bootstrap_servers:
- broker1.myclusterid.cnodes.instaclustr.com:9093
- broker2.myclusterid.cnodes.instaclustr.com:9093
- broker3.myclusterid.cnodes.instaclustr.com:9093
security:
security_protocol: SASL_SSL
sasl_mechanism: SCRAM-SHA256
sasl_username: ickafka
sasl_password: ${INSTACLUSTR_KAFKA_PASSWORD}
ssl_ca_location: /etc/kafka-backup/instaclustr/cluster-ca.pem
connection:
tcp_keepalive: true
storage:
backend: gcs
bucket: my-kafka-backups
prefix: instaclustr/production
backup:
compression: zstd
kafka-backup backup --config instaclustr-backup.yaml
What gets backed up
Every backup captures topic records with their timestamps and headers, consumer group offsets, and topic configuration, compressed with Zstd or LZ4. Because Instaclustr runs on AWS, Azure, and GCP, the backup target can match your cloud — S3, Azure Blob, or GCS — or sit in a different provider entirely for isolation from the cluster's failure domain.
Restores can target the original Instaclustr cluster or a different one — including a self-managed cluster on another distribution — with topic and partition remapping. That makes backup and restore double as a migration path on or off Instaclustr. Backing up a Schema Registry alongside topic data is an OSO Enterprise capability; the open source tool captures topic records, offsets, and configuration.
Frequently asked questions
Does Instaclustr back up my Kafka topic data?
Instaclustr’s documented cluster backups cover Kafka metadata and configuration — the state needed to rebuild the cluster — not the records in your topics. Topic data is yours under the managed-service responsibility split. An independent, consumer-based backup into storage you control closes that gap.
How does OSO Kafka Backup authenticate to Instaclustr?
With Instaclustr’s standard client settings: SASL_SSL with SCRAM-SHA256, using a Kafka user and password you create in the console, plus the cluster CA certificate from the Connection Info page pointed at by ssl_ca_location. No Instaclustr-specific integration is needed.
Do I need firewall changes to run backups?
Yes — Instaclustr clusters only accept connections from allowed addresses. Add the backup host’s IP (or security group) to the cluster’s firewall rules. Use port 9092 from the public network, or port 9093 when connecting over the private network from inside your VPC.
Is Instaclustr’s managed MirrorMaker 2 enough for disaster recovery?
It covers replication, not backup. MirrorMaker 2 mirrors streams to a second cluster for failover, and it forwards bad writes and deletes just as faithfully as good records. Point-in-time restore of a poisoned or deleted topic requires an independent backup with its own retention.
Can I restore an Instaclustr backup to a different cluster?
Yes. Restores can target the original cluster or any other reachable Kafka cluster, with topic and partition remapping. Since Instaclustr runs unmodified Apache Kafka, backups move cleanly between Instaclustr, self-managed, and other managed clusters.
Ready to protect your Kafka data?
Take your first backup in minutes with the open source CLI, or talk to us about Enterprise features like encryption, RBAC, and audit logging.