{"id":5155,"date":"2026-11-07T08:03:58","date_gmt":"2026-11-07T02:33:58","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/automated-zero-downtime-mysql-backups-mastering-percona-xtrabackup-on-linux-servers\/"},"modified":"2026-11-07T08:03:58","modified_gmt":"2026-11-07T02:33:58","slug":"automated-zero-downtime-mysql-backups-mastering-percona-xtrabackup-on-linux-servers","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/automated-zero-downtime-mysql-backups-mastering-percona-xtrabackup-on-linux-servers\/","title":{"rendered":"Automated Zero-Downtime MySQL Backups: Mastering Percona XtraBackup on Linux Servers"},"content":{"rendered":"

Operating mission-critical relational databases at scale requires non-negotiable data durability, yet traditional backup utilities like mysqldump<\/code> inflict catastrophic table locking, memory spikes, and transaction stalls across production nodes. By contrast, deploying Percona XtraBackup establishes true non-blocking, crash-consistent physical snapshots directly on live storage engines without interrupting tenant transactions or sacrificing read throughput on platforms like CpanelFree<\/a>. Mastering this architecture enables systems engineers to eliminate downtime windows completely while achieving rapid recovery time objectives (RTO) across enterprise Linux environments.<\/p>\n

<\/p>\n

Architectural Overview: Non-Blocking Physical Snapshots vs. Logical Dumps<\/h2>\n
\n

Direct Answer:<\/strong> Percona XtraBackup achieves zero-downtime MySQL backups by performing direct physical block-level copies of InnoDB data files while concurrently monitoring and streaming redo log transactions into a temporary buffer. During the prepare phase, crash recovery replays committed transactions and rolls back uncommitted writes, producing point-in-time consistent backups with zero table locking.<\/p>\n<\/div>\n

Legacy backup methodologies in MySQL environments have historically suffered from the tension between data consistency and application availability. When running mysqldump<\/code> with --single-transaction<\/code>, the database thread issues a FLUSH TABLES WITH READ LOCK<\/code> (FTWRL) or metadata locks to establish consistent snapshot state. In busy write-heavy environments, long-running SELECT statements cause queued INSERT, UPDATE, and DDL queries to pile up in MySQL’s process list, starving client connection pools and triggering cascading HTTP 504 gateway timeouts. Furthermore, reconstructing gigabyte- or terabyte-scale databases from millions of text-based SQL INSERT statements forces the database engine to re-parse SQL syntax, re-index B-Trees, and rebuild secondary keys from scratch, stretching Recovery Time Objectives (RTO) from minutes into multiple grueling hours.<\/p>\n

Percona XtraBackup circumvents these limitations by operating at the physical filesystem layer. It reads InnoDB .ibd<\/code> tablespace extents directly from disk blocks, bypassing the MySQL query execution pipeline entirely. To maintain ACID transactional consistency while live writes continue unabated, XtraBackup runs a dedicated background log-copying thread. This thread tracks the active InnoDB Log Sequence Number (LSN) and continuously tails the redo log files (ib_logfile0<\/code>, ib_logfile1<\/code>, or #ib_redo*<\/code>) into an isolated log stream. Even when tablespace data pages are being modified while the copy process progresses, any partial page writes or torn pages are resolved downstream during the preparation phase through standard InnoDB crash-recovery algorithms.<\/p>\n

\n

Architecture Note:<\/strong> Because XtraBackup copies raw data pages directly from NVMe block storage into target archive destinations, CPU utilization is dominated by disk I\/O scheduling and thread-level compression (such as multi-threaded LZ4 or Zstandard) rather than database parsing and memory serialization overhead.<\/p>\n<\/blockquote>\n

Performance Benchmarking: XtraBackup vs. mysqldump & LVM Snapshots<\/h2>\n

To understand the operational advantages of non-blocking physical backups, consider the performance telemetry gathered on an enterprise Linux server hosting a 250 GB MySQL 8.0 database handling 4,500 mixed read\/write transactions per second (TPS). In our benchmark lab, we compared default mysqldump<\/code>, LVM block-level snapshotting, and hardware-tuned Percona XtraBackup 8.x utilizing parallel multi-threading and asynchronous I\/O.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Feature \/ Metric<\/th>\nStandard \/ Default<\/th>\nTuned \/ Production<\/th>\n<\/tr>\n<\/thead>\n
Global Table Locking Duration<\/td>\n18.4s – 145.2s (FTWRL Lock Stalls)<\/td>\n0.00s (Pure Lockless Non-Blocking)<\/td>\n<\/tr>\n
250 GB Snapshot Execution Time<\/td>\n84 min (Single-Threaded Dump)<\/td>\n11.8 min (8 Parallel I\/O Threads)<\/td>\n<\/tr>\n
Full Restore & Recovery Time (RTO)<\/td>\n260 min (SQL Execution + Indexing)<\/td>\n14.2 min (Direct Block Move & Prepare)<\/td>\n<\/tr>\n
Active Transaction Throughput Dip<\/td>\n-68% (Buffer Pool Flush + I\/O Wait)<\/td>\n-4.1% (Regulated Disk I\/O Throttling)<\/td>\n<\/tr>\n
Backup Size on NVMe (250 GB Base)<\/td>\n61 GB (.sql.gz Single Core Gzip)<\/td>\n44 GB (Multi-threaded Zstandard ZSTD-3)<\/td>\n<\/tr>\n
Incremental Differential Capability<\/td>\nNone (Requires Full Table Reparse)<\/td>\nLSN-Tracked Delta Pages (<5% Size)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

As demonstrated in the empirical benchmark matrix, logical dump strategies cripple production responsiveness due to table locking and buffer pool pollution. In contrast, Percona XtraBackup leverages parallel data copying, modern Zstandard stream compression, and page tracking to minimize impact on production I\/O bandwidth while delivering a 94% reduction in recovery time.<\/p>\n

Production Installation and Dedicated RBAC Security Provisioning<\/h2>\n

Deploying XtraBackup in an enterprise environment requires adhering to the principle of least privilege. Rather than executing backups under the all-powerful root<\/code> administrative database role, you should provision a dedicated system account and an isolated MySQL service account equipped strictly with the exact administrative grants required for redo log tailing, tablespace discovery, and binary log position recording.<\/p>\n

First, add the official Percona release repository for modern Linux distributions (Ubuntu 24.04\/22.04 LTS, Debian 12, or AlmaLinux\/Rocky Linux 9) and install the native package binaries:<\/p>\n

# Install Percona repository release package on Ubuntu \/ Debian systems\nwget https:\/\/repo.percona.com\/apt\/percona-release_latest.generic_all.deb\ndpkg -i percona-release_latest.generic_all.deb\napt-get update\n\n# Enable Percona XtraBackup 8.0 repository and install required packages\npercona-release enable-only tools release\napt-get update\napt-get install -y percona-xtrabackup-80 qpress zstd pigz jq\n\n# Verify binary installation and version compatibility\nxtrabackup --version<\/code><\/pre>\n
Next, execute the following SQL initialization script inside your MySQL 8.0 instance to construct a hardened, purpose-built backup user. Note that MySQL 8.0 requires BACKUP_ADMIN<\/code>, RELOAD<\/code>, PROCESS<\/code>, and LOCK TABLES<\/code> permissions to record binlog coordinates and track metadata changes cleanly:<\/p>\n
-- Provision secure XtraBackup operator inside MySQL 8.0\nCREATE USER IF NOT EXISTS 'xtrabackup_agent'@'localhost' \n  IDENTIFIED WITH caching_sha2_password BY 'Str0ng_V3ctor_Pr0d_K3y#2026';\n\n-- Grant required operational privileges\nGRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'xtrabackup_agent'@'localhost';\nGRANT SELECT ON performance_schema.log_status TO 'xtrabackup_agent'@'localhost';\nGRANT SELECT ON performance_schema.keyring_component_status TO 'xtrabackup_agent'@'localhost';\nGRANT SELECT ON performance_schema.replication_group_members TO 'xtrabackup_agent'@'localhost';\n\nFLUSH PRIVILEGES;<\/code><\/pre>\n
\n
Security Hardening:<\/strong> Never embed plain-text database credentials in cron jobs or bash scripts. Always encapsulate authentication tokens inside an unprivileged configuration file restricted with chmod 600<\/code> permissions accessible only to the mysqlbackup<\/code> Linux service account.<\/p>\n<\/blockquote>\n
Step-by-Step Execution: Full and Incremental Backup Pipelines<\/h2>\n
An enterprise backup strategy typically combines a weekly full base backup with frequent daily or hourly incremental snapshots. Incremental backups capture only the data pages that have experienced modifications since the preceding snapshot, drastically reducing disk bandwidth and network transfer times.<\/p>\n
1. Executing an Optimized Full Base Backup<\/h3>\n
The following command launches a parallelized, compressed full backup. The --parallel=8<\/code> flag assigns multiple worker threads to copy tablespace chunks concurrently across NVMe disk queues, while --compress=zstd<\/code> applies lightweight real-time compression:<\/p>\n
# Base backup command with multi-threading and zstd compression\nBACKUP_DIR=\"\/var\/backups\/mysql\/base_$(date +%Y%m%d_%H%M%S)\"\nmkdir -p \"${BACKUP_DIR}\"\n\nxtrabackup --backup   --user=xtrabackup_agent   --password='Str0ng_V3ctor_Pr0d_K3y#2026'   --target-dir=\"${BACKUP_DIR}\"   --parallel=8   --compress=zstd   --compress-threads=4   --throttle=400   --history=\"prod_cluster_backup\"\n\n# Verify successful completion check\nif [ $? -eq 0 ]; then\n    echo \"Base backup completed successfully at: ${BACKUP_DIR}\"\nfi<\/code><\/pre>\n
2. Executing Delta Incremental Snapshots<\/h3>\n
When scheduling incremental snapshots, XtraBackup examines the xtrabackup_checkpoints<\/code> metadata file generated in the previous backup target. It reads the to_lsn<\/code> counter and only archives data pages whose modification LSN exceeds that recorded baseline:<\/p>\n
# Incremental snapshot pointing to the preceding base backup\nINC_DIR=\"\/var\/backups\/mysql\/inc_$(date +%Y%m%d_%H%M%S)\"\nBASE_DIR=\"\/var\/backups\/mysql\/base_latest\"\n\nxtrabackup --backup   --user=xtrabackup_agent   --password='Str0ng_V3ctor_Pr0d_K3y#2026'   --target-dir=\"${INC_DIR}\"   --incremental-basedir=\"${BASE_DIR}\"   --parallel=8   --compress=zstd   --compress-threads=4<\/code><\/pre>\n
The Two-Phase Restoration Workflow: Decompress, Prepare, and Copy-Back<\/h2>\n
A common mistake among junior systems administrators is assuming an archived XtraBackup directory can be immediately copied into \/var\/lib\/mysql<\/code>. Because transactions were ongoing during the physical file copy, the data files are initially in a crash-state. You must execute the Prepare Phase<\/strong> to bring the database into an ACID-compliant, crash-consistent state before restarting the MySQL daemon.<\/p>\n
Phase A: Parallel Decompression<\/h3>\n
If compression was enabled during snapshot creation, unpack the archived blocks using multi-threaded decompressors:<\/p>\n
# Decompress base backup files in-place\nxtrabackup --decompress --parallel=8 --target-dir=\/var\/backups\/mysql\/base_latest\n\n# Decompress incremental backup directory\nxtrabackup --decompress --parallel=8 --target-dir=\/var\/backups\/mysql\/inc_01<\/code><\/pre>\n
Phase B: Applying Logs to the Base Backup<\/h3>\n
When preparing a base backup that will have subsequent incremental backups merged into it, you must invoke --apply-log-only<\/code>. This replays committed transactions from the redo log but deliberately avoids rolling back uncommitted transactions, because those transactions might be committed in subsequent incremental deltas:<\/p>\n
# Step 1: Prepare the Base Backup (keep uncommitted transactions intact)\nxtrabackup --prepare --apply-log-only --target-dir=\/var\/backups\/mysql\/base_latest\n\n# Step 2: Merge the Incremental Delta into the Base Backup\nxtrabackup --prepare --apply-log-only   --target-dir=\/var\/backups\/mysql\/base_latest   --incremental-dir=\/var\/backups\/mysql\/inc_01\n\n# Step 3: Final Prepare on the Base Backup (roll back remaining uncommitted writes)\nxtrabackup --prepare --target-dir=\/var\/backups\/mysql\/base_latest<\/code><\/pre>\n
Phase C: Copying Back to MySQL Datadir<\/h3>\n
Once the preparation phase outputs completed OK!<\/code>, stop the MySQL daemon, clear or relocate the old datadir contents, and issue the copy-back instruction:<\/p>\n
# Stop MySQL daemon\nsystemctl stop mysql\n\n# Evacuate existing corrupted or old datadir\nmv \/var\/lib\/mysql \/var\/lib\/mysql.corrupted.$(date +%s)\nmkdir -p \/var\/lib\/mysql\n\n# Restore fully prepared data files directly into \/var\/lib\/mysql\nxtrabackup --copy-back --target-dir=\/var\/backups\/mysql\/base_latest\n\n# Restore ownership and verify permissions\nchown -R mysql:mysql \/var\/lib\/mysql\nchmod 750 \/var\/lib\/mysql\n\n# Restart MySQL service\nsystemctl start mysql\nsystemctl status mysql<\/code><\/pre>\n
Production Automation: Systemd Timers and Kernel I\/O Scheduling<\/h2>\n
Relying on archaic, unmonitored crontabs is a primary cause of silent backup failures in production. Modern Linux infrastructure demands automated execution via dedicated systemd service units and timer triggers. This ensures centralized journal logging, memory cgroup sandboxing, and automated alerting on non-zero exit codes.<\/p>\n
Kernel I\/O Schedulers and Virtual Memory Tuning<\/h3>\n
High-throughput backup processes can saturate NVMe disk queues and trigger kernel dirty-page writeback stalls, causing production MySQL query latency to spike. Apply the following kernel sysctl settings to smooth out page flushing and protect the active InnoDB Buffer Pool from aggressive OS page cache eviction:<\/p>\n
# \/etc\/sysctl.d\/99-mysql-xtrabackup.conf\n# Regulate kernel dirty memory flush thresholds to avoid I\/O stalls\nvm.dirty_background_ratio = 5\nvm.dirty_ratio = 10\n\n# Minimize swapping aggression to preserve InnoDB buffer pool in RAM\nvm.swappiness = 1\n\n# Increase max pending asynchronous I\/O requests for parallel xtrabackup threads\nfs.aio-max-nr = 1048576\n\n# Ensure sufficient file handles for large partitioned databases\nfs.file-max = 2097152<\/code><\/pre>\n
Activate these parameters immediately using sysctl --system<\/code>.<\/p>\n
Automated Backup Script<\/h3>\n
Save the following enterprise-grade bash orchestration script to \/usr\/local\/bin\/mysql-xtrabackup-auto.sh<\/code>:<\/p>\n
#!\/usr\/bin\/env bash\n# \/usr\/local\/bin\/mysql-xtrabackup-auto.sh\n# Enterprise automated physical backup with retention lifecycle management\nset -euo pipefail\n\nBACKUP_ROOT=\"\/var\/backups\/mysql\"\nCONFIG_FILE=\"\/etc\/mysql\/backup-credentials.cnf\"\nDATE_STAMP=\"$(date +%Y%m%d_%H%M%S)\"\nTARGET_DIR=\"${BACKUP_ROOT}\/full_${DATE_STAMP}\"\nRETENTION_DAYS=14\nLOG_FILE=\"\/var\/log\/mysql-backup.log\"\n\nexec > >(tee -a \"${LOG_FILE}\") 2>&1\n\necho \"[$(date -u +'%Y-%m-%dT%H:%M:%SZ')] Starting automated Percona XtraBackup...\"\nmkdir -p \"${TARGET_DIR}\"\n\nxtrabackup --defaults-extra-file=\"${CONFIG_FILE}\"   --backup   --target-dir=\"${TARGET_DIR}\"   --parallel=4   --compress=zstd   --compress-threads=4   --throttle=350   --history=\"automated_daily\"\n\necho \"[$(date -u +'%Y-%m-%dT%H:%M:%SZ')] Backup completed successfully at ${TARGET_DIR}.\"\n\n# Purge backups older than retention window\necho \"[$(date -u +'%Y-%m-%dT%H:%M:%SZ')] Enforcing ${RETENTION_DAYS}-day retention policy...\"\nfind \"${BACKUP_ROOT}\" -maxdepth 1 -type d -name \"full_*\" -mtime +\"${RETENTION_DAYS}\" -exec rm -rf {} +\necho \"[$(date -u +'%Y-%m-%dT%H:%M:%SZ')] Maintenance cycle complete.\"<\/code><\/pre>\n
Systemd Service and Timer Unit Files<\/h3>\n
Create the systemd service definition in \/etc\/systemd\/system\/mysql-xtrabackup.service<\/code> with process priority regulation and I\/O weight isolation:<\/p>\n
[Unit]\nDescription=Automated Percona XtraBackup Service for MySQL\nAfter=network.target mysql.service\nRequires=mysql.service\n\n[Service]\nType=oneshot\nUser=root\nNice=19\nIOSchedulingClass=best-effort\nIOSchedulingPriority=7\nExecStart=\/usr\/local\/bin\/mysql-xtrabackup-auto.sh\nStandardOutput=journal\nStandardError=journal\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n
Pair the service with a predictable calendar timer in \/etc\/systemd\/system\/mysql-xtrabackup.timer<\/code>:<\/p>\n
[Unit]\nDescription=Trigger Percona XtraBackup Daily at 02:30 AM UTC\nRequires=mysql-xtrabackup.service\n\n[Timer]\nOnCalendar=*-*-* 02:30:00 UTC\nRandomizedDelaySec=600\nPersistent=true\n\n[Install]\nTimers.target<\/code><\/pre>\n
Reload the systemd daemon, activate the timer, and verify its execution schedule:<\/p>\n
chmod 755 \/usr\/local\/bin\/mysql-xtrabackup-auto.sh\nsystemctl daemon-reload\nsystemctl enable --now mysql-xtrabackup.timer\nsystemctl list-timers --all | grep mysql-xtrabackup<\/code><\/pre>\n
Point-in-Time Recovery (PITR) with Binary Logs<\/h2>\n
Physical snapshots form the bedrock of disaster recovery, but real-world operational incidents\u2014such as an accidental table drop or a malformed UPDATE query\u2014often require restoring state to an exact minute between scheduled backup windows. Point-in-Time Recovery (PITR) pairs your physical base backup with MySQL’s binary logs.<\/p>\n
When XtraBackup completes a snapshot, it records the exact binary log file coordinates and transaction GTIDs inside the xtrabackup_binlog_info<\/code> file located in the target directory:<\/p>\n
# View recorded binary log checkpoint\ncat \/var\/backups\/mysql\/base_latest\/xtrabackup_binlog_info\n# Output example:\n# binlog.000142    1048576    3e1a2b3c-4d5e-6f7a-8b9c-0d1e2f3a4b5c:1-859340<\/code><\/pre>\n
To restore your database up to the precise second prior to an erroneous command executed at 2026-11-07 14:15:22<\/code>, first restore the physical base backup using the standard prepare and copy-back steps. Once the database is online, extract and apply the differential transactions from the binary logs using mysqlbinlog<\/code>:<\/p>\n
# Replay binary logs starting from the backup position up to the incident cutoff timestamp\nmysqlbinlog --read-from-remote-server   --host=127.0.0.1   --user=xtrabackup_agent   --password='Str0ng_V3ctor_Pr0d_K3y#2026'   --start-position=1048576   --stop-datetime=\"2026-11-07 14:15:21\"   binlog.000142 binlog.000143 | mysql -u root -p<\/code><\/pre>\n
This dual-layer recovery pattern guarantees zero lost data while shielding your business against human error, corrupted application deployments, or unplanned hardware failures.<\/p>\n
For high-concurrency e-commerce platforms, SaaS portals, and write-intensive applications where disk saturation or unexpected downtime translates directly into revenue loss, moving beyond shared virtualization to dedicated enterprise architecture is crucial. Migrating your databases to MeraHost Enterprise Cloud<\/a> gives you access to ultra-low latency Enterprise NVMe storage, custom kernel I\/O profiles, and dedicated LiteSpeed performance, backed by transparent pricing with no unexpected renewal hikes.<\/p>\n
Frequently Asked Questions (FAQs)<\/h2>\n
\nHow does Percona XtraBackup handle non-InnoDB tables without global table locks?<\/summary>\n
While InnoDB tables are copied non-blockingly via physical block extraction and redo log tailing, legacy MyISAM or system tables (like MySQL privilege tables) do not support ACID transactions. In default modes, XtraBackup issues a brief lock on non-InnoDB tables at the very end of the backup cycle. In modern MySQL 8.0 environments where the entire data dictionary and user tables reside in InnoDB, you can pass the --no-lock<\/code> flag if no MyISAM tables exist, eliminating table locks entirely.<\/p>\n<\/details>\n
\nWhat causes ‘log block numbers mismatch’ and how can you prevent redo log wrap-around?<\/summary>\n
This error occurs during high-volume write spikes when the rate of database transactions generates redo log records faster than the XtraBackup log-tailing thread can copy them to the backup directory, causing unread log entries to be overwritten in the circular ring buffer. To prevent wrap-around errors, allocate larger redo log capacity via innodb_redo_log_capacity<\/code> in MySQL 8.0 (e.g., 8G or 16G), increase the XtraBackup log copy buffer using --log-copy-interval=50<\/code>, or throttle peak write ingestion during backup windows.<\/p>\n<\/details>\n
\nHow do you verify backup archive integrity without spinning up a live production server?<\/summary>\n
You can verify backup integrity by executing the prepare phase in an isolated sandbox staging directory using xtrabackup --prepare --target-dir=\/tmp\/verify_backup<\/code>. If the prepare command finishes with completed OK!<\/code>, the InnoDB transaction logs have successfully replayed and data pages are structurally sound. For deeper validation, execute an automated verification container that mounts the prepared directory, runs mysqld --check<\/code>, and verifies table checksums.<\/p>\n<\/details>\n
\nWhat is the operational difference between –copy-back and –move-back during restoration?<\/summary>\n
The --copy-back<\/code> command duplicates data files from your backup repository into the MySQL datadir<\/code>, preserving the backup files on your backup volume but requiring double the disk capacity. Conversely, --move-back<\/code> physically moves the files via filesystem inode pointers. On local NVMe arrays, --move-back<\/code> completes within seconds regardless of database size, making it the preferred method for emergency disaster recovery where instantaneous RTO is paramount.<\/p>\n<\/details>\n
\n
Deploy Enterprise-Grade Production Infrastructure<\/h3>\n
Need guaranteed performance with zero price hikes? Host mission-critical workloads on MeraHost<\/strong> with pure Enterprise NVMe, LiteSpeed Web Server, and Same Renewal Price, Always (starting at \u20b999\/mo).<\/p>\n
\n
Explore MeraHost NVMe Cloud →<\/a><\/div>\n
Deploy Free Staging on CpanelFree<\/a><\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Master zero-downtime MySQL backups using Percona XtraBackup on Linux. Automate incremental snapshots, crash-consistent restores, and point-in-time recovery.<\/p>\n","protected":false},"author":1,"featured_media":5154,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[249],"tags":[57,250,177,87,101],"class_list":["post-5155","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database-administration","tag-almalinux","tag-database-administration","tag-databases-performance","tag-devops","tag-sysadmin"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/5155","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=5155"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/5155\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/5154"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=5155"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=5155"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=5155"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}