Back up, aggregate, and restore (online)

For performing backups, Neo4j uses the Admin Service, which is only available inside the Kubernetes cluster and access to it should be guarded. For more information, see Accessing Neo4j.

Backup storage options

Neo4j’s Helm chart supports both full and differential backups and can be configured to use cloud providers or local storage.

Cloud storage

Neo4j Helm chart uses Neo4j’s native cloud storage integration with direct upload to create immutable backup objects. This allows you to back up your Neo4j databases directly to cloud storage without the need for persistent volumes. The chart can be configured to use cloud providers, such as AWS S3, Google Cloud Storage, and Azure Blob Storage, by setting the cloudProvider parameter to aws, gcp, or azure in the backup-values.yaml file.

The following features are supported:

  • Direct cloud storage upload - local storage is needed for downloading the database store files and transaction logs which are then streamed to cloud storage directly.

  • Differential backup chains with preferDiffAsParent: true.

  • Immutable backup objects in cloud storage.

  • Support for S3-compatible endpoints.

  • Enhanced S3 configuration including custom CA certificates and endpoint settings.

Local storage

Local storage creates local backups in the /backups mount. This mount must be configured to use a persistent storage for large databases using tempVolume. The cloudProvider must be empty.

Prepare to back up a database(s) to a cloud provider (AWS, GCP, and Azure) bucket

You can perform a backup of a Neo4j database(s) to any cloud provider (AWS, GCP, and Azure) bucket using the neo4j/neo4j-admin Helm chart. The neo4j/neo4j-admin Helm chart also supports performing a backup of multiple databases, workload identity integration for GCP, AWS, and Azure, and Deprecated in 5.26 MinIO (an AWS S3-compatible object storage API) for Non-TLS/SSL endpoints.

Prerequisites

Before you can back up a database and upload it to your bucket, verify that you have the following:

When using cloud providers, differential backups do not require persistent volumes with previous backups. Instead, the chart will first create a full backup in the cloud storage, and then, the subsequent backups will be differential backups that reference this full backup.

Create a Kubernetes secret

You can create a Kubernetes secret with the credentials that can access the cloud provider bucket using one of the following options:

Create the secret named gcpcreds using your GCP service account JSON key file. The JSON key file contains all the details of the service account that has access to the bucket.

kubectl create secret generic gcpcreds --from-file=credentials=/path/to/gcpcreds.json
  1. Create a credentials file in the following format:

    [ default ]
    region = us-east-1
    aws_access_key_id = <your-aws_access_key_id>
    aws_secret_access_key = <your-aws_secret_access_key>
  2. Create the secret named awscreds via the credentials file:

    kubectl create secret generic awscreds --from-file=credentials=/path/to/your/credentials
  1. Create a credentials file in the following format (before 2025.06):

    AZURE_STORAGE_ACCOUNT_NAME=<your-azure-storage-account-name>
    AZURE_STORAGE_ACCOUNT_KEY=<your-azure-storage-account-key>

    Starting with Neo4j 2025.06, update your credentials secret as follows:

    # Azure credentials file
    AZURE_STORAGE_ACCOUNT=<your_account>
    AZURE_STORAGE_KEY=<your_key>
    AZURE_CLIENT_ID=<your_service_principal_id>
    AZURE_CLIENT_SECRET=<your_service_principal_secret>
    AZURE_TENANT_ID=<your_tenant_id>
  2. Create the secret named azurecred via the credentials file:

    kubectl create secret generic azurecred --from-file=credentials=/path/to/your/credentials

Configure the backup parameters

You can configure the backup parameters in the backup-values.yaml file either by using the secretName and secretKeyName parameters or by mapping the Kubernetes service account to the workload identity integration.

The following examples show the minimum configuration required to perform a backup to a cloud provider bucket. For more information about the available backup parameters, see Backup parameters.

Configure the backup-values.yaml file using the secretName and secretKeyName parameters

neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName:  "standalone-admin" #This is the Neo4j Admin Service name.
  database: "neo4j,system"
  cloudProvider: "gcp"
  secretName: "gcpcreds"
  secretKeyName: "credentials"
  # Enable cloud-native differential backups
  preferDiffAsParent: true
  type: "AUTO"  # First backup will be FULL, subsequent ones DIFF
  fallbackToFull: true

consistencyCheck:
  enabled: true
neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName:  "standalone-admin"
  database: "neo4j,system"
  cloudProvider: "aws"
  secretName: "awscreds"
  secretKeyName: "credentials"
  # Enable cloud-native differential backups
  preferDiffAsParent: true
  type: "AUTO"  # First backup will be FULL, subsequent ones DIFF
  fallbackToFull: true

consistencyCheck:
  enabled: true
neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName:  "standalone-admin"
  database: "neo4j,system"
  cloudProvider: "azure"
  secretName: "azurecreds"
  secretKeyName: "credentials"
  # Enable cloud-native differential backups
  preferDiffAsParent: true
  type: "AUTO"  # First backup will be FULL, subsequent ones DIFF
  fallbackToFull: true

consistencyCheck:
  enabled: true

Configure the backup-values.yaml file using service account workload identity integration

In certain situations, it may be useful to assign a Kubernetes Service Account with workload identity integration to the Neo4j backup pod. This is particularly relevant when you want to improve security and have more precise access control for the pod. Doing so ensures that secure access to resources is granted based on the pod’s identity within the cloud ecosystem. For more information on setting up a service account with workload identity, see Google Kubernetes Engine (GKE) → Use Workload Identity, Amazon EKS → Configuring a Kubernetes service account to assume an IAM role, and Microsoft Azure → Use Microsoft Entra Workload ID with Azure Kubernetes Service (AKS).

To configure the Neo4j backup pod to use a Kubernetes service account with workload identity, set serviceAccountName to the name of the service account to use. For Azure deployments, you also need to set the azureStorageAccountName parameter to the name of the Azure storage account, where the backup files will be uploaded. For example:

neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName:  "standalone-admin" #This is the Neo4j Admin Service name.
  database: "neo4j,system"
  cloudProvider: "gcp"
  secretName: ""
  secretKeyName: ""
  # Enable cloud-native differential backups
  preferDiffAsParent: true
  type: "AUTO"  # First backup will be FULL, subsequent ones DIFF
  fallbackToFull: true

consistencyCheck:
  enabled: true

serviceAccountName: "demo-service-account"
neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName:  "standalone-admin"
  database: "neo4j,system"
  cloudProvider: "aws"
  secretName: ""
  secretKeyName: ""
  # Enable cloud-native differential backups
  preferDiffAsParent: true
  type: "AUTO"  # First backup will be FULL, subsequent ones DIFF
  fallbackToFull: true

consistencyCheck:
  enabled: true

serviceAccountName: "demo-service-account"
neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName:  "standalone-admin"
  database: "neo4j,system"
  cloudProvider: "azure"
  azureStorageAccountName: "storageAccountName"
  # Enable cloud-native differential backups
  preferDiffAsParent: true
  type: "AUTO"  # First backup will be FULL, subsequent ones DIFF
  fallbackToFull: true

consistencyCheck:
  enabled: true

serviceAccountName: "demo-service-account"

The /backups mount created by default is an emptyDir type volume. This means that the data stored in this volume is not persistent and will be lost when the pod is deleted. To use a persistent volume for backups add the following section to the backup-values.yaml file:

tempVolume:
  persistentVolumeClaim:
    claimName: backup-pvc

You need to create the persistent volume and persistent volume claim before installing the neo4j-admin Helm chart only when using local storage. When using cloud providers, persistent volumes are not required for differential backups. For more information, see Volume mounts and persistent volumes.

Configure S3-compatible storage endpoints

The backup system supports any S3-compatible storage service. You can configure both TLS and non-TLS endpoints using the following parameters in your backup-values.yaml file:

backup:
  # Specify your S3-compatible endpoint (e.g., https://s3.amazonaws.com or your custom endpoint)
  s3Endpoint: "https://s3.custom-provider.com"

  # Enable TLS for secure connections (default: false)
  s3EndpointTLS: true

  # Optional: Provide a base64-encoded CA certificate for custom certificate authorities
  s3CACert: "base64_encoded_ca_cert_data"

  # Optional: Skip TLS verification (not recommended for production)
  s3SkipVerify: false

  # Optional: Force path-style addressing for S3 requests
  s3ForcePathStyle: true

  # Optional: Specify S3 region
  s3Region: "us-east-1"

  # Alternative: Use Kubernetes secret for CA certificate
  s3CASecretName: "s3-ca-cert"
  s3CASecretKey: "ca.crt"

The following are examples of how to configure the backup system for different S3-compatible storage providers:

AWS S3 standard endpoint
neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName: "standalone-admin"
  s3Endpoint: "https://s3.amazonaws.com"
  s3EndpointTLS: true
  database: "neo4j,system"
  cloudProvider: "aws"
  secretName: "awscreds"
  secretKeyName: "credentials"

consistencyCheck:
  enabled: true
Custom S3-compatible provider with self-signed certificate
backup:
  bucketName: "my-bucket"
  s3Endpoint: "https://custom-s3.example.com"
  s3EndpointTLS: true
  s3CACert: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0t..."  # Base64-encoded CA cert
  cloudProvider: "aws"
  secretName: "awscreds"
  secretKeyName: "credentials"
