Availability Machine

Every database protected. Every recovery proven

Tessell's Availability Machine is provisioned automatically with every database, continuously capturing snapshots, transaction logs, and native backups across every engine and every cloud. Protection isn't a configuration task. It's the default state.

The problem

Database protection comes in layers. Recovery fails in the gaps

Backup, recovery testing, retention governance, and replication have each been solved independently. Connecting them across every database, every engine, every cloud is where the hard problem lives.
Backup and recovery are separate workflows

Backup and recovery are separate workflows

A successful backup says nothing about whether it can be recovered. The two are validated independently, and estate-wide recovery health is a layer most teams build by hand.
Protection policies live outside the provisioning layer

Protection policies live outside the provisioning layer

A database gets provisioned; its protection doesn't. Schedules, retention, and RPO targets come after, so every database starts unprotected and standardizing takes constant manual work.
RPO and RTO targets are defined, not tested

RPO and RTO targets are defined, not tested

Recovery objectives live in continuity plans, but whether the architecture supports them goes unverified until a real incident. A tested RTO is the only guarantee.
How it works

One Availability Machine for every database. Always on

Tessell’s Availability Machine enables protection while a database is provisioned and your entire estate operates under a consistent, auditable protection posture from day one.

01 Source to AM
Continuous capture. Snapshots and transaction logs every 5 minutes, from the moment the database is provisioned.
02 AM center
The central data protection construct. Your RPO policy is enforced here: defining retention, frequency, and recovery scope.
03 Output artifacts
Every snapshot, log, and native backup retained and ready. What Dataflix browses and Data Access Policies govern.
04 Cross-region replication
Snapshots replicate automatically to secondary regions. Access and sharing governed by Data Access Policies.
What it does

Four things the AM handles automatically, from the moment your database is provisioned

From the moment your database is provisioned, the AM is already capturing data, enforcing retention, and producing everything recovery needs.

Continuous capture

Snapshots, transaction logs, and native backups captured automatically, across every engine, without manual setup.

  • Engine-native backups using each engine's own tooling
  • HPC hybrid backup pairs snapshots with native backups to minimize data loss.
  • Backup is built into provisioning so nothing to configure, license, or maintain.
Data Management

Four layers of data management, architected into one platform

Tessell connects protection, access, governance, and activation into a single platform. Managed from one control plane, with no gaps between them.

Ready to see what this looks like for your database estate?

Talk to a Tessell engineer, not a sales rep. Bring your environment, your engines, your cloud. Walk away with a clear picture of what the AM would change for your team.

Frequently Asked
Questions
The Availability Machine (AM) is Tessell's built-in data protection layer, automatically provisioned with every database, no separate setup required. It continuously captures snapshots, transaction logs, and native backups, enforces retention policies across your estate, and provides real-time visibility into backup health across every engine and cloud.
Oracle, SQL Server, PostgreSQL, and MySQL, each using its native backup technology. RMAN for Oracle, native .bak for SQL Server, pgbackrest for PostgreSQL, Percona XtraBackup for MySQL. All four engines support PITR, snapshot-based recovery, and custom RPO policies.
Yes, across all four engines. Transaction logs are captured every five minutes, enabling recovery to any specific timestamp within the retention window. PITR is available via the Dataflix interface and works independently of snapshot schedule.
Transaction logs are captured every five minutes, enabling granular PITR. Snapshot frequency is configurable: daily is standard, with weekly, monthly, and yearly options available through custom RPO policies. Manual snapshots can be taken on-demand at any time.
Standard retention is up to 35 days for snapshots and native backups. Custom RPO policies extend this with weekly, monthly, and yearly snapshot tiers, supporting multi-year retention mandates for financial services, healthcare, and government workloads.
An RPO policy defines how frequently backups are captured and how long they're retained. Policies are configured at the governance level and applied across database services, standard (up to 35 days, daily snapshots) or custom (daily, weekly, monthly, yearly tiers). Published policies are available estate-wide; unpublished policies are restricted.
Yes, on-demand from the AM interface at any time. Unlike automated snapshots which follow the RPO policy retention schedule, manual snapshots are retained indefinitely until manually deleted. They appear in the Dataflix catalog alongside automated snapshots and PITR recovery points.
You choose. Retain the AM, a final snapshot is taken, manual snapshots are preserved, and recovery remains available through Dataflix until retention expires. Delete the AM, all snapshots, logs, and access policies are permanently removed. Automated snapshots and transaction logs continue to be managed per the RPO policy either way.
Yes, when a Data Access Policy is configured, snapshots replicate automatically to the defined regions. The AM's data flow visualization shows replication status in real time, region, status, access policy, and who the data is shared with. No manual intervention required once the policy is set. Learn more about DAPs →