{"id":5789,"date":"2026-09-29T11:44:04","date_gmt":"2026-09-29T08:44:04","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5789"},"modified":"2026-09-29T06:17:32","modified_gmt":"2026-09-29T03:17:32","slug":"expand-cloud-server-disk-partition-filesystem","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/expand-cloud-server-disk-partition-filesystem\/","title":{"rendered":"Expanding Cloud Server Disks: Partition and Filesystem Steps"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div class=\"aiw-summary\">\n<p class=\"aiw-box-title\">Quick summary<\/p>\n<p>Expanding a cloud server disk in the provider panel does not always expand the partition or filesystem inside Linux. First confirm that the operating system sees the new disk size, then extend each storage layer in order.<\/p>\n<ul>\n<li>Prepare a current backup, snapshot, or provider-supported rollback option before changing partitions or LVM.<\/li>\n<li>Use <code>lsblk<\/code>, <code>findmnt<\/code>, and <code>df -hT<\/code> to map the disk, partition, logical volume, and filesystem.<\/li>\n<li>For LVM, the usual sequence is partition, physical volume, logical volume, and filesystem.<\/li>\n<li>Use <code>resize2fs<\/code> for ext4 and <code>xfs_growfs<\/code> for XFS. XFS cannot be reduced.<\/li>\n<li>Measure capacity after every layer; the size shown in the cloud panel is not the same as application-usable space.<\/li>\n<\/ul>\n<\/div>\n<p>You increased the disk size in your cloud panel, but <code>df -h<\/code> still reports the old capacity. This usually means that only the virtual disk grew while the Linux partition, LVM structure, or filesystem still has its previous size.<\/p>\n<p>A typical virtual disk has several layers: the virtual disk supplied by the cloud provider, a partition inside the operating system, an optional LVM physical volume (PV) and logical volume (LV), and a filesystem such as ext4 or XFS. The panel changes the first layer. You may need to expand the remaining layers from inside the server.<\/p>\n<p>This guide covers common Linux layouts with LVM and direct ext4 or XFS partitions. Device names in the commands are examples. Do not copy a device name until your own output confirms that it is the correct disk or partition.<\/p>\n<div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_does_the_disk_grow_but_free_space_not_increase\"><span class=\"toc_number toc_depth_1\">1.<\/span> Why does the disk grow but free space not increase?<\/a><\/li><li><a href=\"#Check_the_layout_and_prerequisites_first\"><span class=\"toc_number toc_depth_1\">2.<\/span> Check the layout and prerequisites first<\/a><\/li><li><a href=\"#Expand_a_cloud_server_disk_with_LVM\"><span class=\"toc_number toc_depth_1\">3.<\/span> Expand a cloud server disk with LVM<\/a><ul><li><a href=\"#Expand_the_physical_partition\"><span class=\"toc_number toc_depth_2\">3.1.<\/span> Expand the physical partition<\/a><\/li><li><a href=\"#Expand_the_PV_and_LV\"><span class=\"toc_number toc_depth_2\">3.2.<\/span> Expand the PV and LV<\/a><\/li><li><a href=\"#Grow_and_verify_the_filesystem\"><span class=\"toc_number toc_depth_2\">3.3.<\/span> Grow and verify the filesystem<\/a><\/li><\/ul><\/li><li><a href=\"#Expand_a_direct_ext4_partition_without_LVM\"><span class=\"toc_number toc_depth_1\">4.<\/span> Expand a direct ext4 partition without LVM<\/a><\/li><li><a href=\"#Use_the_correct_growth_command_for_XFS\"><span class=\"toc_number toc_depth_1\">5.<\/span> Use the correct growth command for XFS<\/a><\/li><li><a href=\"#Verify_the_result_and_plan_rollback\"><span class=\"toc_number toc_depth_1\">6.<\/span> Verify the result and plan rollback<\/a><\/li><li><a href=\"#Frequently_Asked_Questions\"><span class=\"toc_number toc_depth_1\">7.<\/span> Frequently Asked Questions<\/a><ul><li><a href=\"#Can_I_expand_the_disk_without_rebooting\"><span class=\"toc_number toc_depth_2\">7.1.<\/span> Can I expand the disk without rebooting?<\/a><\/li><li><a href=\"#Why_did_du_not_change_after_the_disk_expansion\"><span class=\"toc_number toc_depth_2\">7.2.<\/span> Why did du not change after the disk expansion?<\/a><\/li><li><a href=\"#Should_I_assign_all_free_space_to_the_root_LV\"><span class=\"toc_number toc_depth_2\">7.3.<\/span> Should I assign all free space to the root LV?<\/a><\/li><li><a href=\"#Does_the_application_need_to_restart_after_the_filesystem_grows\"><span class=\"toc_number toc_depth_2\">7.4.<\/span> Does the application need to restart after the filesystem grows?<\/a><\/li><\/ul><\/li><li><a href=\"#Actionable_checklist\"><span class=\"toc_number toc_depth_1\">8.<\/span> Actionable checklist<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_does_the_disk_grow_but_free_space_not_increase\">Why does the disk grow but free space not increase?<\/span><\/h2>\n<p>The visible symptom is a larger disk size in the panel while the root filesystem remains unchanged in <code>df -hT<\/code>. The kernel may still report the old disk size, the partition table may not include the newly available space, or the filesystem may still occupy its previous size.<\/p>\n<p>A filesystem does not automatically use every block on the device beneath it. For example, the virtual disk <code>\/dev\/sda<\/code> may grow from 100 GB to 150 GB while <code>\/dev\/sda3<\/code> remains 100 GB. The filesystem then cannot use the additional 50 GB.<\/p>\n<p>The chain is longer with LVM. New space must move from the disk to the partition, then to the PV, volume group (VG), and LV. The filesystem is expanded last. If you skip a layer, capacity remains unavailable at the next layer.<\/p>\n<div class=\"aiw-note aiw-note-warning\">\n<p class=\"aiw-box-title\">Caution<\/p>\n<p>Partition and LVM commands can cause data loss when applied to the wrong device. Before working on a production server, prepare a backup, snapshot, or provider-supported rollback option. Confirm in advance that you can actually restore the backup or revert to the snapshot.<\/p>\n<\/div>\n<h2><span id=\"Check_the_layout_and_prerequisites_first\">Check the layout and prerequisites first<\/span><\/h2>\n<p>These procedures assume a Linux server with root or <code>sudo<\/code> access. The command names and package availability vary by distribution. The examples use standard tools commonly found on current Debian, Ubuntu, and RHEL-compatible systems; check your distribution documentation before installing a missing tool. Online filesystem growth also depends on the filesystem, kernel, distribution, and storage infrastructure.<\/p>\n<p>Keep your SSH session open and, if possible, prepare a separate management session. Low space on the root filesystem can affect package installation and log writing. Reduce critical write activity and schedule data-changing steps within an appropriate maintenance window.<\/p>\n<p>The following commands only read information. They show whether the operating system sees the new capacity, which partition is mounted, and which filesystem is in use. The LVM commands require the relevant LVM tools, usually provided by an <code>lvm2<\/code> package.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS\nfindmnt -no SOURCE,FSTYPE,TARGET \/\ndf -hT\nsudo pvs\nsudo vgs\nsudo lvs<\/code><\/pre>\n<p>When LVM is not installed or not in use, <code>pvs<\/code>, <code>vgs<\/code>, and <code>lvs<\/code> may return an error or no output. That is not automatically a problem. If <code>findmnt<\/code> shows a source such as <code>\/dev\/sda3<\/code>, you likely have a direct-partition layout. A source in the form <code>\/dev\/mapper\/...<\/code> usually indicates LVM.<\/p>\n<p>If <code>lsblk<\/code> still shows the old size for the main disk after the panel operation, do not run partition or filesystem commands yet. Check that the provider operation has completed, whether the virtual disk supports online expansion, and whether a reboot or provider-specific rescan is required. If a reboot is necessary, assess its effect on the application first.<\/p>\n<p>If the disk has the new size but the last partition is still smaller, and unallocated space follows it immediately, you may only need to expand that partition. Save the <code>lsblk<\/code> and <code>findmnt<\/code> output before changing the partition table. If the target is not the last partition, or another partition lies after it, <code>growpart<\/code> may not produce the expected result.<\/p>\n<div class=\"aiw-note aiw-note-example\">\n<p class=\"aiw-box-title\">Example scenario<\/p>\n<p>Assume a panel operation changes a virtual disk from 100 GB to 200 GB. <code>lsblk<\/code> shows <code>\/dev\/sda<\/code> at 200 GB, but the root partition <code>\/dev\/sda3<\/code> remains 100 GB. In this constructed scenario, first confirm that unallocated space directly follows the partition, then expand the partition. Run the ext4 or XFS growth command only after checking the new partition size.<\/p>\n<\/div>\n<h2><span id=\"Expand_a_cloud_server_disk_with_LVM\">Expand a cloud server disk with LVM<\/span><\/h2>\n<p>LVM makes it easier to allocate disk capacity between logical volumes, but it adds storage layers. Assume, for illustration, that the root filesystem is on <code>\/dev\/mapper\/ubuntu--vg-ubuntu--lv<\/code> and the LVM partition is <code>\/dev\/sda3<\/code>. Your names may be different.<\/p>\n<h3><span id=\"Expand_the_physical_partition\">Expand the physical partition<\/span><\/h3>\n<p>If <code>lsblk<\/code> shows that the main disk grew while the LVM partition did not, expand the partition. Debian- and Ubuntu-based systems can use <code>growpart<\/code>. Check whether it is available:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">command -v growpart<\/code><\/pre>\n<p>If the command is missing, install <code>cloud-guest-utils<\/code> or the equivalent package through your distribution&#8217;s package manager. Package names vary by distribution. Installing a package may require repository access and free space, so confirm that your backup and rollback plan is ready first.<\/p>\n<p>After verifying the disk and partition number against your own <code>lsblk<\/code> output, run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo growpart \/dev\/sda 3\nlsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS<\/code><\/pre>\n<p>Here, <code>\/dev\/sda<\/code> is the disk and <code>3<\/code> is the partition number. Do not continue if the partition did not reach the expected size. GPT layouts or custom partition arrangements may require a different tool or sequence; when the layout is unclear, follow the documentation for your distribution and provider.<\/p>\n<h3><span id=\"Expand_the_PV_and_LV\">Expand the PV and LV<\/span><\/h3>\n<p>After the partition grows, the LVM physical volume may still have its old size. Check whether LVM can see the additional space with <code>pvs<\/code> and <code>pvdisplay<\/code>. If the PV is <code>\/dev\/sda3<\/code>, for example:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo pvresize \/dev\/sda3\nsudo pvs\nsudo vgs<\/code><\/pre>\n<p>Free space in the <code>vgs<\/code> output means that the volume group has capacity available. Decide which logical volume should receive it before running <code>lvextend<\/code>. If several LVs exist, assigning all free space to the wrong one can affect the application&#8217;s storage arrangement.<\/p>\n<p>To add a specific amount, such as 40 GB:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo lvextend -L +40G \/dev\/mapper\/ubuntu--vg-ubuntu--lv<\/code><\/pre>\n<p>To assign all free space in the volume group to this LV:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo lvextend -l +100%FREE \/dev\/mapper\/ubuntu--vg-ubuntu--lv<\/code><\/pre>\n<p>These commands enlarge the logical volume. The filesystem may not grow automatically in every configuration. Some systems allow <code>lvextend -r<\/code> to call the filesystem resize operation as well, but handling the layers separately makes each result easier to verify and gives you more control during a production change.<\/p>\n<p>After either command, check <code>lvs<\/code> before resizing the filesystem. If the LV did not reach the intended size, stop and investigate rather than proceeding with an incorrect device.<\/p>\n<h3><span id=\"Grow_and_verify_the_filesystem\">Grow and verify the filesystem<\/span><\/h3>\n<p>For ext4, use <code>resize2fs<\/code> after the logical volume has grown. A mounted root filesystem can usually be expanded online, subject to the kernel and storage environment:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo resize2fs \/dev\/mapper\/ubuntu--vg-ubuntu--lv\ndf -hT\nlsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS<\/code><\/pre>\n<p>For XFS, specify the mounted path rather than the source device. For the root filesystem:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo xfs_growfs \/\ndf -hT\nlsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS<\/code><\/pre>\n<p>The <code>xfs_growfs<\/code> command is supplied by the <code>xfsprogs<\/code> package on many distributions. XFS growth is performed on the mounted filesystem. XFS cannot be reduced, so define your capacity plan before allocating more space than the application needs. Reducing ext4 is also a different and generally riskier operation that often requires the filesystem to be unmounted. The steps here are for expansion only.<\/p>\n<p>Review three outputs together: <code>pvs<\/code> for the PV, <code>lvs<\/code> for the LV, and <code>df -hT<\/code> for the mounted filesystem. If the first two layers grew but <code>df<\/code> did not, the filesystem step is the missing layer. If <code>df<\/code> changed but the application still cannot use the space, investigate inode usage, quotas, or application-specific storage limits.<\/p>\n<h2><span id=\"Expand_a_direct_ext4_partition_without_LVM\">Expand a direct ext4 partition without LVM<\/span><\/h2>\n<p>If ext4 is installed directly on a partition, you do not need LVM commands. Confirm that the main disk grew and that the filesystem partition is adjacent to unallocated space at the end of the disk. In this example, the root filesystem is <code>\/dev\/sda3<\/code> on <code>\/dev\/sda<\/code>.<\/p>\n<p>Expand the partition with <code>growpart<\/code>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo growpart \/dev\/sda 3\nlsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS<\/code><\/pre>\n<p>After confirming the partition size, expand the ext4 filesystem:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo resize2fs \/dev\/sda3\ndf -hT<\/code><\/pre>\n<p>The direct device is used here because the filesystem is not on LVM. Your <code>findmnt<\/code> output may show <code>\/dev\/vda1<\/code>, <code>\/dev\/nvme0n1p1<\/code>, or another device. NVMe partition names use a different format, so do not treat <code>\/dev\/sda3<\/code> as a default.<\/p>\n<p>Growing a mounted filesystem is possible in most ext4 installations, but behavior can vary with the kernel, distribution, and storage infrastructure. If <code>resize2fs<\/code> fails, record the error instead of repeatedly running the command. Confirm that the device is ext4 and that the partition is larger than the filesystem. If offline maintenance is required, stop the application and use a recovery environment or planned maintenance procedure.<\/p>\n<h2><span id=\"Use_the_correct_growth_command_for_XFS\">Use the correct growth command for XFS<\/span><\/h2>\n<p>A common mistake on XFS systems is running <code>resize2fs<\/code>. That tool is for ext filesystems. Use <code>xfs_growfs<\/code> after confirming the type:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">findmnt -no SOURCE,FSTYPE,TARGET \/\ndf -hT \/<\/code><\/pre>\n<p>For XFS directly on a partition, expand the partition first, verify it, and then grow the mounted filesystem:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo growpart \/dev\/sda 3\nlsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS\nsudo xfs_growfs \/\ndf -hT \/<\/code><\/pre>\n<p>This example applies only when the root filesystem is on <code>\/dev\/sda3<\/code> and mounted at <code>\/<\/code>. If XFS is mounted at a data path such as <code>\/var\/lib<\/code>, use <code>\/var\/lib<\/code> in the final command. With LVM, expand the relevant partition, PV, and LV first; run <code>xfs_growfs<\/code> only after the LV has its new size.<\/p>\n<p>Make sure the target mount point is mounted before growing XFS. Afterward, use <code>df -hT<\/code> to check the filesystem size. You can also perform a small, controlled write test in the directory used by the application, then remove the test data and avoid changing application permissions.<\/p>\n<div class=\"aiw-note aiw-note-tip\">\n<p class=\"aiw-box-title\">Tip<\/p>\n<p>Disk capacity and filesystem capacity are different measurements. Use <code>lsblk<\/code> for disks and partitions, <code>pvs<\/code>\/<code>lvs<\/code> for LVM, and <code>df -hT<\/code> for mounted filesystems. Reading these levels together identifies where the expansion stopped.<\/p>\n<\/div>\n<h2><span id=\"Verify_the_result_and_plan_rollback\">Verify the result and plan rollback<\/span><\/h2>\n<p>Do not rely only on the size shown in the cloud panel. These checks show whether each layer sees the new capacity and whether the mounted filesystem gained usable space:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS\ndf -hT\nfindmnt -no SOURCE,FSTYPE,TARGET \/\nsudo pvs 2&gt;\/dev\/null\nsudo vgs 2&gt;\/dev\/null\nsudo lvs 2&gt;\/dev\/null<\/code><\/pre>\n<p>If the new capacity is visible but free space is lower than expected, check whether deleted files are still held open by running processes. That issue is separate from disk expansion. Also check inode usage with <code>df -ih<\/code>, and inspect <code>vgs<\/code> for unallocated space in the volume group. Application quotas or internal storage settings may prevent the application from using operating-system space.<\/p>\n<p>Changes to partition or LVM sizes generally do not shrink existing capacity. If you expanded the wrong LV, reversing the change depends on the filesystem type and how much space is in use. XFS cannot be reduced. For that reason, rollback often means reverting to a pre-change snapshot or restoring the backup to another disk. Do not attempt a reduction as an improvised rollback.<\/p>\n<p>If SSH disconnects during the procedure, do not blindly rerun every command. Reconnect and collect <code>lsblk<\/code>, <code>pvs<\/code>, <code>lvs<\/code>, and <code>df -hT<\/code> first. If one step completed, perform only the missing layer. A command having run previously does not make a wrong device selection safe.<\/p>\n<h2><span id=\"Frequently_Asked_Questions\">Frequently Asked Questions<\/span><\/h2>\n<h3><span id=\"Can_I_expand_the_disk_without_rebooting\">Can I expand the disk without rebooting?<\/span><\/h3>\n<p>Many virtual disk platforms support online disk and filesystem expansion. Whether the new size is detected without a reboot depends on the provider, operating system, and disk type. If <code>lsblk<\/code> still reports the old size, a planned reboot or the provider&#8217;s rescan procedure may be required.<\/p>\n<h3><span id=\"Why_did_du_not_change_after_the_disk_expansion\">Why did <code>du<\/code> not change after the disk expansion?<\/span><\/h3>\n<p><code>du<\/code> totals space used by existing files in directories; it does not report unused capacity. Use <code>df -hT<\/code> for available filesystem space and <code>lsblk<\/code> for disk and partition sizes.<\/p>\n<h3><span id=\"Should_I_assign_all_free_space_to_the_root_LV\">Should I assign all free space to the root LV?<\/span><\/h3>\n<p>No. If separate LVs hold databases, logs, or user files, consider their future needs before using <code>+100%FREE<\/code>. Use that option only when you deliberately want all VG free space assigned to the selected LV.<\/p>\n<h3><span id=\"Does_the_application_need_to_restart_after_the_filesystem_grows\">Does the application need to restart after the filesystem grows?<\/span><\/h3>\n<p>A capacity increase alone usually does not require an application restart. An application that caches quota or storage information may need its own refresh procedure, but that is separate from filesystem expansion. CLI queue workers also do not occupy PHP-FPM workers unless they make HTTP requests; do not treat a queue process as part of this disk-resize procedure.<\/p>\n<h2><span id=\"Actionable_checklist\">Actionable checklist<\/span><\/h2>\n<ul>\n<li>Confirm that the panel operation completed and check whether a reboot or provider rescan is required.<\/li>\n<li>Verify that the backup or snapshot can actually be restored.<\/li>\n<li>Map the layout with <code>lsblk<\/code>, <code>findmnt<\/code>, and <code>df -hT<\/code>.<\/li>\n<li>Do not run partition or filesystem commands while the disk still shows its old size.<\/li>\n<li>Confirm that unallocated space directly follows the target partition.<\/li>\n<li>With LVM, preserve the order: partition, PV, LV, then filesystem.<\/li>\n<li>Use <code>resize2fs<\/code> for ext4 and <code>xfs_growfs<\/code> for XFS.<\/li>\n<li>Measure capacity after every layer and recheck the device name.<\/li>\n<li>Perform a safe verification at the mount point used by the application.<\/li>\n<li>Keep the pre-change snapshot or backup until the application has been checked.<\/li>\n<\/ul>\n<p>Your next step is to collect the read-only command output from the server and identify the correct layout. Do not run a partition or LVM command until that output confirms the target device. If you are also planning capacity for IOPS and inode usage, review <a href=\"https:\/\/www.dchost.com\/blog\/en\/what-is-a-cloud-server\/\">What is a Cloud Server?<\/a> and the related disk, IOPS and inode planning guidance before choosing the next disk size.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>A cloud panel disk increase may not expand Linux partitions or filesystems. Follow the correct diagnostic and growth steps for LVM, ext4 and XFS.<\/p>\n","protected":false},"author":4,"featured_media":5786,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[176],"tags":[626,627,623,60,622,628,624],"class_list":["post-5789","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-computing","tag-cloud-server","tag-disk-expansion","tag-ext4","tag-linux","tag-lvm","tag-server-administration","tag-xfs"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5789"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5789\/revisions"}],"predecessor-version":[{"id":5791,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5789\/revisions\/5791"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5786"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}