Legacy MinIO support
backup:
  bucketName: "my-bucket"
  databaseAdminServiceName: "standalone-admin"
  minioEndpoint: "http://minio.example.com:9000"  # Deprecated in 5.26: Use s3Endpoint instead
  database: "neo4j,system"
  cloudProvider: "aws"
  secretName: "awscreds"
  secretKeyName: "credentials"
  • The s3EndpointTLS parameter must be set to true when using HTTPS endpoints.

  • When using custom CA certificates, provide them base64-encoded in the s3CACert parameter.

  • The s3SkipVerify parameter should only be used in development environments.

  • Legacy MinIO support through the minioEndpoint parameter is deprecated in 5.26 - use s3Endpoint instead.

Configure S3 checksum behavior

The AWS SDK calculates and validates checksums for S3 requests and responses. By default, the SDK uses its standard checksum behavior. If you use an S3-compatible storage provider that does not support the checksum algorithms used by the AWS SDK, you can configure request checksum calculation and response checksum validation using the corresponding backup parameters. You can also disable multipart checksums when required by the storage provider.

If this is an S3-compatible service and you see errors such as checksum mismatches or unsupported checksum headers, then configure the following:

backup:
  cloudProvider: "aws"
  bucketName: "my-bucket"
  s3Endpoint: "https://your-s3-compatible-endpoint"

  s3RequestChecksumCalculation: "WHEN_REQUIRED" (1)
  s3ResponseChecksumValidation: "WHEN_REQUIRED" (2)
  s3DisableMultipartChecksums: true (3)
1 (Optional) Controls when AWS SDK calculates request checksums. Valid values are WHEN_SUPPORTED (default), WHEN_REQUIRED. Set to WHEN_REQUIRED to disable automatic checksum calculation for custom S3 endpoints that do not support CRC32 or other checksum algorithms.
2 (Optional) Controls when AWS SDK validates response checksums. Valid values are WHEN_SUPPORTED (default), WHEN_REQUIRED. Set to WHEN_REQUIRED to disable automatic checksum validation for custom S3 endpoints.
3 (Optional) Disables multipart upload checksums entirely. The default value is false. Set to true to disable checksums for multipart uploads when using custom S3 endpoints. This sets AWS_S3_DISABLE_MULTIPART_CHECKSUMS environment variable.

S3 CA certificate setup

For S3 endpoints with custom CA certificates, use a Kubernetes secret to manage the CA certificate:

  1. Create the CA certificate secret:

    kubectl create secret generic s3-ca-cert --from-file=ca.crt=/path/to/your/ca.crt
  2. Configure the backup job:

    backup:
      cloudProvider: "aws"
      s3Endpoint: "https://your-s3-endpoint.com"
      s3CASecretName: "s3-ca-cert"
      s3CASecretKey: "ca.crt"
      s3EndpointTLS: true  # Automatically set when s3CASecretName is provided

Prepare to back up a database(s) to on-premises storage

You can perform a backup of a Neo4j database(s) to on-premises storage using the neo4j/neo4j-admin Helm chart. When configuring the backup-values.yaml file, keep the “cloudProvider” field empty and provide a persistent volume in the tempVolume section to ensure the backup files are persistent if the pod is deleted.

You need to create the persistent volume and persistent volume claim before installing the neo4j-admin Helm chart only when using local storage. When using cloud providers, persistent volumes are not required for differential backups. For more information, see Volume mounts and persistent volumes.

For example:

neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"
  jobSchedule: "* * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  backoffLimit: 3

backup:
  bucketName: "my-bucket"
  databaseAdminServiceName:  "standalone-admin"
  database: "neo4j,system"
  cloudProvider: ""

consistencyCheck:
  enabled: true

tempVolume:
  persistentVolumeClaim:
    claimName: backup-pvc

Backup parameters

To see what options are configurable on the Helm chart use helm show values and the Helm chart neo4j/neo4j-admin.
The neo4j/neo4j-admin Helm chart also supports assigning your Neo4j pods to specific nodes using nodeSelector labels, and affinity/anti-affinity rules or tolerations. For more information, see Assigning backup pods to specific nodes and the Kubernetes official documentation on Affinity and anti-affinity rules and Taints and Tolerations.

For example:

helm show values neo4j/neo4j-admin
## @param nameOverride String to partially override common.names.fullname
nameOverride: ""
## @param fullnameOverride String to fully override common.names.fullname
fullnameOverride: ""
# disableLookups will disable all the lookups done in the helm charts
# This should be set to true when using ArgoCD since ArgoCD uses helm template and the helm lookups will fail
# You can enable this when executing helm commands with --dry-run command
disableLookups: false

