Overview

We're excited to announce a powerful new feature in IBM API Connect Analytics that gives you unprecedented control over your backup and restore operations: backup mode selection in v12.1.0.0. This enhancement allows you to create targeted backups based on your specific deployment needs, significantly reducing backup times, storage costs, and restore complexity.

What is the backupMode Option?

The backupMode parameter is a new field available in the analytics backup Custom Resource (CR) that enables you to specify exactly which data components you want to include in your backup. Instead of always backing up everything, you can now choose to backup only the data relevant to your specific use case.

Available Backup Modes

The feature supports four distinct backup modes, each designed for specific deployment scenarios:

1. all (Complete Backup)

backupMode: all

This is the default mode that backs up all indices and data across your entire API Connect Analytics deployment. Use this when you need a comprehensive backup of your complete system.

What's included:

• All analytics data (API events, metrics, reports)

• Developer Portal data

• Federated API Management data

• Audit logs

• Configuration data

• All other indices

Best for:

• Full system disaster recovery

• Complete environment migrations

• Comprehensive compliance requirements

• Initial backups of new deployments

2. devportal (Developer Portal Only)

backupMode: devportal

Creates a focused backup containing only Developer Portal-related data.

What's included:

• api_tms_core-* indices (Portal content management)

• portal* indices (Portal configuration and data)

• apic-audit-* indices (Audit logs)

Best for:

• Developer Portal migrations

• Portal-specific disaster recovery

• Isolated portal environment backups

• Reducing backup size when analytics data isn't needed

Benefits:

• Significantly smaller backup size

• Faster backup and restore operations

• Reduced storage costs

• Simplified portal-only recovery scenarios

3. federatedapimanagement (Federated API Management)

backupMode: federatedapimanagement

Targets Federated API Management control plane data.

What's included:

• api_control_plane* indices (Control plane data)

• apic-audit-* indices (Audit logs)

Best for:

• Federated API Management deployments

• Control plane disaster recovery

• Multi-cluster management scenarios

• Backing up federation configuration and state

Benefits:

• Focused backups for federated deployments

• Faster recovery of control plane data

• Optimized for distributed API management architectures

• Reduced backup overhead for federation-specific data

4. analytics (Analytics Data Only)

backupMode: analytics

Captures all analytics-related data while excluding portal and federation components.

What's included:

• reports* indices (Analytics reports)

• service-config index (Service configuration)

• all-content-data* indices (Content data)

• all-content-count* indices (Content counts)

• engagement index (Engagement data)

• summary-api-* indices (API summaries)

• apic-* indices (API Connect analytics data)

Best for:

• Analytics-focused deployments

• Business intelligence and reporting backups

• Compliance and audit data retention

• Separating analytics from operational data

Benefits:

• Optimized for analytics workloads

• Includes all reporting and metrics data

• Excludes unnecessary portal/federation data

• Ideal for analytics-only restore scenarios

How to Use the backupMode Parameter

Prerequisites

Before creating backups with specific modes, you must enable database backup in your AnalyticsCluster CR:

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsCluster
metadata:
  name: analytics
spec:
  # ... other configuration ...
  databaseBackup:
    enabled: true
    # ... backup configuration ...

Creating a Backup with Specific Mode

The backupMode parameter is specified in the AnalyticsBackup Custom Resource. Create a YAML file (e.g., analyticsBackup_cr.yaml) with the following structure:

Example 1: Complete Backup (Default)

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-s3-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Full system backup for disaster recovery"
  backupMode: all

Example 2: Developer Portal Backup

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-portal-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Developer Portal backup for migration"
  backupMode: devportal

Example 3: Analytics Data Backup

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-analytics-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Daily analytics data backup"
  backupMode: analytics

Example 4: Federated API Management Backup

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-federated-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Federated API Management control plane backup"
  backupMode: federatedapimanagement

Applying the Backup CR

Once you've created your YAML file, apply it using kubectl:

# Create a backup with the specified mode
kubectl create -f analyticsBackup_cr.yaml

# Verify the backup was created
kubectl get analyticsbackup

# Check the backup status
kubectl describe analyticsbackup <backup-name>

Snapshot Naming Convention

Snapshots created with different backup modes follow a consistent naming pattern that includes the mode:

{cluster-name}-{backupMode}-{scope}-{timestamp}

Examples:

