{
  "id": 11439086,
  "title": "Learning Distributed Object Storage with Incus and PGSTY SILO",
  "url": "https://urgent.news/2026/10/02/learning-distributed-object-storage-with-incus-and-pgsty-silo",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-02T12:42:20.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/hardyweb/learning-distributed-object-storage-with-incus-and-pgsty-silo-3ad9"
  },
  "original_language": "en",
  "account": "1. The primary objective of this lab is to gain a deeper understanding of distributed storage, specifically object storage systems like MinIO and SILO, by utilizing multiple storage drives and nodes to provide redundancy and ensure continued operation in the event of storage failures. The lab employs a Windows machine with WSL2 Debian Incus Debian VM, PGSTY SILO, and MinIO Client (mc) to simulate a distributed storage environment. The main goal is not to create a production storage cluster, but rather to comprehend how storage behaves when a drive or node fails. PGSTY SILO is a fork of MinIO that maintains compatibility with S3 and MinIO tooling.\n\n2. The decision to use Incus was made due to the lack of physical servers available for use as storage nodes. Incus was used to simulate multiple servers. The topology includes WSL2 with two Incus VMs, each containing two storage drives. The Incus custom block volumes are utilized within the VMs to simulate real storage drives, enabling hotplug functionality and device attachment. The final architecture consists of Incus hosting two Debian VMs, each with two virtual storage drives (sdb and sdc) attached.\n\n3. Incus was chosen over containers because Incus containers use virtual block devices as virtual HDDs, requiring the use of real block devices such as /dev/sdb and /dev/sdc for simulating authentic storage drives. Incus custom block volumes can be used within VMs, supporting hotplug functionality, which is essential for this experiment. The final architecture consists of Incus hosting two Debian VMs, each with two virtual storage drives attached.\n\n4. For each VM, two Incus block volumes were created: one named silo1 and the other silo1-extra, both with a size of 5GiB. These volumes were then attached to the respective VMs using Incus config device commands. As a result, debian-vm and debian-vm2 each had two storage endpoints (sda, sdb, sdc) associated with them. Similarly, these configurations were applied to debian-vm2, resulting in four storage endpoints in total (2 nodes × 2 drives = 4 storage endpoints).\n\n5. The storage was formatted using the ext4 filesystem on each block device: sudo mkfs.ext4 /dev/sdb and sudo mkfs.ext4 /dev/sdc. Subsequently, the directories /mnt/export1 and /mnt/export2 were created and mounted on the respective storage drives (sdb and sdc). This setup ensures that each node has two distinct storage drives mounted at /mnt/export1 and /mnt/export2, allowing for individual experiments on storage failures.\n\n6. To enable communication between nodes, Incus provides network and DNS services for the instances. For instance, a ping from debian-vm to debian-vm2 is successful, allowing SILO to utilize hostnames like debian-vm and debian-vm2 as storage endpoints. This network setup facilitates the distributed storage functionality.\n\n7. Before running SILO, authentication credentials for S3/API were set using environment variables: SILO_ROOT_USER = siloadmin and SILO_ROOT_PASSWORD = change-this-password. These credentials should be replaced with strong passwords and managed through a secret-management mechanism for production deployments. After setting the credentials, SILO was started using the storage endpoints (http://debian-vm/mnt/export1, http://debian-vm/mnt/export2, http://debian-vm2/mnt/export1, http://debian-vm2/mnt/export2). These environment variables and authentication mechanisms may need to be adjusted based on the specific version of SILO being used.\n\n8. The MinIO client (mc) was used to connect to SILO, configured as an S3 client using the hostname of the SILO server (http://debian-vm:9000, http://debian-vm/mnt/export1, etc.). After starting the SILO server, mc alias set silo was used to set the connection parameters. Various commands, such as mc alias list, mc admin info silo, mc mb silo/test, echo, and mc cp, were executed to create a bucket, upload an object, download an object, inspect server and storage status, and verify the results.\n\n9. The final step in the experiment involved building a distributed SILO pool using the four storage endpoints. This setup transforms the view of the storage from four separate drives to a single distributed storage pool. The output from mc admin info silo confirms that the pool consists of 1 drive across 2/2 OK and displays the configuration details, including the erasure coding parameters for redundancy. This setup demonstrates that distributed storage is more complex than simply copying files, as it employs erasure coding mechanisms to provide redundancy among the storage drives.",
  "summary": "Aku buat R&D homelab untuk memahami konsep distributed storage , khususnya bagaimana object storage seperti MinIO/SILO menggunakan beberapa storage drives dan nodes untuk menyediakan redundancy dan survive daripada kegagalan storage. Untuk lab ini, aku gunakan: Windows + WSL2 Debian Incus Debian VM PGSTY SILO MinIO Client ( mc ) ext4 filesystem Tujuan utama bukan untuk membina production storage…",
  "key_points": [
    "Lab uses Incus VMs with two storage drives each to simulate distributed object storage",
    "Incus chosen over containers for virtual block devices and hotplug functionality",
    "MinIO Client (mc) configured to connect to SILO using four storage endpoints"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}