neo4j:
  image: "neo4j/helm-charts-backup"
  imageTag: "2026.7.1"

  # Optional registry for backup image, e.g., "my.private.registry.com"
  registry: ""

  # imagePullSecrets for pulling the backup image from private registries
  imagePullSecrets: []
  #  - name: my-docker-secret

  podLabels: {}
#    app: "demo"
#    acac: "dcdddc"
  podAnnotations: {}
#    ssdvvs: "svvvsvs"
#    vfsvswef: "vcfvgb"
  # define the backup job schedule . default is * * * * *
  jobSchedule: ""
  # default is 3
  successfulJobsHistoryLimit:
  # default is 1
  failedJobsHistoryLimit:
  # default is 3
  backoffLimit:
  #add labels if required
  labels: {}

backup:
  # Neo4j Backup Modes:
  # - Cloud Provider Mode (aws/gcp/azure): Uses Neo4j native cloud storage with direct upload to create immutable backup objects
  # - Local Mode (empty cloudProvider): Creates local backups in /backups mount - requires persistent storage for large databases
  # - Native cloud storage supports differential backups and eliminates need for persistent volume claims

  # Ensure the bucket is already existing in the respective cloud provider
  # In case of azure the bucket is the container name in the storage account
  # bucket: azure-storage-container
  #
  # Path prefix (folder) within the bucket: use '/' separator
  # Example: "my-bucket/backups" uses bucket "my-bucket" and path prefix "backups"
  # Backups are written to s3://my-bucket/backups/ (or equivalent for GCP/Azure)
  # No manual folder creation needed - cloud storage uses path prefixes in object keys
  bucketName: ""

  # Specify multiple backup endpoints as comma-separated string
  # e.g. "10.3.3.2:6362,10.3.3.3:6362,10.3.3.4:6362"
  databaseBackupEndpoints: ""

  #ex: standalone-admin.default.svc.cluster.local:6362
  # admin service name -  standalone-admin
  # namespace - default
  # cluster domain - cluster.local
  # port - 6362

  # Minio endpoint configuration
  minioEndpoint: ""
  #ex: 10.3.3.2:6362
  # admin service ip - 10.3.3.2
  # port - 6362

  databaseAdminServiceName: ""
  databaseAdminServiceIP: ""
  #default name is 'default'
  databaseNamespace: ""
  #default port is 6362
  databaseBackupPort: ""
  #default value is cluster.local
  databaseClusterDomain: ""
  # specify S3-compatible endpoint (e.g., https://s3.amazonaws.com or your custom S3 endpoint)
  # This can be any S3-compatible endpoint including AWS S3, MinIO, or other S3-compatible storage services
  # TLS is automatically enabled for https:// endpoints
  s3Endpoint: ""
  # Name of the Kubernetes secret containing the CA certificate for S3 endpoint TLS verification
  # Only needed for self-signed certificates or private CA
  s3CASecretName: ""
  # Key in the secret containing the CA certificate
  s3CASecretKey: ""
  # Optional: Skip TLS verification (not recommended for production)
  s3SkipVerify: false
  # Optional: Force path-style addressing (default: true)
  # Some S3-compatible storage providers require this to be set to true
  s3ForcePathStyle: true
  # Optional: Explicitly set the region for S3 signature calculation
  # For non-AWS S3 providers, this is often set to a fixed value like "us-east-1"
  s3Region: ""
  # Optional: Force a specific signature version (2 or 4)
  # Some S3-compatible storage providers only support signature version 2
  # Valid values: "2", "4", or "" (empty for auto-detection)
  s3SignatureVersion: ""

  # AWS SDK checksum configuration for S3 uploads
  # These settings control AWS SDK v2's automatic checksum calculation behavior
  # Useful for custom S3 endpoints that don't support AWS's newer checksum requirements

  # Optional: Control when AWS SDK calculates request checksums
  # Valid values: "WHEN_SUPPORTED" (default), "WHEN_REQUIRED"
  # Set to "WHEN_REQUIRED" to disable automatic checksum calculation for custom S3 endpoints
  # that don't support CRC32 or other checksum algorithms
  # IMPORTANT: For custom S3 endpoints experiencing "Checksum Type mismatch" errors,
  # set this to "WHEN_REQUIRED" to resolve the issue
  s3RequestChecksumCalculation: ""

  # Optional: Control when AWS SDK validates response checksums
  # Valid values: "WHEN_SUPPORTED" (default), "WHEN_REQUIRED"
  # Set to "WHEN_REQUIRED" to disable automatic checksum validation for custom S3 endpoints
  # IMPORTANT: For custom S3 endpoints experiencing checksum validation errors,
  # set this to "WHEN_REQUIRED" to resolve the issue
  s3ResponseChecksumValidation: ""

  # Optional: Disable multipart upload checksums entirely
  # Set to true to disable checksums for multipart uploads when using custom S3 endpoints
  # This sets AWS_S3_DISABLE_MULTIPART_CHECKSUMS environment variable
  # IMPORTANT: For custom S3 endpoints, set this to true along with the above checksum settings
  s3DisableMultipartChecksums: false

  # Note: When using AWS cloud provider, the chart automatically configures the AWS SDK
  # to use URLConnection HTTP client via JAVA_OPTS system property to avoid
  # "Unable to load HTTP implementation" errors in containerized environments

  #name of the database to backup ex: neo4j or neo4j,system (You can provide command separated database names)
  # In case of comma separated databases failure of any single database will lead to failure of complete operation
  database: ""
  # cloudProvider can be either gcp, aws, or azure
  # if cloudProvider is empty then the backup will be done to the /backups mount.
  # the /backups mount can point to a persistentVolume based on the definition set in tempVolume
  cloudProvider: ""

  # Cloud provider authentication
  # For cloud providers, credentials are used by Neo4j native backup for direct cloud storage access
  # name of the kubernetes secret containing the respective cloud provider credentials
  # Ensure you have read,write access to the mentioned bucket
  # For AWS :
  # add the below in a file and create a secret via
  # 'kubectl create secret generic awscred --from-file=credentials=/demo/awscredentials'

  #  [ default ]
  #  region = us-east-1
  #  aws_access_key_id = XXXXX
  #  aws_secret_access_key = XXXX

  # For AZURE :
  # add the storage account name and key in below format in a file create a secret via
  # 'kubectl create secret generic azurecred --from-file=credentials=/demo/azurecredentials'

  #  AZURE_STORAGE_ACCOUNT=XXXX
  #  AZURE_STORAGE_KEY=XXXX
  #  AZURE_CLIENT_ID=XXXX
  #  AZURE_CLIENT_SECRET=XXXX
  #  AZURE_TENANT_ID=XXXX

  # For GCP :
  # create the secret via the gcp service account json key file.
  # ex: 'kubectl create secret generic gcpcred --from-file=credentials=/demo/gcpcreds.json'
  # When using Workload Identity (via serviceAccountName), leave secretName empty
  secretName: ""
  # provide the keyname used in the above secret
  secretKeyName: ""
  # Cloud provider specific credential environment variables
  # These are set by Neo4j's native cloud storage clients for authentication
  # AWS: Path to AWS credentials file (will set AWS_SHARED_CREDENTIALS_FILE)
  awsCredentialsFile: ""
  # GCP: Path to Google Cloud service account key file (will set GOOGLE_APPLICATION_CREDENTIALS)
  gcpCredentialsFile: ""
  #
  # NOTE: When cloudProvider is set to "aws" or "gcp" and secretKeyName is provided,
  # the chart will automatically set AWS_SHARED_CREDENTIALS_FILE or GOOGLE_APPLICATION_CREDENTIALS
  # to "/credentials/secretKeyName". Use awsCredentialsFile/gcpCredentialsFile to override this default.
  # provide the azure storage account name
  # this to be provided when you are using workload identity integration for azure
  azureStorageAccountName: ""
  # Azure blob service URL for different Azure clouds
  # This configures both the Go SDK client and Neo4j's native backup via dbms.integrations.cloud_storage.azb.blob_endpoint_suffix
  # Default: "" (uses Neo4j default which is "blob.core.windows.net" for Azure Commercial)
  # Azure Government: "blob.core.usgovcloudapi.net"
  # See: https://neo4j.com/docs/operations-manual/current/configuration/configuration-settings/
  azureBlobServiceURL: ""
  #setting this to true will not delete the backup files generated at the /backup mount
  keepBackupFiles: true

  #Below are all neo4j-admin database backup flags / options
  #To know more about the flags read here : https://neo4j.com/docs/operations-manual/current/backup-restore/online-backup/
  pageCache: ""
  includeMetadata: "all"
  type: "AUTO"
  keepFailed: false
  parallelRecovery: false
  verbose: true
  heapSize: ""
  compress: true

  # Neo4j Native Cloud Storage Features
  # Enable differential backups - allows Neo4j to create differential backups directly to cloud storage
  # This creates backup chains where subsequent backups only store changes from previous backup
  preferDiffAsParent: false

  # Neo4j 2025.09+ feature: Enable remote address resolution for backup operations
  # This flag controls how remote addresses are resolved during backup operations
  remoteAddressResolution: false

  # Optional temporary directory for backup process when using cloud storage
  # If not specified, Neo4j will use a temporary directory inside the current working directory
  # This is strongly recommended when backing up to cloud storage to avoid disk space issues
  # on the local filesystem where Neo4j is installed
  tempDir: ""

  # https://neo4j.com/docs/operations-manual/current/backup-restore/aggregate/
  # Performs aggregate backup. If enabled, NORMAL BACKUP WILL NOT BE DONE only aggregate backup
  # fromPath supports only s3 or local mount. For s3 , please set cloudProvider to aws and use either serviceAccount or creds
  aggregate:
    enabled: false
    verbose: true
    keepOldBackup: false
    parallelRecovery: false
    # Only AWS S3 or local mount paths are supported
    # For S3 provide the complete path , Ex: s3://bucket1/bucket2
    fromPath: ""
    # database name to aggregate. Can contain * and ? for globbing.
    database: ""
    # Optional temporary directory for aggregation process
    # If not specified, will use the backup directory (/backups)
    # This is especially useful when working with cloud storage and large backup chains
    tempDir: ""

