AWS Backup en disaster recovery op STACKIT: de checklist

resource "aws_backup_vault" "main" {
  name = "company-vault"
}

resource "aws_backup_plan" "daily" {
  name = "daily-35d"

  rule {
    rule_name         = "daily"
    target_vault_name = aws_backup_vault.main.name
    schedule          = "cron(0 3 * * ? *)"

    lifecycle {
      delete_after = 35
    }
  }
}

resource "aws_backup_selection" "tagged" {
  name         = "tagged-resources"
  plan_id      = aws_backup_plan.daily.id
  iam_role_arn = "arn:aws:iam::111122223333:role/backup-role"

  selection_tag {
    type  = "STRINGEQUALS"
    key   = "backup"
    value = "daily"
  }
}

# no volume automation is drafted for the selection tagged-resources of aws_backup_plan.daily: it reaches no volume in the scan.
# NOT CARRIED (aws_backup_plan.daily): rule.target_vault_name — STACKIT Server Backup keeps backups per server and has no vault: the vault a rule writes to, aws_backup_vault.main (company-vault), is not carried.
resource "stackit_server_backup_enable" "daily" {
  project_id = var.project_id
  server_id  = var.daily_server_id
}

resource "stackit_server_backup_schedule" "daily" {
  project_id = var.project_id
  server_id  = var.daily_server_id
  name       = "daily-35d-daily"
  rrule      = "DTSTART;TZID=UTC:20200101T030000 RRULE:FREQ=DAILY;INTERVAL=1"
  enabled    = true
  backup_properties = {
    name             = "daily-35d-daily"
    retention_period = 35
  }
  depends_on = [stackit_server_backup_enable.daily]
}

resource "aws_dlm_lifecycle_policy" "ebs" {
  description        = "Daily EBS snapshots"
  execution_role_arn = "arn:aws:iam::111122223333:role/dlm-role"
  state              = "ENABLED"

  policy_details {
    resource_types = ["VOLUME"]
    target_tags = {
      snapshot = "true"
    }
    schedule {
      name = "daily"
      create_rule {
        interval      = 24
        interval_unit = "HOURS"
        times         = ["03:00"]
      }
      retain_rule {
        count = 7
      }
    }
  }
}

# Check the count: the policy keeps 7 snapshots for schedule daily; the documented limit is 6 snapshots per volume (docs.stackit.cloud, introduction to the server), so the days beyond are not covered by snapshots — backups (daily retention, default 14 days, `backupRetentionPolicies`) are the longer-retention path; whether the Automation Service enforces the number is not documented, verify it on the first run.
resource "stackit_volume_automation" "ebs" {
  project_id  = var.project_id
  template_id = var.ebs_automation_template_id
  name        = "daily-ebs-snapshots-daily"
  description = "Daily EBS snapshots"
  input = jsonencode({
    kind                = "VolumeRecoveryPointManagement"
    inheritVolumeLabels = false
    snapshotRetentionPolicy = {
      kind  = "count"
      value = 7
    }
    volumeLabelSelector = "snapshot=true"
  })
  triggers = {
    schedule = {
      rrule = "DTSTART;TZID=UTC:20200101T030000 RRULE:FREQ=DAILY;INTERVAL=1"
    }
  }
}

resource "aws_db_instance" "orders" {
  identifier              = "orders-db"
  engine                  = "postgres"
  engine_version          = "16.4"
  instance_class          = "db.m6g.large"
  allocated_storage       = 100
  username                = "app"
  password                = var.db_password
  backup_retention_period = 14
  backup_window           = "02:00-02:30"
  multi_az                = true
  skip_final_snapshot     = false
  final_snapshot_identifier = "orders-db-final"
  tags = {
    backup = "daily"
  }
}

# recovery window: the source restores to any point within 14 days, as late as about five minutes before now (RDS uploads transaction logs to S3 every five minutes).
# PostgreSQL Flex restores to an arbitrary point of its available backups (transaction logs are on by default) into a cloned instance, and keeps them retention_days = 32.
# LEDGER backup retention: 14 days → retention_days = 32 — TRANSFORMED
# LEDGER high availability: standby / multi-node → flavor_id = "2.16-replica" (a replica flavor: three nodes that mirror each other; no STACKIT page states the zone of each node or how a failover works, so a zone failure or an automatic takeover is not claimed) — TRANSFORMED
resource "stackit_postgresflex_instance" "orders" {
  project_id = var.project_id
  name       = "orders-db"
  version    = "16"
  flavor_id  = "2.16-replica"
  storage = {
    class = var.postgresflex_storage_class
    size  = 108
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl          = var.orders_allowed_cidrs
    access_scope = var.orders_access_scope == "SNA" ? "SNA" : null
  }
  retention_days = 32
}

resource "aws_s3_bucket_versioning" "documents" {
  bucket = aws_s3_bucket.documents.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket" "documents_replica" {
  bucket = "acme-documents-replica"
}

resource "aws_s3_bucket_replication_configuration" "documents" {
  bucket = aws_s3_bucket.documents.id
  role   = "arn:aws:iam::111122223333:role/s3-replication"

  rule {
    id     = "all"
    status = "Enabled"
    destination {
      bucket = aws_s3_bucket.documents_replica.arn
    }
  }
}

# NOT CARRIED (aws_s3_bucket_replication_configuration.documents): role = arn:aws:iam::111122223333:role/s3-replication, rule — stackit_objectstorage_bucket has no replication attribute (pinned provider). STACKIT's supported-operations page lists Put, Get and Delete Bucket Replication, but no STACKIT page describes replication targets, cross-region behaviour or the role the source assumes, so whether replication between STACKIT buckets works is UNKNOWN (not observed); the source's destination, role, storage class and filter do not carry over.
#   Decision: probe `put-bucket-replication` between two STACKIT buckets before relying on it, or replace it with a scheduled sync (rclone) or application writes to both buckets.
# NOT CARRIED (aws_s3_bucket_versioning.documents): versioning_configuration.status = Enabled — stackit_objectstorage_bucket has no versioning attribute (pinned provider), but STACKIT Object Storage supports versioning through its S3 API (the provider lacks it, STACKIT does not). … Once enabled, versioning cannot be disabled on STACKIT, only suspended (docs manage-bucket-versioning). (shortened: the whole reason is in the trace of this block)
# LEDGER geo-replication: second region → none — sync to a second bucket if required — UNSUPPORTED
resource "stackit_objectstorage_bucket" "documents" {
  project_id = var.project_id
  name       = "acme-documents-primary"
}