• analytics-devportal-default-2025-01-12t13:30:00.000z

• analytics-analytics-default-2025-01-12t14:45:00.000z

• analytics-federatedapimanagement-default-2025-01-12t15:00:00.000z

• analytics-all-default-2025-01-12t16:15:00.000z

This naming convention makes it easy to identify the backup mode at a glance and helps with backup management and retention policies.

Key Benefits

1. Reduced Backup Time

By backing up only the data you need, backup operations complete significantly faster. For example, a devportal backup might complete in minutes instead of hours for a full backup.

2. Lower Storage Costs

Selective backups consume less storage space. If you only need portal data, why pay to store terabytes of analytics events?

Example savings:

• Full backup: 500 GB

• Developer Portal backup: 50 GB (90% reduction)

• Analytics backup: 400 GB (20% reduction)

3. Faster Restore Operations

Restoring smaller, focused backups is much faster than restoring everything. This reduces your Recovery Time Objective (RTO) significantly.

4. Simplified Disaster Recovery

Different components can have different backup schedules and retention policies:

• Daily analytics backups with 7-day retention

• Weekly portal backups with 30-day retention

• Monthly full backups with 90-day retention

5. Improved Compliance

Separate backup modes allow you to implement different retention policies for different data types, helping meet various compliance requirements.

6. Flexible Migration Strategies

Migrate components independently:

• Move your Developer Portal to a new cluster without migrating analytics data

• Migrate analytics data separately from operational data

• Implement phased migration strategies

Best Practices

1. Choose the Right Mode for Your Use Case

• Use all for initial backups and full disaster recovery scenarios

• Use component-specific modes for regular operational backups

• Consider your recovery requirements when selecting a mode

2. Implement a Tiered Backup Strategy

Create different backup CRs for different frequencies:

Daily Analytics Backup:

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-daily-analytics-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Daily analytics backup"
  backupMode: analytics

Weekly Portal Backup:

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-weekly-portal-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Weekly portal backup"
  backupMode: devportal

Monthly Full Backup:

apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-monthly-full-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Monthly comprehensive backup"
  backupMode: all

3. Test Your Restore Procedures

Regularly test restoring from different backup modes to ensure your disaster recovery procedures work as expected.

4. Monitor Backup Sizes

Track the size of backups created with different modes to optimize your storage allocation and costs:

# List all backups
kubectl get analyticsbackup

# Get detailed information about a specific backup
kubectl describe analyticsbackup <backup-name>

5. Document Your Backup Strategy

Clearly document which backup modes you're using and why, so your team understands the recovery capabilities and limitations.

6. Consider Retention Policies

Different backup modes may warrant different retention periods:

• Analytics data: Shorter retention (7-30 days)

• Portal configuration: Longer retention (30-90 days)

• Full backups: Extended retention (90+ days)

Technical Implementation Details

Validation and Error Handling

The system automatically validates the backupMode parameter:

• Invalid modes default to all with a warning logged

• The system ensures backward compatibility (omitting the parameter defaults to all)

• Clear error messages guide users to correct usage

Index Selection Logic

Each backup mode maps to a specific set of index patterns:

// Developer Portal
"api_tms_core-*,portal*,apic-audit-*"

// Federated API Management
"api_control_plane*,apic-audit-*"

// Analytics
"reports*,service-config,all-content-data*,all-content-count*,engagement,summary-api-*,apic-*"

// All (default)
".*,*"

Restore Compatibility

Snapshots created with any backup mode can be restored using the standard restore procedures. The system automatically detects the backup mode from the snapshot name and restores the appropriate indices.

Migration from Previous Versions

If you're currently using the backup feature without the backupMode parameter:

1. No action required - Existing backups continue to work

2. Default behavior unchanged - Backups without the parameter still create full backups

3. Gradual adoption - Start using specific modes for new backups as needed

4. Backward compatible - All existing restore procedures continue to work

Real-World Use Cases

Use Case 1: Multi-Environment Strategy

Scenario: A company with separate development, staging, and production environments.

Strategy:

Development Environment:

# Daily portal backups for rapid iteration
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-dev-portal-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Dev portal daily backup"
  backupMode: devportal

Staging Environment:

# Daily analytics backups for testing
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-staging-analytics-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Staging analytics backup"
  backupMode: analytics

Production Environment:

# Weekly full backup + daily analytics
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-prod-full-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Production full backup"
  backupMode: all