#Below are all neo4j-admin database check flags / options
#To know more about the flags read here : https://neo4j.com/docs/operations-manual/current/tools/neo4j-admin/consistency-checker/
consistencyCheck:
  enable: false
  checkIndexes: true
  checkGraph: true
  checkCounts: true
  checkPropertyOwners: true
  #The database name for which consistency check needs to be done.
  #Defaults to the backup.database values if left empty
  #The database name here should match with one of the database names present in backup.database. If not , the consistency check will be ignored
  #
  # When left empty: Consistency check will be performed for ALL backed up databases
  # When specified: Only the specified database(s) will be checked
  #
  # You can specify multiple databases using comma separation: "neo4j,system"
  database: ""
  maxOffHeapMemory: ""
  threads: ""
  verbose: true
  # Optional temporary directory for consistency check process when using cloud storage
  # If not specified, will use the backup directory with a "consistency-temp" subdirectory
  tempDir: ""
  # Timeout for consistency check operations
  # Must be a valid Go duration format (supports compound durations and decimals)
  # Examples: "30m", "1h", "90m", "2h", "2h30m", "1.5h", "4h"
  # Helm validation will fail immediately for invalid formats
  # Default: "30m" for cloud storage (aws/gcp/azure), no timeout for local storage
  # For large databases, increase this value (e.g., "2h", "4h", "6h")
  timeout: ""

