Availability Machine

The Availability Machine (AM) is the data management and data governance hub for each MySQL database service in Tessell. It provides a centralized interface for snapshots, native backups (via Percona XtraBackup), data sanitization, data access policies, and cloning — all in one place. Every provisioned database service automatically gets an associated AM, owned by the data owner who owns the database service.

---

Prerequisites

Ensure that you have created your MySQL database service in the Provisioning application under the DB Services app family. For more information, see Provisioning a MySQL DB service.

---

What can I do in an Availability Machine?

Capability	Description
Snapshots	Automatically capture cloud-native, incremental, application-consistent point-in-time copies on a configured schedule; take manual ad-hoc snapshots at any time. Maximum long-term retention is 35 days on a Standard RPO policy; use a Custom RPO policy for weekly, monthly, or yearly retention.
Transaction logs (binary logs)	Continuously archive MySQL binary log (binlog) segments every 5 minutes to object storage for point-in-time recovery, replication, and continuous data protection
Native Backups	Create full and incremental backups using Percona XtraBackup, a MySQL-compatible physical backup utility, from an existing snapshot
Sanitization	Mask or anonymize sensitive data (PII, card numbers, etc.) using your own SQL scripts before creating copies for lower environments
Data Access Policies (DAP)	Control what data is shared, with whom, in which region, and on what schedule — across subscriptions and clouds
Clones	Provision a full database clone from any snapshot
Sharing	Share the AM itself with other Tessell users (Co-owner or Read-only)

Binary logging must be enabled for HA, DR, and Read Replica configurations.

---

What does the Availability Machines dashboard show?

Navigate to DB Services → Availability Machines to view the dashboard. It lists all AMs you can access.

Dashboard filters

Filter	Behavior
Search	Filter by database service name
Engine	All, MySQL, Oracle, PostgreSQL, or SQL Server
Cloud	All, AWS, Azure, or GCP
Owner	Filter by a specific username or All
Subscription	Filter by cloud subscription or All
Clear	Reset all filters to defaults

Dashboard columns

Column	Description
Name	Database service name with the MySQL engine icon. Click to open the AM home page.
Cloud and Region	Cloud provider and region where the source DB service is hosted
DAPs	Number of data access policies configured for this AM
Source DB Status	Current status of the associated database service (see table below)
Created	Date, time, and username that provisioned the database service
Ellipsis icon	Available only when the source DB is deleted — allows you to delete the AM

Source DB status reference

Status	Description
Ready	Source database service is running; connections are accepted
Stopped	Source database service is not running; connections are not accepted
Deleted	Source database service has been deleted; the AM remains until you delete it manually

Figure 1 — Availability Machines dashboard

---

What does the Availability Machine home page show?

Clicking a service name on the dashboard opens its AM home page. The source DB status is shown next to the service name.

Top-right buttons

Button	Action
DB Service	Opens the My Services home page for this database service. See MySQL My Services.
Dataflix	Opens the Dataflix home page for this database service. See Dataflix.
Update RPO Policy	Opens the RPO policy wizard to configure snapshot schedules and binary log archival.

Summary panel

Expand the top bar to view a summary of the AM, grouped into three sections:

RPO Policy and DB details

Field	Description
RPO Policy	Retention days and backup type as configured
Transaction Logs	Whether binary log archiving is enabled
Source DB Status	Current status of the source database service

Cloud details

Field	Description
Cloud	Cloud provider hosting the database service
Region	Cloud region of the database service

User details

Field	Description
Owner	Tessell account username of the AM owner
My role	Your role: Owner, Co-owner, or Read-only
TRN	Tessell Resource Name — globally unique identifier for use with Tessell APIs

The AM home page has the following tabs: Data Flow, Snapshots, Sanitization, Native Backups, Access Policies, Clones, and Sharing.

Figure 2 — Availability Machine home page

---

How do I update the RPO Policy?

Click Update RPO Policy on the AM home page. The Update RPO Policy and Schedule window opens with two configurable sections:

Include Transactional Logs

Select the Include Transactional Logs checkbox to enable Tessell to archive binary log (binlog) segments every 5 minutes. Logs are stored in Amazon S3 (AWS) or Azure Blob Storage (Azure).

Schedule Snapshots

Toggle Schedule Snapshots to enable automated snapshot capture.

Tessell uses cloud-native snapshots as the default backup mechanism. Snapshots are application-consistent, always incremental, and faster to restore than traditional backups.

1. Select a configuration type: Standard or Custom.
2. For Standard:

   • Specify snapshot retention (1–35 days).
   • Pick the daily time for snapshots.
3. For Custom:

   • Choose an RPO policy from the dropdown (create policies in DB Governance under Governance).
   • Pick the daily time for snapshots.
   • Review the RPO Policy Details panel (policy description, type, and whether PITR is enabled).
