Skip to content

Backup & Restore

RAMP includes a dedicated CLI tool (RAMP.Cli) for backup and disaster recovery. The CLI supports full and partial backups in multiple formats, validation before restore, and two restore modes (overwrite and copy). It operates directly against the RAMP database and produces self-contained backup files.


The RAMP CLI (ramp-cli) provides four commands:

CommandDescription
listDisplay the entity hierarchy (systems, stages, templates, versions, instances)
backupCreate a full or partial backup
validateValidate a backup file before restoring
restoreRestore data from a backup file

The CLI is built as part of the RAMP solution (src/RAMP.Cli). It connects to the same database as the RAMP API using the connection string from appsettings.json.

Terminal window
# Build the CLI
cd src/RAMP.Cli
dotnet build
# Run the CLI
dotnet run -- <command> [options]
# View help
dotnet run -- --help

RAMP data follows a hierarchical structure. Understanding this hierarchy is important for partial backups and restores.

System
└── Stage
└── (Instances are linked to Stages)
Template
└── Template Version
└── Steps, Variables
└── Instance
└── Instance Steps, Instance Variables, Attachments

When backing up or restoring a specific entity, RAMP automatically includes all child entities in the hierarchy. For example, backing up a System includes its Stages, and backing up a Template includes all its Versions.

Use the list command to explore the entity hierarchy before creating backups:

Terminal window
# List entire hierarchy
ramp-cli list
# List from a specific entity
ramp-cli list --type system --id <system-guid>
# Expand all nodes
ramp-cli list --expand

The output displays a tree view with color-coded entity types and child counts.


RAMP supports three backup formats:

FormatExtensionDescriptionBest For
JSON.jsonHuman-readable JSON file with all data inlineSmall backups, inspection, programmatic processing
ZIP.zipCompressed archive with JSON data and attachment files stored separatelyBackups with large attachments
SQLite.sqlitePortable SQLite database fileLarge backups, offline querying

A full backup captures all data in the RAMP database: systems, stages, templates, versions, instances, steps, variables, attachments, and user/group/category references.

Terminal window
ramp-cli backup full --output <path> [--format <format>]
OptionAliasRequiredDefaultDescription
--output-oYesOutput file path
--format-fNoJsonBackup format: Json, Zip, or Sqlite

Example:

Terminal window
# Full backup in JSON format
ramp-cli backup full --output /backups/ramp-full-2026-03-09.json
# Full backup in ZIP format (recommended for large databases)
ramp-cli backup full --output /backups/ramp-full-2026-03-09.zip --format Zip

After completion, the CLI displays a summary table showing entity counts:

Entity Type Count
──────────────────────
Systems 3
Stages 12
Templates 45
Versions 89
Instances 234
User References 156
Category Refs 18

A partial backup captures a specific entity and all its children in the hierarchy.

Terminal window
ramp-cli backup object --type <entity-type> --id <guid> --output <path> [--format <format>]
OptionAliasRequiredDefaultDescription
--type-tYesEntity type: system, stage, template, version, instance
--id-iYesEntity GUID
--output-oYesOutput file path
--format-fNoJsonBackup format: Json, Zip, or Sqlite

Examples:

Terminal window
# Backup a single instance
ramp-cli backup object --type instance --id a1b2c3d4-... --output instance-backup.json
# Backup a system and all its stages
ramp-cli backup object --type system --id e5f6a7b8-... --output system-backup.zip --format Zip
# Backup a template with all versions and instances
ramp-cli backup object --type template --id c9d0e1f2-... --output template-backup.json
Starting EntityIncludes
SystemThe system + all its stages
StageThe stage + reference to its parent system
TemplateThe template + all versions + steps + variables
VersionThe version + all steps + variables + reference to parent template
InstanceThe instance + all instance steps + instance variables + attachments + references to parent version and stage

Each backup also includes reference data — minimal information (IDs and names) for users, groups, and categories that are referenced by the backed-up entities. This enables the restore process to create placeholder records when the original users or groups do not exist in the target system.


Every backup file contains a manifest with metadata about the backup:

FieldDescription
VersionBackup format version (currently “1.0”)
Created AtTimestamp when the backup was created
Created ByUser or system that initiated the backup
TypeFull or Partial
FormatJson, Zip, or Sqlite
Root Object TypeFor partial backups: the entity type that was backed up
Root Object IDFor partial backups: the GUID of the entity that was backed up
ContentsSummary of all entities included in the backup

Before restoring, you can validate a backup file to check for potential issues.

Terminal window
ramp-cli validate --input <path> [--mode <mode>]
OptionAliasRequiredDefaultDescription
--input-iYesPath to the backup file
--mode-mNoCopyRestore mode to validate for: Overwrite or Copy