# Set to name of an existing Service Account to use if desired
# Follow the following links for setting up a service account with workload identity
# Azure - https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview?tabs=go
# GCP - https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
# AWS - https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html
serviceAccountName: ""

# Volume to use for local backup storage and temporary files.
# Note: When using cloud providers (aws/gcp/azure), Neo4j native backup uploads directly to cloud storage
# For large databases with local backups, you may need persistent storage here
# The chart defaults to an emptyDir, use this to overwrite default behavior

#tempVolume:
#  persistentVolumeClaim:
#    claimName: backup-pvc

# securityContext defines privilege and access control settings for a Pod. Making sure that we don't run Neo4j as root user.
securityContext:
  runAsNonRoot: true
  runAsUser: 7474
  runAsGroup: 7474
  fsGroup: 7474
  fsGroupChangePolicy: "Always"

containerSecurityContext:
  runAsNonRoot: true
  runAsUser: 7474
  runAsGroup: 7474
  readOnlyRootFilesystem: false
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

# default ephemeral storage of backup container
resources:
  requests:
    ephemeralStorage: "4Gi"
    cpu: ""
    memory: ""
  limits:
    ephemeralStorage: "5Gi"
    cpu: ""
    memory: ""

# nodeSelector labels
# please ensure the respective labels are present on one of nodes or else helm charts will throw an error
nodeSelector: {}
#  label1: "true"
#  label2: "value1"

# set backup pod affinity
affinity: {}
#  podAffinity:
#    requiredDuringSchedulingIgnoredDuringExecution:
#      - labelSelector:
#          matchExpressions:
#            - key: security
#              operator: In
#              values:
#                - S1
#        topologyKey: topology.kubernetes.io/zone
#  podAntiAffinity:
#    preferredDuringSchedulingIgnoredDuringExecution:
#      - weight: 100
#        podAffinityTerm:
#          labelSelector:
#            matchExpressions:
#              - key: security
#                operator: In
#                values:
#                  - S2
#          topologyKey: topology.kubernetes.io/zone

# Additional environment variables for the backup container
# Follows the standard Kubernetes env var format
# Supports value, valueFrom.secretKeyRef, valueFrom.configMapKeyRef, etc.
extraEnvVars: []
#  - name: AWS_CA_BUNDLE
#    value: "/custom-ca/ca-bundle.crt"
#  - name: MY_SECRET_VAR
#    valueFrom:
#      secretKeyRef:
#        name: my-secret
#        key: secret-key

# Additional volumes to mount on the backup pod
extraVolumes: []
#  - name: custom-ca
#    secret:
#      secretName: my-ca-cert-secret