4. Under Snapshot frequency, configure:

   Field	Description
   RPO Policy	Selected policy options: Continuous Recovery (PITR), Daily, Weekly, Monthly, and/or Yearly Snapshots
   Every	Frequency for weekly/monthly/yearly schedules. Daily shows the scheduled time. Disabled for PITR.
   Keep for	Retention period (days) per the selected RPO policy

5. Click Update to apply all changes.

Note: Automated RPO scheduling is not supported for MySQL native backups — native backups are always created manually. See Native Backups.

---

What does the Data Flow tab show?

The Data Flow tab is a visual representation of how data moves through the AM.

• The source DB box represents your primary database service.
• The AM box (center) is the data management layer receiving continuous data from the source.
• The RPO policy box (handshake icon) shows the configured backup schedule.
• Region boxes show where snapshots and binary logs are replicated to, as configured by DAPs.

A continuous stream flows from the source DB to the AM, representing ongoing snapshot and binary log capture. For multi-AZ (HA) services, snapshots and binary log backups are taken from the primary node and replicated to the replica region boxes. Regions with manual snapshots only do not show a continuous data stream, since manual snapshots are retained only until you delete them.

Use the + / − icons (bottom left) to zoom in or out, or the expand icon to view in full screen.

---

Snapshots

Tessell automatically captures snapshots on the schedule defined by your RPO policy. You can also take manual ad-hoc snapshots at any time. The Snapshots tab shows all snapshots for the service.

Snapshot status reference

Status	Description
Available	Snapshot is complete and ready to use
Queued	Snapshot is scheduled and waiting for a prior task to finish
Creating	Snapshot capture is in progress
Failed	Snapshot did not complete successfully

Snapshot table columns

Column	Description
Snapshot Name	Name of the snapshot
Availability	Number of regions where the snapshot is available. Click to see region name, status, access policy, and shared users.
Status	Current snapshot status (see above)
Size (GiB)	Snapshot size in GiB
Snapshot Time	Exact date and time the snapshot was captured

The Manual Snapshots view (the default) lists all manually triggered snapshots. The Automatic Snapshots view lists snapshots taken per the RPO policy. Use the Search bar to find a snapshot by name; use the Status filter to narrow by state.

Note: Tessell does not automatically delete manual snapshots. You must delete them manually from this tab. Automatic snapshots are deleted per the RPO policy — update the retention period and time using Update RPO Policy.

How do I take a manual snapshot?

1. Click + Take Snapshot (top right of the Snapshots tab).
2. Enter a Snapshot Name.
3. Click Submit.

As an alternative, use the Code button (bottom-left of the dialog) to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell.

How do I star or unstar a snapshot?

Automatic snapshots, automatic sanitized snapshots, and automatic native backups are deleted after their retention period. Starring an automatic entry prevents automatic deletion indefinitely.

Note: Manual snapshots, manual sanitized snapshots, and manual native backups are never automatically deleted — they do not need to be starred.

To star:

1. In the Automatic Snapshots view of the Snapshots, Sanitization, or Native Backups tab, click the ellipsis icon on the entry → Star.
2. Review the notice (additional storage costs may apply) → click Star to confirm.

A star icon appears next to the entry. The entry is retained until you unstar it.

To unstar:

1. Click the ellipsis icon on the starred entry → Unstar.
2. Review the notice (the entry resumes its original retention schedule) → click Unstar to confirm.

Note: If the original retention period has already elapsed, the entry is queued for deletion immediately after unstarring. Starred snapshots and backups can be independently retained during service deletion. See Delete the service.

Figure 3 — Snapshots tab

---

Sanitization

Tessell sanitization creates a masked copy of production data before it is used in lower environments (testing, development, training). You provide a SQL masking script; Tessell applies it by:

1. Creating a temporary clone VM from the source snapshot.
2. Running the masking SQL script against the MySQL databases on the clone VM.
3. Capturing a new snapshot from the masked clone — this is the sanitized snapshot.

Sanitized snapshots can be shared or used for cloning, just like regular snapshots. Sanitization is available both on-demand and as an automated schedule.

Prerequisite: Upload your SQL masking script to the Script Library under DB Services before sanitizing.

Sanitized snapshot table columns

Column	Description
Snapshot Name	Name of the sanitized snapshot
Status	Available, Queued, Creating, or Failed
Schedule Name	Name of the automated sanitization schedule that created this snapshot (empty for manual)
Size (GiB)	Size of the sanitized snapshot in GiB
Script Name/Version	Name and version of the SQL masking script applied
Availability	Regions where the sanitized snapshot is available; click for region, status, access policy, and shared users
Snapshot Time	Exact date and time the sanitized snapshot was captured

Filter sanitized snapshots using the Status filter or the Script filter. Use the Search bar to find by name.

