Backup Creator

Input Parameters

| Name | Type | Required | Description | |------|------|----------|-------------| | rundir | string | Yes | Working directory absolute path for input/output files | | decisionid | string | Yes | Phase 5 confirmation decision ID (e.g., confirm-20260605-001) | | phase5decisionfile | string | Yes | Path to Phase 5 decision file (confirm/phase5decision.json from zombie-decision-handler), containing resources array with resourceid, entitytype, environment, cloudprovider, resourcemetadata | | sshkeypath | string | No | SSH key path for cloud API calls and remote execution | | taskid | string | Yes | Task ID for progress tracking in backupepisodes.json | | maxconcurrentbackups | integer | No | Maximum concurrent backup operations (avoid cloud API throttling) | | backupretentiondaysoverride | integer | No | Override default retention days (prod:30, staging:14, dev:7) |

Execution Flow

Task Context

Before starting execution, initialize task_context.json:

{
  "task_id": "",
  "current_step": 0,
  "current_step_id": null,
  "status": "running",
  "steps": {
    "validate_input": "pending",
    "pre_backup_validation": "pending",
    "select_backup_strategy": "pending",
    "backup_creation_batch": "pending",
    "backup_verification": "pending",
    "backup_protection": "pending",
    "generate_reports": "pending",
    "handle_escalations": "pending",
    "finalize": "pending"
  },
  "updated_at": ""
}

Update this file after each step completes. On error, set step status to "failed" and overall status to "failed".

Step 1: validate_input

Type: inline Description: Validate input parameters and read resource list

Execution

Follow these instructions:

Your task is to validate input parameters and read the list of resources to be backed up.

Steps:

1. Verify that the run_dir directory exists and is writable
2. Verify that {rundir}/{phase5decision_file} file exists
3. Read phase5decisionfile, extract the resources array (written by decision-handler's write-phase5-decision step), verify each element contains:

• resource_id (required)
• resourcetype (required): CloudVM/CloudRDS/CloudCache/K8sWorkload/... (resourcetype defined in isolation plan)
• entity_type (required): VM/Database/Cache/K8s/ElasticIP/LoadBalancer/... (cloud provider entity type)
• environment (required): dev/staging/prod
• cloud_provider (required): aws/aliyun/k8s
• resource_metadata (required): JSON object with provider-specific fields

1. Read decisionid from phase5decision_file (auto-uses the ID assigned by decision-handler)
2. Count resources, group by entity_type
3. Write to {rundir}/delete/backupvalidation_start.json
4. If validation fails, return error status; if passed, continue

Write the output to the specified output file.

Output

• Schema: schemas/backupvalidationstart.schema.json
• File: delete/backupvalidationstart.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "validate_input"
• Set steps.validate_input to "completed"

Step 2: prebackupvalidation

Type: agent Description: Phase 1: Validate each resource before backup attempt (existence, isolation state, API accessibility, storage quota)

Input Files

• delete/backup_validation_start.json (from Step validateinput, schema: schemas/backupvalidation_start.schema.json)

Execution

Launch an independent agent with the following prompt file:

Prompt file: $PLUGINS/ico/skills/backup-creator/prompts/01_pre_backup_validation.md Agent workflow:

1. Read input data from:

• Schema: schemas/backup_validation_start.schema.json

1. Execute the agent with the prompt

1. Write results to:

• File: delete/pre_backup_validation.json

Output

• Schema: schemas/prebackupvalidation.schema.json
• File: delete/prebackupvalidation.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "pre_backup_validation"
• Set steps.pre_backup_validation to "completed"

Step 3: selectbackupstrategy

Type: agent Description: Phase 2: Select backup method per resource type and environment

Input Files

• delete/pre_backup_validation.json (from Step prebackupvalidation, schema: schemas/prebackupvalidation.schema.json)

Execution

Launch an independent agent with the following prompt file:

Prompt file: $PLUGINS/ico/skills/backup-creator/prompts/02_backup_strategy_selection.md Agent workflow:

1. Read input data from:

• Schema: schemas/pre_backup_validation.schema.json

1. Execute the agent with the prompt

1. Write results to:

• File: delete/backup_strategies.json

Output

• Schema: schemas/backup_strategies.schema.json
• File: delete/backup_strategies.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "select_backup_strategy"
• Set steps.select_backup_strategy to "completed"

Step 4: backupcreationbatch

Type: inline Description: Phase 3: Create backups with retry logic (maxconcurrentbackups parallel, 3 retries each)

Input Files

• delete/backup_strategies.json (from Step selectbackupstrategy, schema: schemas/backup_strategies.schema.json)

Execution

Follow these instructions:

Your task is to execute backup creation with retry logic and concurrency control.

Architecture:

• Maintain a work queue, max {maxconcurrentbackups} concurrent backup tasks
• Each backup retries up to 3 times with exponential backoff (5s, 10s, 20s)
• Successful backups record backup_id; failed backups record error and push to retry queue or escalate to manual

For each resource:

1. Attempt 1

• Call the backup creation function for the corresponding resource type:
• CloudVM: createami() + createsnapshotsfordata_volumes()
• RDS: createfinalsnapshot()
• Redis: executebgsave() + exportrdbtos3()
• K8s: exportyamlmanifest() + uploadtos3()
• ... (refer to phase-6-delete.md section 4.2-4.10)
• Record start time, backup ID (if returned immediately), call parameters
• Wait for backup completion (poll status, timeout = resource-type dependent)

1. Failure handling (first attempt or retry)

• Catch exceptions, classify as:
• Retriable: Service unavailable, Timeout, Rate limit, Transient error
• Non-retriable: Invalid credential, Resource not found, Quota exceeded (hard limit)
• Retriable error -> wait backoff time, add to retry queue
• Non-retriable error -> immediately record as failed, prepare escalation

1. Attempts 2 and 3

• Repeat step 1, record attempt number
• If 3rd attempt still fails -> record as "escalation_required"

1. Success indicators

• Backup ID returned, backup status is available/completed
• Backup size > 0 (for RDB, YAML files, etc.)

1. Concurrency control:

• Maintain active backup task count state must be "available"
• RDS snapshot: describedbsnapshots(DBSnapshotIdentifier=...) -> state must be "available"
• Redis RDB: Check S3 object exists, size > 0
• K8s YAML: Check S3 object exists, size > 0

1. Readability check

• Can read backup metadata (IAM permissions correct)
• For Redis RDB, verify JSON config snapshot format is valid
• For K8s YAML, run kubectl apply --dry-run=client to verify syntax

1. Completeness check (resource-type dependent)

• CloudVM: All data disk snapshots are complete
• RDS: Snapshot size > 0, includes database parameters
• K8s: YAML includes all related ConfigMap/Secret/Service

1. Recovery hints generation

• Based on resource type and backup method, generate recovery steps with method, instructions, estimatedtimeminutes, and pre_requisites

1. Failure handling

• If verification fails, mark as "backupverificationfailed"
• Trigger manual escalation: cannot confirm backup is recoverable, needs manual confirmation

1. Write verification results {rundir}/delete/backupverification.json with per-resource checks, recovery hints, and status.

Write the output to the specified output file.

Output

• Schema: schemas/backup_verification.schema.json
• File: delete/backup_verification.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "backup_verification"
• Set steps.backup_verification to "completed"

Step 6: backup_protection

Type: inline Description: Phase 5: Apply protection tags and lifecycle rules to backups

Input Files

• delete/backup_verification.json (from Step backupverification, schema: schemas/backupverification.schema.json)

Execution

Follow these instructions:

Your task is to apply protection measures to all successfully verified backups.

For each successfully verified backup:

1. Apply tags (all resource types)

• CloudVM AMI and Snapshots:
• Tag: zombie-backup=true
• Tag: decision_id={decision_id}
• Tag: resource_id={resource_id}
• Tag: backup_date={date}
• Tag: retention_days={retention_days}
• RDS Snapshot: Same as above (if tag supported)
• S3/OSS objects:
• Metadata: zombie-backup=true, decision_id=...
• S3 Tag: Same as above

1. Set lifecycle rules (S3/OSS)

• For objects with prefix backup-*:
• Expiration Rule: Days={retention_days}, Filter: Tag zombie-backup=true, Action: Delete object + delete all versions

1. Enable encryption (handled by resource type category)

• K8s Secret backup (mandatory encryption):
• Must use KMS to encrypt Secret data
• Check: if resourcetype == "k8ssecret" or entity_type == "K8sSecret"
• Must provide KMS key ARN or Key ID
• Use KMS to encrypt exported YAML files (unencrypted export not allowed)
• Verify encryption flag is recorded in S3/OSS object metadata as kms_encrypted=true
• If KMS key is missing, mark as FAILED, refuse to save unencrypted Secret
• Encryption algorithm: AES-256-GCM or AES-256-CBC (via KMS)
• Other resource backups (recommended encryption):
• CloudVM: Enable SSE-S3 or SSE-KMS (optional)
• RDS: Confirm snapshot is encrypted (if original instance encrypted)
• S3/OSS: Enable default encryption policy (optional)
• K8s ConfigMap/PVC: If containing sensitive data, recommend enabling KMS (optional)

1. Access control

• K8s Secret backup (mandatory access restriction):
• Only allow recovery scripts and auditors to read
• S3: Set BucketPolicy to Deny all GetObject except for recovery scripts
• OSS: Set Bucket ACL to Deny public access
• Other resource backups (optional):
• Restrict backup access permissions (only recovery scripts can read)
• Prevent accidental deletion (IAM deny DeleteObject)

1. Write protection results {rundir}/delete/backupprotection.json with per-resource actions, status, and K8s secret protection details.

Write the output to the specified output file.

Output

• Schema: schemas/backup_protection.schema.json
• File: delete/backup_protection.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "backup_protection"
• Set steps.backup_protection to "completed"

Step 7: generate_reports

Type: inline Description: Phase 6: Generate per-resource backup reports and aggregate summary

Input Files

• delete/backup_creation_progress.json (from Step backupcreationbatch, schema: schemas/backupcreationprogress.schema.json)
• delete/backup_protection.json (from Step backupprotection, schema: schemas/backupprotection.schema.json)

Execution

Follow these instructions:

Your task is to generate detailed backup reports and a summary.

Generate per-resource reports {rundir}/delete/backupreport{resourceid}.json for each resource, combining data from all prior phases: prebackupvalidation, backupstrategy, backuprecord (status, backupid, type, size, duration, attempts, verification, protection), failurerecord (if failed after retries), and audit_log.

Generate summary report {rundir}/delete/backupsummary.json with:

• statistics: total, successful, failed, escalations, success_rate
• byresourcetype and by_environment breakdowns
• backupstoragecosts: total size, daily cost, retention, total cost
• escalations list with resourceid, reason, actionrequired
• nextsteps: readyfor_deletion flag, escalated resources requiring manual action, recommendation

Write the output to the specified output file.

Output

• Schema: schemas/backupreportoutput.json
• File: delete/backupreport{resource_id}.json
• Schema: schemas/backup_summary.schema.json
• File: delete/backup_summary.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "generate_reports"
• Set steps.generate_reports to "completed"

Step 8: handle_escalations

Type: inline Description: Phase 7: Process escalations and send notifications

Input Files

• delete/backup_summary.json (from Step generatereports, schema: schemas/backupsummary.schema.json)

Execution

Follow these instructions:

Your task is to process all escalations and notify relevant personnel.

For each escalated resource:

1. Generate escalation payload {rundir}/delete/escalations.json with escalationid, resourceid, resourcetype, decisionid, reason, error, recommendedaction, escalatedat, escalatedto, required_response, and notification tracking.

1. Send notification to the Phase 5 decision maker:

• Escalation type: ZOMBIEBACKUPFAILED
• Recipient: Phase 5 decision maker (from decision_id record)
• Content: escalated resource list, failure reasons, recommended actions

1. Update progress {rundir}/delete/backupepisodes.json:

• Mark escalation status
• Record notification send time

1. Output results with escalation_processing summary (total, notifications sent, timestamp, status).

Write the output to the specified output file.

Output

• Schema: schemas/escalations.schema.json
• File: delete/escalations.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "handle_escalations"
• Set steps.handle_escalations to "completed"

Step 9: finalize

Type: inline Description: Phase 8: Finalize and update task context

Input Files

• delete/backup_summary.json (from Step generatereports, schema: schemas/backupsummary.schema.json)
• delete/escalations.json (from Step handle_escalations, schema: schemas/escalations.schema.json)

Execution

Follow these instructions:

Your task is to finalize the backup process and update task status.

Steps:

1. Aggregate all reports

• Read {rundir}/delete/backupreport_*.json
• Count successful/failed/escalated

1. Update progress file {rundir}/delete/backupepisodes.json with taskid, phase=phase6backup, status, completedat, statistics, and result summary.

1. Generate final report {rundir}/delete/backupfinalreport.json with phase6backupresult: status, total, successful, escalations, outputfiles, nextphase, proceedwithdeletion flag, and decision_id.

1. Return status indicating success/partial_success/failed with counts, output file manifest, and whether deletion can proceed.

Write the output to the specified output file.

Output

• Schema: schemas/backup_episodes.schema.json
• File: delete/backup_episodes.json
• Schema: schemas/backupfinalreport.schema.json
• File: delete/backupfinalreport.json

Progress Tracking

After completing this step, update task_context.json:

• Set current_step_id to "finalize"
• Set `steps.fina

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: KnoxOps
• Source: KnoxOps/open-devops-skills
• License: Apache-2.0
• Homepage: https://knoxops.app?invite_token=GITHUB26

Install and usage instructions live in the source repository linked above.