# Additional volume mounts for the backup container
extraVolumeMounts: []
#  - name: custom-ca
#    mountPath: /custom-ca
#    readOnly: true

#Add tolerations to the Neo4j pod
tolerations: []
#  - key: "key1"
#    operator: "Equal"
#    value: "value1"
#    effect: "NoSchedule"
#  - key: "key2"
#    operator: "Equal"
#    value: "value2"
#    effect: "NoSchedule"

Back up your database(s)

To back up your database(s), you install the neo4j-admin Helm chart using the configured backup-values.yaml file.

  1. Install neo4j-admin Helm chart using the backup-values.yaml file:

    helm install backup-name neo4j/neo4j-admin -f /path/to/your/backup-values.yaml

    The neo4j/neo4j-admin Helm chart installs a cronjob that launches a pod based on the job schedule. This pod performs a backup of one or multiple databases, a consistency check of the backup file(s), and uploads them to the cloud provider bucket.

  2. Monitor the backup pod logs using kubectl logs pod/<neo4j-backup-pod-name> to check the progress of the backup.

  3. Check that the backup files and the consistency check reports have been uploaded to the cloud provider bucket or on-premises storage.

Aggregate a database backup chain

The aggregate backup command turns a backup chain into a single backup file. This is useful when you have a backup chain that you want to restore to a different cluster, or when you want to archive a backup chain. For more information on the benefits of the aggregate backup chain operation, its syntax and available options, see Aggregate a database backup chain.

Starting from 5.26 LTS, the neo4j-admin Helm chart supports an optional temporary directory to be used by the aggregation process instead of the backup working directory. This is especially useful when the size of the backup chain is larger then the pods ephemeral storage. To avoid the backup aggregation job to fail due to lack of disk space, you can set the tempDir parameter to a persistent volume claim that has enough space to hold the backup files.

The neo4j-admin Helm chart supports aggregating a backup chain stored in an AWS S3 bucket or a local mount. If enabled, normal backup will not be done, only aggregate backup.

  1. To aggregate a backup chain stored in an AWS S3 bucket or a local mount, you need to provide the following information in your backup-values.yaml file:

    If your backup chain is stored on AWS S3, you need to set cloudProvider to aws and use either creds or serviceAccount to connect to your AWS S3 bucket. For example:

    Connect to your AWS S3 bucket using the awscreds secret
    neo4j:
      image: "neo4j/helm-charts-backup"
      imageTag: "2026.7.1"
      jobSchedule: "* * * * *"
      successfulJobsHistoryLimit: 3
      failedJobsHistoryLimit: 1
      backoffLimit: 3
    
    backup:
    
      cloudProvider: "aws"
      secretName: "awscreds"
      secretKeyName: "credentials"
    
      aggregate:
        enabled: true
        verbose: false
        keepOldBackup: false
        parallelRecovery: false
        fromPath: "s3://bucket1/bucket2"
        # Database name to aggregate. Can contain * and ? for globbing.
        database: "neo4j"
        # Optional temporary directory for aggregation process
        # If not specified, will use the backup directory
        tempDir: "/custom/temp/dir"
    
    resources:
      requests:
        ephemeralStorage: "4Gi"
      limits:
        ephemeralStorage: "5Gi"
    Connect to your AWS S3 bucket using serviceAccount
    neo4j:
      image: "neo4j/helm-charts-backup"
      imageTag: "2026.7.1"
      jobSchedule: "* * * * *"
      successfulJobsHistoryLimit: 3
      failedJobsHistoryLimit: 1
      backoffLimit: 3
    
    backup:
    
        cloudProvider: "aws"
    
        aggregate:
          enabled: true
          verbose: false
          keepOldBackup: false
          parallelRecovery: false
          fromPath: "s3://bucket1/bucket2"
          # Database name to aggregate. Can contain * and ? for globbing.
          database: "neo4j"
          # Optional temporary directory for aggregation process
          # If not specified, will use the backup directory
          tempDir: "/custom/temp/dir"
    
    #The service account must already exist in your cloud provider account and have the necessary permissions to manage your S3 bucket, as well as to download and upload files. See the example policy below.
    #{
    #   "Version": "2012-10-17",
    #    "Id": "Neo4jBackupAggregatePolicy",
    #    "Statement": [
    #        {
    #            "Sid": "Neo4jBackupAggregateStatement",
    #            "Effect": "Allow",
    #            "Action": [
    #                "s3:ListBucket",
    #                "s3:GetObject",
    #                "s3:PutObject",
    #                "s3:DeleteObject"
    #            ],
    #            "Resource": [
    #                "arn:aws:s3:::mybucket/*",
    #                "arn:aws:s3:::mybucket"
    #            ]
    #        }
    #    ]
    #}
    serviceAccountName: "my-service-account"
    
    resources:
      requests:
        ephemeralStorage: "4Gi"
      limits:
        ephemeralStorage: "5Gi"
    neo4j:
      image: "neo4j/helm-charts-backup"
      imageTag: "2026.7.1"
      successfulJobsHistoryLimit: 1
      failedJobsHistoryLimit: 1
      backoffLimit: 1
    
    backup:
    
      aggregate:
        enabled: true
        verbose: false
        keepOldBackup: false
        parallelRecovery: false
        fromPath: "/backups"
        # Database name to aggregate. Can contain * and ? for globbing.
        database: "neo4j"
        # Optional temporary directory for aggregation process
        # If not specified, will use the backup directory
        tempDir: "/custom/temp/dir"
    
    tempVolume:
      persistentVolumeClaim:
        claimName: aggregate-pv-pvc
    
    resources:
      requests:
        ephemeralStorage: "4Gi"
      limits:
        ephemeralStorage: "5Gi"
  2. Install the neo4j-admin Helm chart using the configured backup-values.yaml file:

    helm install backup-name neo4j/neo4j-admin -f /path/to/your/backup-values.yaml
  3. Monitor the pod logs using kubectl logs pod/<neo4j-aggregate-backup-pod-name> to check the progress of the aggregate backup operation.

  4. Verify that the aggregated backup file has replaced your backup chain in the cloud provider bucket or on-premises storage.

