TempsTemps

Backups

This is the feature reference. For step-by-step setup instructions, see Set Up Backups & Monitoring. For recovery scenarios, see Restore & Recovery.

Protect your applications and data with automated backups. Configure backup schedules, store backups securely, and restore quickly when needed.

Loading diagram...

Quick Start

Enable Automatic Backups

  1. Go to Project Settings - Navigate to your project
  2. Open Backups Tab - Click on "Backups" in settings
  3. Create Backup Schedule - Set frequency and retention
  4. Done - Backups run automatically

Create Backup Now

# Trigger an immediate backup for a managed service
bunx @temps-sdk/cli backup run-service \
  --id <service-id> \
  --s3-source-id <s3-source-id> \
  --type full

You can also trigger a backup from the web UI: open the service detail page and click Run Backup Now.

What Gets Backed Up

Application Data

  • Container volumes - Persistent data in containers
  • File uploads - User-uploaded files
  • Application state - Runtime data
  • Configuration files - App-specific configs

Database Backups

If you're using managed databases:

  • PostgreSQL - Full database dumps
  • Redis - RDB snapshots
  • MySQL - Database exports
  • MongoDB - Database dumps

Configuration

  • Environment variables - Encrypted backup
  • Deployment settings - Resource limits, ports
  • Domain configurations - SSL certificates, routing
  • Team settings - Permissions, access

Backup Schedules

Create Schedule

# Daily full backup at 2 AM, kept for 30 days
bunx @temps-sdk/cli backup schedule create \
  --name "daily-full" \
  --schedule "0 2 * * *" \
  --type full \
  --retention 30 \
  --s3-source-id <s3-source-id>

# Weekly full backup on Sundays at 3 AM, kept for 90 days
bunx @temps-sdk/cli backup schedule create \
  --name "weekly-full" \
  --schedule "0 3 * * 0" \
  --type full \
  --retention 90 \
  --s3-source-id <s3-source-id>

# Every 6 hours incremental backup, kept for 7 days
bunx @temps-sdk/cli backup schedule create \
  --name "6h-incremental" \
  --schedule "0 */6 * * *" \
  --type incremental \
  --retention 7 \
  --s3-source-id <s3-source-id>

Schedule Options

Frequency:

  • Hourly - Every X hours
  • Daily - Once per day at specific time
  • Weekly - Once per week on specific day
  • Monthly - Once per month on specific date

Retention:

  • Keep backups for X days
  • Automatic cleanup of old backups
  • Configurable per schedule

Backup Storage

Storage Options

Local Storage (Default)

  • Stored on Temps server
  • Fast access
  • Included in Temps hosting

S3-Compatible Storage

  • AWS S3, MinIO, DigitalOcean Spaces
  • Off-site backup
  • Configurable regions

External Storage

  • Custom S3-compatible endpoints
  • Your own storage infrastructure

Configure Storage

# Add an S3-compatible backup source
bunx @temps-sdk/cli backup source create \
  --name "my-s3-backups" \
  --bucket my-backups \
  --region us-east-1 \
  --access-key YOUR_KEY \
  --secret-key YOUR_SECRET

# List configured sources
bunx @temps-sdk/cli backup source list --json

Restore from Backup

List Backups

# List backups for a specific schedule
bunx @temps-sdk/cli backup list --schedule-id <schedule-id> --json

# Show details for a specific backup
bunx @temps-sdk/cli backup show --id <backup-id> --json

# List all configured schedules
bunx @temps-sdk/cli backup schedule list --json

Restore Backup

# Restore a specific backup to a service
bunx @temps-sdk/cli services restore \
  --id <service-id> \
  --backup-id <backup-id>

You can also initiate a restore from the web UI: open the service detail page, go to the Backups tab, and click Restore next to any listed backup.

What Gets Restored

  • Application data - All volumes and files
  • Database data - If using managed databases
  • Configuration - Environment variables and settings

What Doesn't Get Restored

  • Deployment history - Previous deployments stay
  • Analytics data - Historical analytics preserved
  • Team members - User access unchanged

Backup Best Practices

Regular Backups

  • Daily for production - Critical applications
  • Weekly for staging - Less critical environments
  • Before major changes - Manual backup before migrations
  • After deployments - Backup after successful deployments

Test Restores

Regularly test your restore process:

# Restore a known-good backup to the staging service
bunx @temps-sdk/cli services restore \
  --id <staging-service-id> \
  --backup-id <backup-id>

# Verify data integrity
# Test application functionality

Backup Verification

  • Automatic verification - Backups verified after creation
  • Integrity checks - Checksums verified
  • Restore testing - Periodic restore tests
  • Alert on failure - Notified if backup fails

Disaster Recovery

Recovery Plan

  1. Identify the issue - What data was lost?
  2. Find the backup - Locate the right backup
  3. Restore backup - Restore to staging first
  4. Verify data - Check data integrity
  5. Restore to production - Restore when verified
  6. Monitor closely - Watch for issues

Recovery Time

  • Backup retrieval - Seconds to minutes
  • Data restoration - Minutes to hours (depends on size)
  • Application restart - Minutes
  • Total recovery - Usually under 1 hour

Backup Management

Manage Schedules

# Disable a schedule (pauses future runs without deleting past backups)
bunx @temps-sdk/cli backup schedule disable --id <schedule-id>

# Re-enable a previously disabled schedule
bunx @temps-sdk/cli backup schedule enable --id <schedule-id>

# Delete a schedule (stops future runs; past backups remain in S3)
bunx @temps-sdk/cli backup schedule delete --id <schedule-id>

Access Backup Files

Individual backup files are stored directly in your configured S3-compatible bucket. To download or export a backup, access it through your S3 provider's console, CLI (aws s3 cp, mc cp, etc.), or any S3-compatible client using the credentials from your backup source.

Next Steps

Was this page helpful?