Back up Schema Registry with the topics that depend on it

Kafka Schema Registry backup in the same config​

Kafka Schema Registry backup is one section added to the config you already run. The Enterprise edition captures every subject, every schema version, references, and both global and per-subject compatibility settings — in the same job as the topic data, stored in the same backend.

That coupling matters. A topic backup and a schema backup taken at different times can disagree, and a registry rebuilt from the wrong snapshot leaves consumers unable to deserialize restored records.

mode: backup
backup_id: "daily-with-schemas"

source:
bootstrap_servers:
  - broker-1.kafka.svc:9092
topics:
  include:
    - orders
    - payments

storage:
backend: s3
bucket: my-kafka-backups
region: us-west-2

enterprise:
schema_registry:
  url: "https://schema-registry:8081"
  auth:
    type: basic
    username: ${SR_USERNAME}
    password: ${SR_PASSWORD}
  backup:
    subjects:
      - "orders-*"
      - "payments-*"
    exclude:
      - "*-test"
    include_versions: all

kafka-backup-enterprise backup --config backup.yaml

# Schema-only snapshot (no Kafka data) — e.g. for a compliance archive
kafka-backup-enterprise backup --config backup.yaml --schema-only

mode: restore
backup_id: "daily-with-schemas"

target:
bootstrap_servers:
  - dr-broker-1.kafka.svc:9092
topics:
  include: [orders, payments]

storage:
backend: s3
bucket: my-kafka-backups
region: us-west-2

enterprise:
schema_registry:
  url: "https://dr-schema-registry:8081"
registry_restore:
  source: confluent
  destination: confluent
  id_policy: preserve
  serializers:
    orders:
      key:
        source: {type: raw}
        target: {type: raw}
      value:
        source: {type: confluent, namespace: ""}
        target: {type: confluent, namespace: ""}
    payments:
      key:
        source: {type: raw}
        target: {type: raw}
      value:
        source: {type: confluent, namespace: ""}
        target: {type: confluent, namespace: ""}

Choose original IDs or allocated IDs​

Enterprise 0.6.1 restores and verifies registries before normal, three-phase and repartitioned Kafka replay. Original-ID preservation is the default. Allocation uses enterprise.registry_restore.id_policy: rewrite and explicit key/value serializer profiles; configure the actual framing used by your application. The example above assumes raw keys and Confluent numeric-framed values.

Confluent self-hosted and Apicurio v2/v3 are supported. Cross-provider migrations require coordinate mappings for every selected subject/artifact and dependency. Destructive overwrite is rejected, and skip requires verified equivalence. Missing IDs, unsupported semantics and cleanup/verification failures block Kafka replay. Confluent Cloud registry restore, rule-bearing replay and native Apicurio nested Protobuf are outside the 0.6.1 release scope.

kafka-backup-enterprise validate-restore --config restore.yaml --format json
kafka-backup-enterprise restore --config restore.yaml

# Registry-only validation and recovery
kafka-backup-enterprise validate-restore --config restore.yaml --schema-only --format json
kafka-backup-enterprise restore --config restore.yaml --schema-only

See the Enterprise Schema Registry restore guide for complete configurations, tested versions, framing profiles and recovery limits. A trial or licence with schema_registry is required when registry restoration is configured; unavailable entitlement fails before Kafka replay.