Note: Sanitized snapshots can be starred to prevent automatic deletion. See How do I star or unstar a snapshot?

How do I create a sanitized snapshot?

1. Click + Sanitize Snapshot.
2. Enter a Sanitized snapshot name.
3. Choose a Source snapshot (manual or automatic) from the dropdown.
4. Choose a Data masking script from the dropdown.
5. Choose the Script version.
6. Click Submit.

Use the Code button (bottom left of the dialog) to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell.

How do I create a sanitization schedule?

Automated schedules sanitize snapshots at a configured frequency without manual intervention.

1. Click + Create Schedule.
2. Fill in the schedule details:

   Field	Description
   Schedule Name	Name for this sanitization schedule
   Description	Optional description
   Frequency	Daily (every day) or Weekly (select specific days)
   Keep each snapshot for	Retention period for sanitized snapshots (days or weeks)
   Snapshot name prefix	Prefix for sanitized snapshot names (default: "Sanitized")
   Script	SQL masking script to apply
   Script version	Version of the selected script

3. Click Save.

Click Show Schedules to list all existing sanitization schedules. Each schedule entry shows: Schedule Name, Script info (name and version), Retention, Snapshot Name Prefix, and Create on (timestamp).

Figure 4 — Sanitization tab

---

Native Backups

Native backups for MySQL use Percona XtraBackup, a MySQL-compatible physical backup utility. Percona XtraBackup supports non-blocking hot backups for InnoDB databases, built-in compression, and direct streaming to cloud object storage.

Native backups are always triggered manually from a selected snapshot: a temporary clone VM is created from the snapshot, and Percona XtraBackup runs on the clone VM, avoiding any load on the source database.

Note: Automated RPO scheduling is not supported for MySQL native backups.

Native backup table columns

Column	Description
Backup Name	Name assigned at creation
Status	Available, Queued, Creating, or Failed
Size	Backup size in GiB
Type	Full or Incremental
Availability	Regions where the backup is available; click for region name, status, access policy, and shared users
Created on	Date and time the backup was taken
Shared With	Users with access to this backup

Use the Search bar to find a backup by name. Use the ellipsis icon on a row to Delete a backup.

Note: Native backups can be starred to prevent automatic deletion. See How do I star or unstar a snapshot?

How do I create a manual native backup?

1. Click + Create Backup. The Create Manual Backup window opens.
2. Enter a Backup Name.
3. Choose the Source snapshot (manual or automatic) from the dropdown.
4. Click Create. A workflow runs at the backend and captures the backup for your database service using Percona XtraBackup.

Note: Manual native backups can be downloaded and deleted from the UI.

Use the Code button (bottom-left corner) to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell.

How do I download a native backup?

For manually triggered native backups, use the Download button in the Dataflix tab to generate a pre-signed URL for downloading the backup files from S3 or Blob Storage. This lets you restore the database outside of Tessell — on-premises, on another cloud VM, or in a different environment.

Figure 5 — Native Backups tab

---

Access Policies (DAP)

A Data Access Policy (DAP) defines what data is shared, with whom, where (same or cross-region, same or cross-subscription), and how (as-is, sanitized, or native backup). DAPs enable data owners to make snapshots or binary logs available for secondary use cases — DR, testing, staging, archiving, migration — without copying data manually. If the DAP has continuous recovery (PITR) enabled, you can also create a point-in-time database copy, and use the DAP to refresh lower environments on a regular cadence.

DAP cross-region and cross-subscription support

DAP type	Same subscription, any region	Cross-subscription, same region	Cross-subscription, cross-region
Snapshot-only	Supported	Supported	Supported
PITR	Supported	Not supported	Not supported
Native Backups	Supported	Supported	Supported

DAP table columns

Column	Description
Policy Name	Name of the access policy
Status	Active or Inactive
Shared Across	Number of subscriptions the data is shared to
Content Type	As-is, sanitized, or backups — and whether automated or manual
Available Content	Frequency and retention period for the shared content

Use the Search bar to find a policy by name. Use the ellipsis icon on a policy row for Manage Access, Update, or Delete Policy.

How do I create a Data Access Policy?

1. Click + Create Policy.
2. In Policy Name, enter a name for the policy.
3. In Target subscription, configure the destination:

   • Choose a subscription from the dropdown.
   • Choose a target region for replication.
   • Choose an encryption key.
   • Add more regions if needed.
   • In Add users to grant access, select the users who can access the replicated data.
