A model for applications that expect a disk
Define data layout for software that uses file-system access. Mount points, ownership and permissions belong in the operating plan.
STORAGE / BLOCK STORAGE
Consider block storage for application files, database data and growing workspaces. A useful choice accounts for file systems, access patterns, server attachment and recovery requirements alongside the amount of capacity the application needs.
01 / Overview
Block storage presents storage that an operating system can use as a disk device. Applications manage data through a file system or another supported disk layout. This differs from Object Storage, which addresses files through an object API; the access model expected by the application is the first decision.
Capacity and access performance are different requirements. A small database with frequent random operations behaves differently from large sequential files. Confirm attachment, capacity-change and performance characteristics against the current service scope, then complete the storage plan with backup and recovery procedures.
Define data layout for software that uses file-system access. Mount points, ownership and permissions belong in the operating plan.
Measure storage requirements separately from CPU and memory. Include growth and temporary processing space as well as the data already stored.
Identify the directories and databases that need protection. The presence of a disk does not establish that its contents can be restored consistently.
02 / Architecture
Illustrative access path: an application uses a block device through its file system. A backup copy is a separate data-protection step.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| File system | Identify a file system supported by the operating system and application. | Formatting and mount decisions directly affect how the data is used. |
| I/O pattern | Measure random and sequential access, reads and writes separately. | The same capacity can behave differently under different workloads. |
| Attachment model | Confirm the server and access mode supported for the volume. | Concurrent writes from multiple servers require a suitable coordinated design. |
| Protection and growth | Plan backup, retention, resizing and deletion behaviour. | The data lifecycle involves more than adding disk space. |
04 / Use cases
Organise data paths for applications expecting file and directory access. Verify permissions and attachment behaviour after a restart.
Test storage latency and write behaviour alongside the actual query workload. Preserve the database’s backup and consistency requirements.
Estimate peak space for imports, reports and temporary files. Distinguish disposable working data from information that must be retained.
Plans & pricing
Scroll horizontally to view all columns.
| Storage | $/Mo |
|---|---|
| 80 GB | $8 |
| 640 GB | $64 |
| 1280 GB | $128 |
Review the current configuration, price and order terms before selecting a service.
05 / From planning to operation
Separate persistent, temporary and reproducible data. Define capacity and backup requirements for each category.
Verify the supported connection and device identity. Check backups and migration plans before formatting any device that may contain existing data.
Test permissions, file paths and behaviour after a restart. Measure storage access with representative data.
Restore a backup in a separate environment. Confirm that the application can open the recovered data and perform its expected work.
Block storage is considered for disk and file-system access. Object storage addresses files through keys, metadata and APIs. Choose according to the access model your application expects.
Confirm the attachment modes supported by the service. Concurrent writes to one file system can corrupt data without appropriate file-system support and coordination.
The storage device, partition and file system are separate layers. Check the supported resizing procedure, operating-system requirements and recovery plan together.
No. Accidental deletion, application errors and inconsistent writes can persist on the disk. Plan an independent backup and verify that it can be restored.
Connect product decisions with installation, configuration and operating knowledge.
These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.
FIBACLOUD / Block Storage
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.