The validate command performs the following checks:

  • File integrity: Backup file can be read and parsed correctly
  • Schema validation: All required fields are present and correctly typed
  • Reference integrity: Referenced entities (users, systems, templates) exist in the target database (for Overwrite mode)
  • ID conflicts: For Overwrite mode, checks whether existing entities would be overwritten
Backup Information
┌──────────────┬─────────────────────────────┐
│ Property │ Value │
├──────────────┼─────────────────────────────┤
│ Backup Type │ Partial │
│ Created At │ 2026-03-09 14:30:00 │
│ Created By │ admin │
│ Format │ Json │
│ Root Object │ Template │
└──────────────┴─────────────────────────────┘
Validation passed!

If validation fails, the output lists specific errors and warnings, with a suggestion to try the alternative restore mode.


The restore command imports data from a backup file into the RAMP database.

Terminal window
ramp-cli restore --input <path> [--mode <mode>] [--dry-run] [--dummy-prefix <prefix>]
OptionAliasRequiredDefaultDescription
--input-iYesPath to the backup file
--mode-mNoCopyRestore mode: Overwrite or Copy
--dry-runNofalseValidate only, make no changes
--dummy-prefixNo[RESTORED]Prefix for dummy parent entity names

RAMP provides two restore modes that determine how entity IDs are handled during import.

Behavior: All entities receive new GUIDs. Original IDs are discarded and remapped.

Advantages:

  • Always works, regardless of what exists in the target database
  • No risk of overwriting existing data
  • Creates dummy parent entities if the original parents are not present

Use cases:

  • Cloning data to a different environment
  • Restoring data alongside existing records
  • Migrating data between separate RAMP installations

Dummy parents: When restoring a partial backup (e.g., an instance) and the parent entity (e.g., template version, stage) does not exist in the target database, RAMP creates a placeholder parent with the name prefix [RESTORED]. These dummy parents ensure referential integrity.

Terminal window
ramp-cli restore --input backup.json --mode Copy
# Custom prefix for dummy parents
ramp-cli restore --input backup.json --mode Copy --dummy-prefix "[IMPORTED]"

Use --dry-run to validate the restore without making any changes:

Terminal window
ramp-cli restore --input backup.json --mode Overwrite --dry-run

The dry run performs all validation checks and reports what would be restored, including entity counts and any warnings, without modifying the database.


After a successful restore, the CLI displays statistics:

Restore completed!
Entity Type Count
───────────────────────────
Systems 1
Stages 4
Templates 3
Versions 6
Instances 12
Steps 148
Variables 36
Dummy Parents Created 2
ID mappings created: 210
Old IDs -> New IDs have been remapped

The restore process may generate warnings for non-critical issues:

  • Missing user references: Users referenced in the backup do not exist in the target database
  • Missing category references: Categories referenced in the backup do not exist
  • Dummy parents created: Placeholder entities were created for missing parent references

If the restore fails, the CLI displays specific error messages:

  • Missing required references: In Overwrite mode, a required parent entity does not exist
  • Schema mismatch: The backup format version is incompatible with the current RAMP version
  • Data integrity violations: Foreign key constraints would be violated

For comprehensive disaster recovery, back up data at the System level. This captures the entire hierarchy:

System Backup
├── System metadata
├── All Stages
├── All Templates (linked to this system)
│ ├── All Versions
│ │ ├── Steps
│ │ └── Variables
│ └── All Instances
│ ├── Instance Steps
│ ├── Instance Variables
│ └── Attachments
└── User and Category references
Backup TypeFrequencyRetentionFormat
Full backupWeekly4 weeksZIP
System-level backupDaily2 weeksZIP
Instance backup (after completion)Per instancePermanentJSON

Periodically restore backups to a test environment to verify they are complete and functional. Use --dry-run first, then perform a full restore to a non-production database.

When backing up instances with evidence files, use ZIP format. Attachments are stored as separate files in the archive rather than Base64-encoded inline, which is more efficient and allows direct file access without parsing.

Maintain a record of:

  • Backup schedule and retention policy
  • Storage locations for backup files
  • Restore procedures and contact information
  • Last successful restore test date

Always run validate before restore in production:

Terminal window
# Step 1: Validate
ramp-cli validate --input backup.json --mode Copy
# Step 2: Dry run
ramp-cli restore --input backup.json --mode Copy --dry-run
# Step 3: Actual restore (only after validation passes)
ramp-cli restore --input backup.json --mode Copy

Backup files contain the complete state of your RAMP data, including step instructions, variable values, user references, and execution history. Store them in a secure location with appropriate access controls and encryption.