Benefits: Optimized backup windows, reduced storage costs, faster environment-specific restores.

Use Case 2: Compliance-Driven Backups

Scenario: Financial services company with strict data retention requirements.

Strategy:

# Long-term analytics retention for compliance
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-compliance-analytics-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "7-year retention for regulatory compliance"
  backupMode: analytics

Benefits: Meet compliance requirements without over-retaining unnecessary data.

Use Case 3: Disaster Recovery Optimization

Scenario: Large enterprise with multiple data centers and strict RTO requirements.

Strategy:

# Primary site - comprehensive backup
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-primary-full-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Primary site full backup"
  backupMode: all
---
# DR site - frequent analytics backups
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-dr-analytics-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "DR site analytics backup (4-hour RPO)"
  backupMode: analytics

Benefits: Minimized data loss, faster recovery, optimized bandwidth usage.

Monitoring and Troubleshooting

Verifying Backup Mode

Check the backup CR and snapshot name to verify the backup mode used:

# List all backups
kubectl get analyticsbackup

# Get detailed information
kubectl describe analyticsbackup <backup-name>

# Check the snapshot name (includes backup mode)
kubectl get analyticsbackup <backup-name> -o jsonpath='{.status.snapshotName}'

Look for the mode in the snapshot name:

analytics-devportal-default-2025-01-12t13:30:00.000z
         ^^^^^^^^^
         backup mode

Checking Backup Status

# Watch backup progress
kubectl get analyticsbackup -w

# View backup logs
kubectl logs -l app=analytics-backup-controller

# Check for errors
kubectl describe analyticsbackup <backup-name> | grep -A 10 "Status:"

Common Issues and Solutions

Issue: Backup taking longer than expected Solution: Consider using a more specific backup mode instead of all

Issue: Restore missing expected data Solution: Verify the backup mode used matches your restore requirements

Issue: Storage costs higher than expected Solution: Review backup modes and implement a tiered strategy

Issue: Backup CR not creating snapshot Solution: Verify databaseBackup.enabled: true in AnalyticsCluster CR

Performance Metrics

Based on typical deployments, here are approximate performance improvements:

Note: Actual metrics vary based on your specific data volumes and usage patterns.

Future Enhancements

We're continuously improving the backup and restore capabilities. Planned enhancements include:

• Custom backup mode definitions

• Automated backup mode selection based on usage patterns

• Enhanced backup mode validation and recommendations

• Integration with backup scheduling and retention policies

• Backup mode-specific compression strategies

Conclusion

The backupMode parameter in the backup CR represents a significant advancement in IBM API Connect Analytics data management. By providing granular control over what gets backed up, you can:

• Reduce costs through optimized storage usage

• Improve performance with faster backup and restore operations

• Enhance flexibility with component-specific backup strategies

• Simplify operations with targeted disaster recovery procedures

• Meet compliance requirements more effectively

We encourage you to evaluate your current backup strategy and consider how selective backup modes can benefit your organization. Start with a pilot implementation, measure the results, and gradually expand your use of this powerful feature.

Getting Started

Ready to implement selective backup modes? Here's your action plan:

1. Enable database backup in your AnalyticsCluster CR

2. Assess your current backup strategy - Identify opportunities for optimization

3. Choose appropriate backup modes - Match modes to your recovery requirements

4. Create backup CRs - Use the examples provided as templates

5. Test in non-production - Validate backup and restore procedures

6. Implement gradually - Start with one mode and expand

7. Monitor and optimize - Track metrics and adjust as needed

Quick Start Example

# 1. Ensure database backup is enabled in AnalyticsCluster CR
kubectl edit analyticscluster analytics
# Add: spec.databaseBackup.enabled: true

# 2. Create a backup CR file
cat > analyticsBackup_cr.yaml <<EOF
apiVersion: analytics.apiconnect.ibm.com/v1beta1
kind: AnalyticsBackup
metadata:
  generateName: a7b-test-
spec:
  analyticsCluster: analytics
  crType: create
  comment: "Test backup with analytics mode"
  backupMode: analytics
EOF

# 3. Apply the backup CR
kubectl create -f analyticsBackup_cr.yaml

# 4. Monitor the backup
kubectl get analyticsbackup -w

For more information, consult the IBM API Connect Analytics documentation or contact your IBM support representative.

Version: v12.1.0.0