Restore a single database

To restore a single offline database or a database backup, you first need to delete the database that you want to replace unless you want to restore the backup as an additional database in your DBMS. Then, use the restore command of neo4j-admin to restore the database backup. Finally, use the Cypher command CREATE DATABASE name to create the restored database in the system database.

Delete the database that you want to replace

Before you restore the database backup, you have to delete the database that you want to replace with that backup using the Cypher command DROP DATABASE name against the system database. If you want to restore the backup as an additional database in your DBMS, then you can proceed to the next section.

For Neo4j cluster deployments, you run the Cypher command DROP DATABASE name only on one of the cluster servers. The command is automatically routed from there to the other cluster members.

  1. Connect to the Neo4j DBMS:

    kubectl exec -it <release-name>-0 -- bash
  2. Connect to the system database using cypher-shell:

    cypher-shell -u neo4j -p <password> -d system
  3. Drop the database you want to replace with the backup:

    DROP DATABASE neo4j;
  4. Exit the Cypher Shell command-line console by typing :exit;.

Restore the database backup

You use the neo4j-admin database restore command to restore the database backup, and then the Cypher command CREATE DATABASE name to create the restored database in the system database. For information about the command syntax, options, and usage, see Restore a database backup.

Neo4j Helm charts do not offer the option to restore directly from cloud storage. You need to download or copy down the backup files from cloud storage to a local directory or inside a pod and then restore the backup from there using the neo4j-admin database restore command.

For Neo4j cluster deployments, restore the database backup on each cluster server.

  1. Run the neo4j-admin database restore command to restore the database backup:

    neo4j-admin database restore neo4j --from-path=/backups/neo4j --expand-commands
  2. Connect to the system database using cypher-shell:

    cypher-shell -u neo4j -p <password> -d system
  3. Create the neo4j database.

    For Neo4j cluster deployments, you run the Cypher command CREATE DATABASE name only on one of the cluster servers.

    CREATE DATABASE neo4j;
  4. Open the browser at http://<external-ip>:7474/browser/ and check that all data has been successfully restored.

  5. Execute a Cypher command against the neo4j database, for example:

    MATCH (n) RETURN n

    If you have backed up your database with the option --include-metadata, you can manually restore the users and roles metadata. For more information, see Restore a database backup → Example.

To restore the system database, follow the steps described in Dump and load databases (offline).

Migrate from traditional to cloud-native backups

To migrate from persistent volume-based backups to cloud-native backups, you need to follow these steps:

  1. Perform a final traditional backup to ensure you have the latest data. For more information, see Prepare to back up a database(s) to on-premises storage and Back up your databases.

  2. Upload existing backups to the cloud storage bucket if needed. You can use cloud provider CLI tools to transfer your backup files:

    • For AWS S3: aws s3 cp /path/to/backups s3://your-bucket/backups --recursive

    • For Google Cloud Storage: gsutil cp -r /path/to/backups gs://your-bucket/backups

    • For Azure Blob Storage: az storage blob upload-batch --source /path/to/backups --destination your-container

  3. Update the backup-values.yaml file to configure the cloud provider, bucket name, and credentials. See Prepare to back up a database(s) to a cloud provider (AWS, GCP, and Azure) bucket for details.

  4. Install the neo4j-admin Helm chart with the updated backup-values.yaml file to back up your databases to the cloud provider bucket. See Back up your databases for details.