--- title: "Monitoring the Database Backup and Streaming Replication" slug: "monitoring-the-database-backup-and-streaming-replication-5-2" tags: ["8.3", "Portal"] updated: 2026-07-01T09:17:35Z published: 2026-07-01T09:17:35Z canonical: "kb.ctera.com/monitoring-the-database-backup-and-streaming-replication-5-2" --- > ## Documentation Index > Fetch the complete documentation index at: https://kb.ctera.com/llms.txt > Use this file to discover all available pages before exploring further. # Monitoring the Database Backup and Streaming Replication You can monitor every database backup and replication component running on the server, including: - Streaming replication - Base backup - WAL archive (continuous archive) ## Monitoring Database Backup and Replication from the Notifications Pane **To monitor database backup and replication from the Notifications page:** - In the global administration view, select **Main > Notifications** in the navigation pane. The **Notifications** page is displayed. Any alerts related to database backup or streaming replication are displayed. ## Monitoring Database Backup and Replication from the Server Task Manager If streaming replication is set up, you can monitor it from the Server Task Manager. The CTERA Portal runs a task every few minutes to verify that replication is working as expected. If any issues are detected, the task fails, and the CTERA Portal displays an appropriate notification in the **Notifications** page, and also sends an email alert to the portal administrators. **Note** The task runs the `portal.sh replication_status` command and analyzes the output. For more information see [Monitoring Database Backup and Replication from the Server Console](/v1/docs/monitoring-the-database-backup-and-streaming-replication-5-2#monitoring-database-backup-and-replication-from-the-server-console). **To monitor database backup and replication from the Server Task Manager:** 1. In the global administration view, select **Main > Servers** in the navigation pane. The **Servers** page is displayed. ![Image](https://cdn.document360.io/30792387-cdcb-4791-aa14-94929bbcd3fe/Images/Documentation/image-EMJH2JNR.png?sv=2026-02-06&spr=https&st=2026-11-11T04%3A28%3A18Z&se=2026-11-11T05%3A28%3A18Z&sr=c&sp=r&sig=cKYKj%2FWmrErSp8GNsODbM4cNVeTUYl6QRDmlaw2HpUw%3D) 2. Click the primary database server. The server window is displayed with the server name as the window title. ![image.png](https://cdn.document360.io/30792387-cdcb-4791-aa14-94929bbcd3fe/Images/Documentation/image-2GKQNRTI.png?sv=2026-02-06&spr=https&st=2026-11-11T04%3A28%3A18Z&se=2026-11-11T05%3A28%3A18Z&sr=c&sp=r&sig=cKYKj%2FWmrErSp8GNsODbM4cNVeTUYl6QRDmlaw2HpUw%3D) 3. Click the **DB Replication** option. The portal reports the status of its scheduled base backups and transaction log archiving process, as well as additional metrics to help detect when database replication falls behind due to lags in the process. In the event that replication falls behind, portal administrators are notified via email. The relevant email templates are *Replication setup failed* and *Replication has errors*. ![image.png](https://cdn.document360.io/30792387-cdcb-4791-aa14-94929bbcd3fe/Images/Documentation/image-5Y3CFM2M.png?sv=2026-02-06&spr=https&st=2026-11-11T04%3A28%3A18Z&se=2026-11-11T05%3A28%3A18Z&sr=c&sp=r&sig=cKYKj%2FWmrErSp8GNsODbM4cNVeTUYl6QRDmlaw2HpUw%3D) ## Monitoring Database Backup and Replication from the Server Console You can view the status of each database backup and replication component. **To monitor database backup and replication from the server console:** **Note** This procedure can be performed on both the primary server and on secondary servers. 1. Using SSH, log in as `root` to the CTERA Portal primary database server or secondary database server. 2. Run the following command: `portal.sh replication_status | json_reformat` The output is displayed in JSON format. For example: ``` { "streaming_replication": { "status": "ok", "lastSuccess": "256KB" }, "base_backup": { "status": "ok", "lastSuccess": "none" }, "wal_archive": { "status": "failed", "lastSuccess": "3 hours" } } ``` Both the primary and secondary servers have the same output structure. However, the fields have slightly different meanings. **streaming_replication** | Field | Primary Server | Secondary Server | | --- | --- | --- | | **status** | Indicates whether a secondary server is streaming from the primary server: **ok** – Streaming replication is running. **failed** – Streaming replication failed. **not configured** – Streaming replication is not configured on this server. | Indicates whether this server is streaming from the primary server: **ok** – Streaming replication is running. **failed** – Streaming replication failed. | | **lastSuccess** | The difference in size (in KB) between the last sent WAL segment and the secondary server’s last checkpoint, a point in the WAL logs at which all data files have been written to the disk. In other words, the amount of data the primary database sent to the secondary database, which has not been processed by the secondary database. | The difference in size (in KB) between the last received WAL segment and the secondary server’s last checkpoint, a point in the WAL logs at which all data files have been written to the disk. In other words, the amount of data the primary database sent to the secondary database, but which has not been processed by the secondary database. If the value is `none` then the secondary database is up to date. | **base_backup** | Field | Primary Server | Secondary Server | | --- | --- | --- | | **status** | Indicates whether the last base backup was completed successfully: **ok** – Last base backup completed successfully. **failed** – Last base backup failed. **not configured** – Base backup is not configured for this server. This means that continuous archiving was not configured on the server. | Indicates whether the last base backup was completed successfully: **ok** – Last base backup completed successfully. **failed** – Last base backup failed. | | **lastSuccess** | The last time a successful backup was run (in days). If the value is `none`, the `status` field is `ok`, and the last base backup was completed successfully. | The last time a successful backup was run (in days). If the value is `none`, the `status` field is `ok`, and the last base backup was completed successfully. | **wal_archive** | Field | Primary Server | Secondary Server | | --- | --- | --- | | **status** | Indicates whether a WAL was successfully archived in the past hour: **ok** – WAL directory was archived successfully in the past hour. **failed** – WAL directory was not archived in the past hour. This does not indicate a problem. You can change the status to ok, by running a manual command that forces archiving. For more information, contact CTERA support. **not configured** – WAL archiving, that is continuous archiving, is not configured on this server. **Note**: Archiving occurs after 16MB of data has been written or during a system restart. | Indicates whether a WAL was successfully synchronized in the past hour: **ok** – WAL directory was synchronized successfully in the past hour. **failed** – WAL directory was not synchronized in the past hour. | | **lastSuccess** | The last time a WAL log was archived successfully (in hours). If the `status` field's value is `ok`, then `none` is output. | The last time a WAL log was archived successfully (in hours). If the `status` field's value is `ok`, then `none` is output. | 3. Run the following command on the secondary server to view the secondary archive synchronization log: `portal-log.sh replication [-f]` Include the `-f` flag to display the log in the command window. Otherwise, the log is displayed in vim.