Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 08 · LESSON 8.5

Protect data and verify recovery

Protect persisted credentials and verify recovery across all stores.

Lesson 47 of 86 · FabrCore 2.0

Overview

Persistence introduces operational responsibilities: schema management, protected key material, backups and retention. A restored database without the matching protection keys can leave connection grants unreadable. Evidence, monitoring and application records have different retention needs.

Encrypted records depend on their key material

A backup may contain encrypted connection grants without the keys needed to decrypt them. Restoring that database onto a new Host therefore requires the corresponding data-protection/key configuration as well as schema compatibility. Do not wait until an incident to discover that a valid database backup cannot restore a user's connections.

Retention differs by data type

Application records, conversation state, monitor captures, signed evidence and knowledge indexes serve different purposes and may use different stores. Choose retention and restore procedures for each. A restore can also reintroduce old operation records, so reconcile external effects before resuming automation from recovered state.

Restore data with its protection keys

  1. Use the SQL data-protection key ring and a host-configured protection certificate where required; keep private keys in an appropriate secret/certificate system.
  2. Back up application data and protection material with a tested recovery procedure. Apply schema changes through the supported initialization/migration path.
  3. Restart the sample and check agent state, history, harness snapshots, reminders and delivery checkpoints. Record in-flight tasks that could not resume.
Host setup · reference snippet
using FabrCore.Host;
using FabrCore.Services.Connections;
using FabrCore.Services.RemoteAgents;

builder.AddFabrCoreServer(new FabrCoreServerOptions {
    AdditionalAssemblies = [typeof(ConnectionsExtensions).Assembly,
                            typeof(RemoteAgent).Assembly]
});
builder.Services.AddFabrCoreConnections(o => {
    o.Enabled = true;
    o.EntraAgentIdEnabled = false;
    o.ClientHandoffEnabled = false;
});
builder.Services.AddFabrCoreRemoteAgents(o => o.Enabled = true);

// Also configure the host's normal user authentication/authorization.
var app = builder.Build();
app.UseFabrCoreServer();
app.MapFabrCoreConnections();
app.Run();
Host setup · reference snippet
{
  "FabrCore": {
    "DataProtection": {
      "ApplicationName": "my-cluster-production",
      "CertificatePath": "/run/secrets/fabrcore-protection.pfx"
    }
  }
}

Run an isolated restore rehearsal

  1. Back up the staging databases and required protected key material using the deployment's supported mechanism. Restore them into an isolated environment with outbound business writes disabled.
  2. Start the matching application version and verify a saved agent record, conversation and a protected connection record can be read through authorized APIs. Report decryption failures separately from missing tables.
  3. Check what happened after the backup time in the authoritative external system before allowing recovered workflows to resume. Record the recovery point and any known missing interval.

The outcome is a repeatable recovery procedure with explicit dependencies. Process startup alone is not sufficient evidence that restored encrypted and business data are usable.

If the result is different

A successful database restore is insufficient if the certificate/key ring is missing. Keep ephemeral development protection out of persistent multi-host deployments.

Go deeper

Explore the related documentation.