# Availability Machine ## Prerequisites Ensure that you have created your PostgreSQL database service in the Provisioning application under the DB Services app family.\ For more information on provisioning, see [Provisioning a PostgreSQL DB service](https://docs.tessell.com/tessell/tessell-for-postgresql/db-services/provisioning-postgresql). *** ## Introduction Availability Machine (AM) is a prominent in-built application under the DB Services app family in Tessell. It offers DBAs and data administrators a centralized approach to data management, featuring differentiated automation, and robust data protection. This application lies at the core of Tessell's data management architecture. When you provision a PostgreSQL database service in Tessell, an AM gets associated with it. AM is a logical construct that encompasses the data management aspects for each database service. AM's are owned by the data owners who own the database services. Availability Machine features: * Create and maintain database snapshots and native backups for data protection purposes. Snapshots use cloud-native incremental snapshots for application-consistent backups. These snapshots are faster to restore. The backups are retained for short-term or long-term periods as per the RPO policy. The maximum long-term retention possible is 35 days for snapshots. * Take WAL (Write-Ahead Log) backups as per the RPO policy. WAL segments are archived every five minutes and pushed to Amazon S3 (for AWS) or Blob Storage (for Azure) for durable storage. * Sanitize the data or mask sensitive information and create sanitized snapshots. * Create database-native backups (full and incremental) for long-term retention. * Create Data Access Policies (DAP) that help to control data sharing — what to share, how much to share, with whom to share, when to share, and where to share. Refer to the [Glossary](#glossary) for definitions of all the related terms used in this document. *** ## Availability Machines dashboard On the left navigation bar of the Tessell portal, select **Availability Machines** under **DB Services** to view the Availability Machines dashboard. This lists all the available AMs on its dashboard. The fields in the dashboard filters are: * **Search** — In the search bar, you can specify the name of the database service to search and list the details of the corresponding AM. * **Engine** — You can choose a database engine from the dropdown list. Select **PostgreSQL** to filter for PostgreSQL services only. By default, it lists all database engine services. The possible values are **All**, **MySQL**, **Oracle**, **PostgreSQL**, and **SQL Server**. * **Cloud** — You can choose a cloud provider from the dropdown list. By default, it lists all the cloud regions. The possible values are **All**, **AWS**, **Azure**, and **GCP**. * **Owner** — You can choose a specific username from the dropdown list to view the details of the database services owned by the user. By default, it lists all the owners. * **Subscription** — You can choose a cloud subscription from the dropdown list. By default, all the subscriptions are displayed. * **Clear** — Click this to clear the selected filters and revert to default settings. The fields in the table provide an overview of the availability machines for the services you created: * **Name** — Displays the name of the database service provided during provisioning. It also displays the PostgreSQL engine icon. If you select the service name, it takes you to the AM home page of that database service. * **Cloud and Region** — Displays the cloud and region name you chose to host your database service during provisioning. * **DAPs** — Displays the data access policies configured for the database service. These data access policies are created and managed from the AM's home page. * **Source DB Status** — Displays the status of the database service associated with the AM. | Status | Description | | ------- | -------------------------------------------------------------------- | | Ready | Source database service is up and running. Connections are allowed. | | Stopped | Source database service is not running. Connections are not allowed. | | Deleted | Source database service is deleted but the AM is not deleted. | * **Created** — Displays the date and time on which your database service is created and assigned an Availability Machine. It also displays the username who created the database service. * **Ellipsis icon** — The ellipsis icon is enabled only if the source database service is deleted. It provides the option to delete the AM. **Figure 1 - Availability Machines dashboard** ![](/files/ilWS1SSozCH0DZbUZjUz) *** ## Availability Machine home page Selecting any of the database services from the AM dashboard takes you to the home page of that availability machine. Every AM has a separate home page with its statistics. On the Availability Machine home page, the status of the source DB is displayed next to its name. On the top right-side, you see the following options: #### DB Service Click to go to the My Services home page of the database service. #### Dataflix Click to go to the Dataflix home page of the database service. #### Update RPO Policy The Recovery Point Objective (RPO) policy dictates the frequency and retention policies for Tessell captured automated DB service snapshots and logs. This is done to ensure DB recoverability and data protection. 1. Click this option to update the recovery point objective policy.\ The **Update RPO Policy and Schedule** window opens to update the RPO policy and apply the changes. 2. **Include Transactional Logs** — Selecting this check box indicates the Tessell platform takes backup of WAL segments.\\ 3. **Schedule Snapshots** — Toggle this option to schedule snapshots. 1. Select the configuration type for RPO policy, **Standard** or **Custom**. 2. For Standard policy: 1. Specify the snapshot retention days in the range of 1 to 35 days. 2. Pick a time you wish to take the snapshot of your database service. 3. For Custom policy: 1. Choose an RPO policy from the dropdown list.\ To use an RPO policy, ensure that you have created an RPO policy in the **DB governance** application under the **Governance** app family. 2. Pick a time you wish to take the snapshot of your database service.\ The **RPO Policy Details** window displays the details related to the chosen RPO policy, including: * Description of the policy if available * Type of the policy, Standard or Custom * Whether PITR is enabled for your policy 3. Select the desired frequency for the RPO Policy to create and store snapshot backups. * **RPO Policy** — Displays the selected RPO Policy. The possible options are one or more from Continuous Recovery (PITR), Daily Snapshots, Weekly Snapshots, Monthly Snapshots, and Yearly Snapshots, as per the option selected in the RPO policy field above. * **Every** — Depending on the schedule type, select the frequency of the snapshot. For Daily Snapshots, this field provides the scheduled time. For PITR, this is disabled. * **Keep for** — Displays the number of days for which a snapshot or a backup needs to be retained as per the selected RPO policy. 4. **Schedule Native Backups** — Toggle this option to schedule native backups for PostgreSQL. Native backups use pgbackrest, a PostgreSQL-native backup utility, to produce full and incremental backup files stored in the object storage of your cloud account (S3 for AWS, Blob Storage for Azure). 1. Select the configuration type, **Standard** or **Custom**. 2. For Standard policy: 1. Specify the backup retention days in the range of 7 to 35 days. 2. Choose a day from the **Full backup day** dropdown list. 3. Pick a time from the **Full backup time** dropdown list. 4. Pick a time from the **Incremental backup time** dropdown list. 3. For Custom policy: 1. Choose an RPO policy from the dropdown list. 2. Choose a day from the **Full backup day** dropdown list. 3. Pick a time from the **Full backup time** dropdown list. 4. Pick a time from the **Incremental backup time** dropdown list. 5. Select the desired backup frequency for your RPO Policy. * **Policy Frequency** — The possible options are one or more from Daily Backups, Weekly Backups, Monthly Backups, and Yearly Backups. For daily backups, a combination of full and incremental backups is taken. For weekly, monthly, and yearly backups, a full backup is taken. * **Every** — Depending on the schedule type, provides the frequency of the backup. * **Keep for** — Displays the number of days for which a backup needs to be retained as per the selected RPO policy. 5. Select the **Update** button at the bottom to apply the changes. ### Summary Expanding the top bar on the AM gives a summary of the AM.\ The summary includes the following details: #### RPO Policy and DB details * **RPO Policy** — Displays the number of retention days and type of backup as per the policy. * **Transaction Logs** — Displays whether transaction logs (WAL archiving) are enabled. * **Source DB Status** — Displays the status of the source DB service for this AM. The possible values are Ready, Stopped, and Deleted. #### Cloud details * **Cloud** — Displays the name of the cloud hosting your database service (AWS or Azure). * **Region** — Displays the name of the cloud region hosting your database service. #### User details * **Owner** — Displays the username of your Tessell account's owner. * **My role** — Displays your role for the database service. The possible values are Owner, Co-owner, or Read-only. * **TRN** — Displays the Tessell resource name. The TRN is a globally unique ID. Use the copy button to copy the TRN. When you click a database service in the AM dashboard, various tabs are displayed on the AM home page that include: Data Flow, Snapshots, Sanitization, Native Backups, Access Policies, Clones, and Sharing. Let us discuss each of these tabs in the next steps. **Figure 2 - Availability Machine home page** ![](/files/N3tPi5Xbkk4r62MR0WU0) *** ## Data Flow The Data Flow tab displays how the data is moving in the system. The data owner can configure an RPO policy and Data Access Policies (DAP) for the AM. This tab displays the flow of the data from your database service (source DB) to AM and from AM to different regions as per the configured RPO policy and DAPs. The main box represents your source DB. The central box is your AM that is acting as the central data management construct. The box with a hand-shake icon shows your configured RPO policy. There is a continuous stream of data flowing from the source DB box to the AM box, representing that data from the source DB is captured via snapshots and WAL segments are continuously captured and retained as per the configured RPO policy. If your database service is configured as multi-AZ (HA), then the snapshots and WAL backups are taken from the primary node and replicated to the replica region boxes and retained as per the configured RPO policy for that particular region. The data flow from AM to different region boxes is different as per the configured RPO policy and DAP policies for that region. The region with manual snapshots does not have any continuous data flow from AM as the manual snapshots are retained until you delete them manually. You can zoom in or out using the **+** or **-** icons from the bottom left corner of the page. You can also view the Data Flow in full screen using the expand screen icon from the bottom left of the page. *** ## Snapshots Snapshots of your PostgreSQL database service are automatically taken as per the configured RPO policy. You can also manually create an ad hoc snapshot at any time. The Snapshots tab displays all the details of the created snapshots for your database service. On the top, you can specify the name of your snapshot in the search bar and search for the particular snapshot and its details. You can filter the snapshots according to the status using the **Status** field next to the search bar. The possible status values are: * **All** — Displays all the snapshots with any of the possible status (default). * **Available** — Select this option to list all the available snapshots. * **Queued** — Select this option to list all the snapshots that are scheduled and waiting. * **Creating** — Select this option to list all the snapshots that are in progress. * **Failed** — Select this option to list all the snapshots that did not complete. * Click **Clear** to clear the applied filters. By default, it displays the list of all the manual snapshots and their details. To take a manual snapshot: 1. Click **+ Take Snapshot** button at the top right corner. 2. Specify the snapshot name and then click **Submit**.\ **Note:** Tessell does not automatically delete manual snapshots. You must return to this tab and delete them manually. As an alternative method, use the code to take a manual snapshot. 1. Use the **Code** button at the bottom-left corner to view the **Code for Take snapshot** window. 2. On the left-hand side of the window, you can view the API, its type, and the payload. 3. On the right-hand side of the window, you can view the code to take snapshot in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using the respective buttons. 5. Use the **Close** button to return to the main window. Select **Automatic Snapshots** to list all the automatic snapshots and their details. The automatic snapshots are taken as per the RPO policy configured for your database service. The table on **Manual Snapshots** and **Automatic Snapshots** displays the following details for each snapshot: * **Snapshot Name** — Displays the name of the snapshot. * **Availability** — Displays the number of regions for which the snapshot is available. Select the region for a particular snapshot to view: * **Region** — Name of the region where the snapshot is available. If a DAP is configured, this shows all the regions where the snapshot is replicated. * **Status** — Availability status of the snapshot in that region. * **Access Policy** — Name of the access policy defined for your database service. * **Shared with** — Name of the user(s) with whom the snapshot is shared. It displays **No users** if not shared. * **Status** — The possible options are Available, Queued, Creating cloud snapshot, and Failed. * **Size (GiB)** — Displays the size of the snapshot. * **Snapshot Time** — Displays the exact date and time when the snapshot was taken. Each manual snapshot can be removed using the **Delete** option from the ellipsis icon at the end of each row. Automatic snapshots are deleted as per the RPO policy. You can update the number of retention days and the time for automatic snapshots using **Update RPO Policy** at the top right corner. **Figure 3 - Snapshots tab** ![](/files/mndMsDmksjG5GyUaC9tO) *** ## Sanitization Tessell offers database sanitization as both an on-demand and an automated scheduled workflow. The sanitization workflow is designed to mask or sanitize sensitive information (such as credit card data, PII data, and so on) before copies of databases are created for lower environments. You can sanitize the snapshots manually or create a schedule to sanitize them automatically. Sanitized snapshots are useful for application testing or user training when a full production dataset is not required. These snapshots can be used or shared as needed. As you know your data best, you are expected to provide the SQL scripts which mask the data before creating a snapshot for a lower environment.\ You need a masking SQL script added to your script library to sanitize a snapshot. For more information, see Script Library app. Whenever a snapshot sanitization request is submitted, a workflow is run at the backend which creates a clone VM using the source snapshot. After creating a clone VM, the masking SQL script is run against the PostgreSQL databases on the clone VM. After the script is run successfully and the data is masked, it captures a snapshot from the clone VM and provides a sanitized snapshot. On top of the Sanitization tab, you can specify the name of your sanitized snapshot in the **Search** bar and search for the particular snapshot and its details.\ You can filter the sanitized snapshots according to the status using the **Status** field next to the search bar. The possible status values are: * **All** — Displays all the sanitized snapshots (default). * **Available** — Lists all the available sanitized snapshots. * **Queued** — Lists sanitized snapshots that are scheduled and waiting. * **Creating** — Lists sanitized snapshots that are in progress. * **Failed** — Lists sanitized snapshots that did not complete. You can also filter the snapshots based on a particular script. The possible values are **All**, and the list of available scripts for your database service.\ You can select the **Clear** button to clear the applied filters. By default, the table displays the list of all the sanitized snapshots and their details: * **Snapshot Name** — Name of the sanitized snapshot. * **Status** — Status of the sanitized snapshot (Available, Queued, Creating, or Failed). * **Schedule Name** — Name of the schedule through which this snapshot was sanitized. * **Size (GiB)** — Size of the sanitized snapshot. * **Script Name/Version** — Script name and version used to sanitize the data. * **Availability** — Number of regions for which the sanitized snapshot is available. Select to view: * **Region** — Region name. * **Status** — Availability status. * **Access Policy** — Name of the access policy. * **Shared with** — Users with whom the sanitized snapshot is shared. Shows **No users** if not shared. * **Snapshot Time** — Exact date and time when the sanitized snapshot was taken. ### Sanitize Snapshot 1. Click **+ Sanitize Snapshot** to create a sanitized snapshot: 2. Specify a name in the **Sanitized snapshot name** field. 3. Choose a source snapshot from the dropdown list.\ Both manual and automated snapshots are available. 4. Choose a data masking script from the dropdown list.\ You are responsible for providing the sanitization script. 5. Choose a version available for your script. 6. Click **Submit**. Select **Show Schedules** to see the list of all the schedules and their details for sanitized snapshots. * **Schedule Name** — Name of the schedule. * **Script info** — Name and version of the script used. * **Retention** — Number of days for which the sanitized snapshot is retained. * **Snapshot Name Prefix** — Snapshot prefix name given at creation time. * **Create on** — Date and time when the snapshot was sanitized. ### Create Schedule 1. Click **+ Create Schedule** to create a schedule for automated sanitization: 2. **Schedule Name** — Specify the name. 3. **Description** — Optionally, specify a description. 4. **Frequency** — Select from: * **Daily** — Sanitize snapshots daily. * **Weekly** — Sanitize snapshots weekly. Further, select the days. 5. **Keep each snapshot for** — Specify the retention period in days or weeks. 6. **Snapshot name prefix** — Specify a prefix name. Default is 'Sanitized'. 7. **Script** — Select the masking script. 8. **Script version** — Select the version. 9. Click **Save**. As an alternative method, use the code to create a sanitized snapshot or sanitization schedule. 1. Use the **Code** button at the bottom-left corner to view the code for the respective action. 2. On the left-hand side of the window, you can view the API, its type, and the payload. 3. On the right-hand side of the window, you can view the code in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using the respective buttons. 5. Use the **Close** button to return to the main window. **Figure 4 - Sanitization tab** ![](/files/vKWSRFEBFj9lTDlot2QS) *** ## Native Backups For PostgreSQL, native backups are produced using pgbackrest, a PostgreSQL-native backup utility. pgbackrest supports block-level incremental backups, parallel processing, built-in compression, and direct streaming to cloud object storage without requiring temporary local disk space. Tessell supports taking native backups either directly from the source database or from existing snapshots to avoid loading the source database. When a backup is created from a snapshot, a clone VM is created from the source snapshot and pgbackrest is run on the clone VM. Automated native backups run on the source VM directly. You can search the backups list by providing the backup name in the **Search** bar on the Native Backups tab. ### Create backup 1. Click **+ Create Backup** on the Native Backups tab to create a manual backup.\ The **Create Manual Backup** window pops up. 2. Specify the name of the backup in the **Backup Name** field. 3. Choose whether to take the backup from **Database** or **Snapshot**. * **Database** — Takes a native backup directly on the running PostgreSQL service. Suitable for on-demand, up-to-the-minute backup captures. * **Snapshot** — Creates a clone VM from a selected snapshot and runs pgbackrest on it. This avoids any load on the production database. 4. If **Snapshot** is chosen, select the source snapshot from the dropdown list.\ Both manual and automated snapshots are available. 5. Click **Create** to submit.\ A workflow runs at the backend and captures the backup for your database service using pgbackrest. > **Note:** Manual native backups can be downloaded and deleted from the UI. Automated backups generated via RPO schedules cannot be deleted manually; they are managed by the RPO retention policy. As an alternative method, use the code to take a manual backup. 1. Use the **Code** button at the bottom-left corner to view the **Code for Create new Backup** window. 2. On the left-hand side of the window, you can view the API, its type, and the payload. 3. On the right-hand side of the window, you can view the code to create a backup in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using the respective buttons. 5. Use the **Close** button to return to the main window. The automatic backups are taken as per the RPO policy configured for your database service. The table on the Native Backups tab lists all the backups and their details: * **Backup Name** — Name of the backup given at the time of creation. * **Status** — Status of the backup: * **Available** — The backup is ready for use. * **Queued** — The backup is scheduled and waiting. * **Creating** — Backup creation is in progress. * **Failed** — The backup did not complete. * **Size** — Size of the backup in GiB. * **Type** — Whether it is a full backup or incremental backup. * **Availability** — Number of regions where this backup is available. Select to view region details, status, access policy, and sharing info. * **Created on** — Date and time when the backup was taken. * **Shared With** — Users with whom the backup is shared. Select the ellipsis icon on the right-side to delete the backups using the **Delete** icon on each row. ### Downloading native backups 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 allows you to restore the database outside of Tessell — on-premises, on another cloud VM, or in a different environment — supporting Tessell's no-lock-in principle. > **Note:** The Download button is available only for manually triggered native backups. RPO-scheduled native backups are not available for individual download. **Figure 5 - Native Backups tab** ![](/files/DPD1da5oIvsosWs3NkWj) *** ## Access Policies The Data Access Policy (DAP) is one of the key data management services that helps data owners manage the availability of database snapshots and/or WAL logs for lower environments like DR, testing, staging, and so on. They can be made available for backup, archiving, data sharing, or migration in the same region or across regions. Production snapshots can be shared as-is, or they can be masked or processed before they are made available. Using the DAP, a data owner can define where the database snapshots or logs can be made available. As part of the configuration, the data owner can define which users or user-groups can access the data for the specified policy. You can make use of the shared data (snapshots/logs) to create a secondary copy of the database. If the DAP has continuous recovery enabled, you can also create a point-in-time database copy. The DAP can also be used to refresh lower environments on a regular basis or a defined cadence. You can search the access policy list by providing the policy name in the **Search** bar on the Access Policies tab.\ The table on the Access Policies tab lists all the policies and their details: * **Policy Name** — Displays the access policy name. * **Status** — Whether the policy is active or inactive. * **Shared Across** — Number of subscriptions the data is shared across. * **Content Type** — Whether it is as-is data, sanitized data, or backups. Also displays whether the data shared is automated or manual. * **Available Content** — Frequency and retention period in days for the content availability. Click the ellipsis icon on the right-side to see the following options: 1. **Manage Access** 1. Select **Manage Access** to add more users. 2. Specify the names of the users to grant access. 3. Click **Update Access**. 2. **Update** — Select this option to update policy details like name, target subscription, and content settings. 3. **Delete Policy** 1. Select **Delete Policy** to delete the policy. 2. Select the confirmation box, **Remove the access policy**. 3. Click **Remove**.\ This action revokes user access to the shared snapshot through this policy. The underlying cloud snapshot is also deleted from the target regions. ### Create Policy 1. Specify a policy name: 1. Click **+ Create Policy**. 2. Specify a name in the **Policy Name** field. 2. Select target subscription: 1. Choose a subscription from the dropdown list. 2. Choose the desired target region for data replication. 3. Choose an encryption key from the dropdown list. 4. If another region is available, you can add it. 5. In the **Add users to grant access** field, select the users. 3. Select data access mode: 1. **As-Is Data**\ Share the source snapshots (and PITR logs) as-is, without processing. 1. Select whether to share automated or manual snapshots. 2. If automated, select frequency and retention period. 3. Toggle the switch to change retention days for PITR and daily frequency. 4. If manual, select from the available manual snapshot list. 2. **Sanitized Data**\ Share the source snapshots post processing (sanitized/masked copy). 1. Select whether to share automated or manual sanitized snapshots. 2. If automated, choose a schedule from the dropdown list. 3. Select frequency and retention period. 4. If manual, select from the available manual sanitized snapshot list.\ **Note:** PITR is only possible in as-is data access mode. 3. **Backups**\ Share native backup access for complete recovery. 1. Select whether to share automated or manual backups. 2. If automated, select frequency and retention period. 3. If manual, select from the available manual backups list. 4. Click **Submit** to share the data as per the configured access policy. As an alternative method, use the code to create an access policy. 1. Use the **Code** button at the top-right corner to view the **Code for Create new access policy** window. 2. On the left-hand side of the window, you can view the API, its type, and the payload. 3. On the right-hand side of the window, you can view the code for adding a new policy in various languages like Shell, Python, Go, Java, Javascript, and Powershell that you can run independently. 4. You can copy and download the code using the respective buttons. 5. Use the **Close** button to return to the main window. **Figure 6 - Access Policies tab** ![](/files/J1AEX2EdMV1TYUX5LJtp) *** ## Clones You can create clones of PostgreSQL databases running in Tessell using the Availability Machine and Dataflix applications. On top of the Clones tab, you can specify the cloned service name in the **Search** bar.\ To filter cloned services by owner, use the **Owner** field.\ Click **Clear** to reset filters. The Clones tab displays the following details: * **Name** — Cloned service name. * **Status** — Status of the cloned service (Creating, Ready, Stopped, or Deleted). * **Cloud/Region** — Cloud provider and region for the cloned service. * **Source** — Source snapshot with name, time, and content type (for example, as-is). * **Infrastructure** — Compute shape of the cloned service. * **Created** — Date and time when the clone creation was requested. ### Create clone 1. Click **+ Create Clone**.\ This takes you to the Dataflix application where you see a list of available snapshots with timestamp, storage size, and number of regions. 2. Select from the available snapshots to view details like creation timestamp, size, number of databases, and cloud details. 3. Click **Clone** at the bottom right corner. 4. Configure the following options for your cloned service: * Service name, description, and tags * Cloud provider settings * Compute shape (parent database server configuration is displayed; storage cannot be changed for clones) * Database instance configuration * Additional settings including refresh schedule, maintenance window, performance insights, and availability machine > **Note:** Clone Refresh (also called Dev Refresh) lets you keep a cloned database service automatically updated with fresh data from its source database. Instead of creating a new clone every time you need current data in your dev/test environment, you set up a refresh schedule on an existing clone, and Tessell periodically restores it with the latest snapshot or PITR data from the source. * In **Refresh schedule**, select **No schedule** or **Automatic refresh**. * For automatic refresh, select the refresh day(s) and time. * Select the refresh mode: **Snapshot** or **PITR**. > **Note:** > > * In snapshot mode, the database is refreshed to the snapshot available at the selected time. If no snapshot is available, the refresh is skipped. > * In PITR mode, the database is refreshed to the latest available data at the selected time. If no data is available, the refresh is skipped. * In the **Custom Scripts for Refresh schedule** panel, select pre and post scripts from the respective dropdown list.\ To use a custom script, ensure that you have uploaded scripts in the **Script Library** application. 5. Click **+ Clone Service** at the bottom of the form. The following steps are performed automatically: * Request is submitted to clone the database service * Creates compute instance(s) * Configures the database * Availability Machine is set up * Triggers first snapshot **Figure 7 - Clones tab** ![](/files/4oo0Uhs0isGO4UlTHEw7) *** ## Sharing The Sharing tab allows you to share your availability machine with other users. You can search the users list by providing the user's name in the **Search** bar on the Sharing tab.\ The following details are displayed: * **User** — List of usernames with whom the availability machine is shared. * **Role** — The user's defined role: Co-owner or Read-only. Click the ellipsis icon on the right-side of the user details to see the following options: 1. **Change Role** 1. Click this option to change the role. 2. Select the role from the dropdown list (Co-owner or Read-only). 3. Click **Update**. 2. **Remove User** 1. Click this option to remove the user. 2. Select the user to remove and click **Remove**. To share an availability machine: 1. Click **Share** on the top right corner. 2. Choose a role from the dropdown list (Co-owner or Read-only). 3. Use the **Search** bar to search for specific users. 4. Move users from the left **Choices** column to the right **Chosen** column.\ Only users with Data Owner roles appear in the **Choices** column.\ **Note:** Users and roles are managed in the **IAM** application under the **Governance** app family. 5. Click **Save** to share your availability machine data. **Figure 8 - Sharing tab** ![](/files/8aGAZoGNziaa7OMpuVAv) *** ## Glossary | Term | Definition | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Clone | A duplicate of an existing database created from a snapshot, native backup, or PITR recovery point. Typically used for testing, development, or troubleshooting without affecting the production database. | | Data Access Policy (DAP) | Defines rules for accessing database data. It controls who can access snapshots, WAL logs, and backups, what actions they can perform, and under what conditions. | | Native Backup | A backup created using pgbackrest, PostgreSQL's enterprise-grade backup utility. Supports full and incremental backups stored directly in cloud object storage. | | Recovery Point Objective (RPO) Policy | Specifies the maximum acceptable data loss, measured in time. It defines how frequently snapshots, native backups, and WAL segment 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 PostgreSQL, Tessell uses cloud-native incremental snapshots that are application consistent. | | WAL (Write-Ahead Log) | Sequential records of all PostgreSQL database transactions. WAL segments are archived every 5 minutes and stored in S3 (AWS) or Blob Storage (Azure). Used for point-in-time recovery and continuous data protection. | | pgbackrest | An open-source, enterprise-grade PostgreSQL backup and restore utility. It provides block-level incremental backups, parallel processing, built-in compression, and native S3/Azure Blob Storage support. Tessell uses pgbackrest as the underlying engine for PostgreSQL native backups. | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tessell.com/tessell/tessell-for-postgresql/db-services/am-postgresql-doc.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.