4. Select the data access mode:

   As-Is Data — share source snapshots and/or PITR logs without processing.

   • Choose Automated or Manual snapshots.
   • For automated: set frequency and retention period.
   • Toggle the switch to change retention days for PITR and daily frequency.
   • For manual: select from the available manual snapshot list.

   Sanitized Data — share post-processed (masked) snapshots.

   • Choose Automated or Manual sanitized snapshots.
   • For automated: choose a sanitization schedule from the dropdown, and set frequency and retention period.
   • For manual: select from the available manual sanitized snapshot list.
   • Note: PITR is only available in As-Is mode.

   Backups — share native backup access for complete recovery.

   • Choose Automated or Manual backups.
   • For automated: set frequency and retention period.
   • For manual: select from the available manual backups list.
5. Click Submit.

Use the Code button (top right of the window) to generate API calls in Shell, Python, Go, Java, JavaScript, or PowerShell.

How do I manage an existing access policy?

Click the ellipsis icon on a policy row:

Manage Access — add or remove users from an existing policy.

1. Select Manage Access.
2. Add or remove usernames.
3. Click Update Access.

Update — modify the policy name, target subscription, or content settings.

Delete Policy — permanently remove the policy.

1. Select Delete Policy.
2. Check the Remove the access policy confirmation checkbox.
3. Click Remove.

Deleting a policy revokes all user access granted through it and removes replicated cloud snapshots from the target regions.

Figure 6 — Access Policies tab

---

Clones

The Clones tab lists all database clones created from this AM using the Availability Machine and Dataflix applications.

Clones table columns

Column	Description
Name	Cloned service name
Status	Creating, Ready, Stopped, or Deleted
Cloud/Region	Cloud provider and region of the cloned service
Source	Source snapshot name, timestamp, and content type (e.g., as-is)
Infrastructure	Compute shape of the cloned service
Created	Date and time the clone was requested

Filter by owner using the Owner field next to the search bar.

How do I create a clone?

1. Click + Create Clone. This opens the Dataflix application with a list of available snapshots (timestamp, size, and regions).
2. Select a snapshot to review details (creation timestamp, size, number of databases, cloud details).
3. Click Clone (bottom right).
4. Configure the clone:

   Setting	Notes
   Service name, description, tags	Identify the clone
   Cloud provider settings	Region, VPC/VNet, subnet
   Compute shape	Parent database server configuration is shown; storage cannot be changed for a clone
   Database instance	Master credentials and connection settings
   Additional settings	Maintenance window, Performance Insights, and Availability Machine configuration for the clone

5. Click + Clone Service to submit.

Tessell automatically:

1. Submits the clone request.
2. Creates the compute instance(s).
3. Configures the database.
4. Sets up the Availability Machine.
5. Triggers the first snapshot.

Figure 7 — Clones tab

---

Sharing

The Sharing tab allows you to share the Availability Machine with other Tessell users, granting them access to AM data (snapshots, backups, policies, and clones).

How do I share the Availability Machine?

1. Click Share (top right of the Sharing tab).
2. Choose a Role: Co-owner or Read-only.
3. Search for users using the Search bar.
4. Move users from the Choices column to the Chosen column to grant access.

   Only users with Data Owner roles appear in the Choices column. Manage users and roles in the IAM application under Governance.

5. Click Save.

How do I change a user's role or remove their access?

The Sharing tab lists all users the AM is shared with and their roles. Click the ellipsis icon on a user row:

Change Role

1. Select Change Role.
2. Choose Co-owner or Read-only from the dropdown.
3. Click Update.

Remove User

1. Select Remove User.
2. Confirm the removal → click Remove.

Figure 8 — Sharing tab

---

Glossary

Term	Definition
Binary Log (Binlog)	Sequential records of all changes made to a MySQL database. Binary log segments are archived every 5 minutes and stored in S3 (AWS) or Blob Storage (Azure). Used for point-in-time recovery, replication, and continuous data protection. Binary logging must be enabled for HA, DR, and Read Replica configurations.
Clone	A duplicate of an existing database created from a snapshot, native backup, or PITR recovery point. Used for testing, development, or troubleshooting without affecting the production database.
Data Access Policy (DAP)	Defines rules for sharing AM data — who can access it, what they can access, in which region, and under what schedule.
Native Backup	A backup created using Percona XtraBackup, a MySQL-compatible physical backup utility. Supports full and incremental backup types.
Percona XtraBackup	An open-source, enterprise-grade MySQL backup utility. Provides non-blocking physical backups of InnoDB tables, incremental backup support, built-in compression, and native S3/Azure Blob Storage support. Tessell uses Percona XtraBackup as the underlying engine for MySQL native backups.
Recovery Point Objective (RPO) Policy	Specifies the maximum acceptable data loss, measured in time. Defines how frequently snapshots and binary log captures occur.
Sanitization	The process of creating a secure version of production data by applying data-masking SQL scripts to the snapshots. Ensures that snapshots can be safely used for development, testing, or analytics without exposing confidential information.
Snapshot	A point-in-time copy of a database service's storage volumes. For MySQL, Tessell uses cloud-native incremental snapshots that are application-consistent.