For more information, see Use Cases.
Before you select a disk type, determine the use case:
fstab, use the UUID or label of the file system as the file system ID, so that the device name remains unchanged on the CVM when any cloud disk is unmounted and then remounted.
nofailoption to configure
fstab, so there will be no error when you restart the CVM after unmounting the cloud disk.
diskpartbefore using the cloud disk in Windows.
For more information, see the automatic mounting section in Mounting Cloud Disks.
You can create cloud disks via the Console or API. For more information, see Creating Cloud Disks.
For more information, see Operation Overview.
Cloud disks cannot be mounted across availability zones. Please ensure that the CVM instance and cloud disk are in the same availability zone of the same region. Please also ensure that the CVM has not been released.
Some Linux CVMs may not recognize the elastic cloud disk. You must first enable the disk hot swapping function in the CVM. For more information, see Enabling the disk hot swapping function.
After manually mounting a cloud disk, you must select and perform the subsequent operations to make it usable.
|Creation mode||Cloud disk capacity||Subsequent operations|
|Create directly||Cloud disk capacity < 2TB||Initializing cloud disks (smaller than 2TB)|
|Cloud disk capacity ≥ 2TB||Initializing cloud disks (larger than or equal to 2TB)|
|Create from a snapshot||Cloud disk capacity = Snapshot capacity||
|Snapshot capacity < cloud disk capacity ≤ 2TB
2TB < snapshot capacity < cloud disk capacity
|Snapshot capacity ≤ 2TB < cloud disk capacity||
A new data disk or data disk partition cannot be used until being formatted and recording the data structure. Formatting the disk is to establish a file system on and writes data in the data disk. The write-in data size varies by the file systems:
Yes. To do this, follow the directions below:
If the mount point is
umount <Mount point>
/data, then run the following command:
If it returns null, all file systems have been unmounted from partitions on the cloud disk.
mount | grep '<Disk path>'
No. You can mount up to 20 cloud disks to the same CVM, but you cannot mount the same cloud disk to multiple CVMs. You can only share data by unmounting the cloud disk from CVM A and then mounting it to CVM B.
ls -l /dev/disk/by-id
wmic diskdrive get caption,deviceid,serialnumber
wmic path win32_physicalmedia get SerialNumber,Tag
Since November 2017, data disks purchased along with CVMs support unmounting and remounting. To avoid lifecycle management difficulties when data disks are unmounted and remounted to another CVM with a different expiration date, we provide various options such as expiration date alignment and automatic renewal configuration. We recommend you carefully select the appropriate lifecycle management method, to avoid data loss caused by disk expiration.
When mounting a cloud disk, you can configure whether it will be automatically released along with your instance. You can enable or disable this feature via the [CBS Console] (https://console.cloud.tencent.com/cvm/cbs/index) or the ModifyDiskAttributes API.
If you lost all data in a directory (such as
/data) after the restart, and you know the reason is that you didn’t mount data disk partitions, follow the step-by-step directions below:
fdisk -lto view the unmounted partitions.
mount /dev/vdb /datato mount partitions.
df -hto see if they are mounted successfully.
No. Data in cloud disks will not be modified during mounting or unmounting. To ensure data consistency, we strongly recommend that you follow the steps below:
umountcommand on the cloud disk, and then access the Console to unmount the disk.
For more information, see Unmounting Cloud Disks.
The following instructions are only applicable for elastic cloud disks that support unmounting. Non-elastic cloud disks that do not support unmounting have the same lifecycles as CVMs. For more information, see Arrears.
Pay-as-you-go cloud disks:
No. To do this, you need to create a snapshot for backup and then use the snapshot to create a cloud disk of your needed type.
Yes. Cloud disks support capacity adjustment. You can [expand the capacity] ](https://intl.cloud.tencent.com/document/product/362/31600), but cannot reduce the capacity of cloud disks.
Only cloud disks support expansion. Local disks cannot be expanded. For more information, see Cloud Disk Expansion Scenarios.
- We strongly recommend that you create a snapshot before expansion to ensure data security.
- If the maximum capacity of the cloud disk still cannot meet your business needs, you can try building up RAID groups using multiple elastic cloud disks or building LVM logical volumes using multiple elastic cloud disks.
- Disks in MBR format support a maximum capacity of 2 TB. If your disk is in MBR format and you need to expand its capacity to more than 2 TB, we recommend that you create and mount a new data disk, and copy the data to the new disk using GPT partition format.
For more information about expansion operations, see Cloud Disk Expansion Scenarios.
When you expanded your capacity successfully through the Console, only the storage capacity of your data disk is increased. You also need to log in to your CVM and extend the partitions and file systems. For more information, see:
Extending Partitions and File Systems (Windows)
Extending Partitions and File Systems (Linux)
If the system disk of the CVM is a cloud disk, you can adjust its CPU and memory.
Disks in MBR format support a maximum capacity of 2 TB. If your disk is in MBR format and you need to expand its capacity to more than 2 TB, we recommend that you create and mount a new data disk, and copy the data to the new disk using GPT partition format.
For more information, see Building up RAID Groups Using Multiple Elastic Cloud Disks.
For more information, see Building LVM Logical Volumes Using Multiple Elastic Cloud Disks.
Therefore, we recommend that you use elastic cloud disks to store data that needs to be saved for a long term.
After formatting, cloud disks cannot be restored. We recommend you create a snapshot before formatting.
LinuxOS supports the
systemd mount command that generates the mounting configuration file, and the existing
.mount still remains, the mounting to the same directory
/run/systemd/generator/ therefore will be affected.
Assume you have mounted the data disk vdb to the directory
mount -a on the fstab file based on disk uuid). Now, you want to mount another data disk vdc to the same directory and replace the data disk vdb. If you directly mount vdc, you cannot read its data in the directory.
reloadcommand (for example, use
mount /dev/vdc /opt/appscommand).