Pentingnya Pemisahan Storage di Cloud
Dalam pengelolaan Virtual Private Server (VPS) berbasis cloud, khususnya di AWS EC2, menjaga pemisahan antara data sistem operasi (OS) dan data aplikasi/pengguna adalah praktik yang sangat direkomendasikan.
Secara default, Instance EC2 diluncurkan dengan satu volume Elastic Block Store (EBS) yang berisi OS dan semua file yang terkait. Meskipun sederhana, konfigurasi single-volume ini memiliki keterbatasan:
Backup dan Pemulihan (Recovery): Jika disk utama mengalami masalah atau Anda perlu mengembalikan OS tanpa memengaruhi data aplikasi (misalnya, database atau uploads pengguna), pemisahan akan mempermudah proses ini.
Skalabilitas: Memungkinkan Anda untuk meningkatkan ukuran disk data tanpa harus mengganggu disk OS.
Kinerja: Anda dapat memilih jenis volume EBS yang berbeda (misalnya, volume gp3 berkinerja tinggi untuk data aplikasi, dan gp2 standar untuk OS).
Panduan ini akan berfokus pada sistem operasi Linux yang umum digunakan di AWS (Ubuntu, Amazon Linux, dsb.) dan memberikan instruksi rinci untuk melakukan mounting permanen menggunakan file konfigurasi /etc/fstab.
Pilar 1: Persiapan dan Alokasi Volume EBS Sekunder
Sebelum melakukan mounting, kita perlu membuat volume EBS baru dan melampirkannya ke Instance EC2 yang sudah ada.
1.1 Persyaratan Sistem dan Terminologi
Untuk panduan ini, kita akan mengasumsikan:
Instance: Instance EC2 Linux yang sudah berjalan (misalnya, menggunakan Ubuntu 24.04).
Volume Utama (Boot): Terlampir, biasanya
/dev/xvdaatau/dev/sda1.Volume Sekunder (Data): Volume EBS baru yang akan kita buat dan format, target mount-nya adalah direktori
/dataatau/appdata.
1.2 Langkah 1: Membuat Volume EBS Baru
Navigasi AWS: Masuk ke AWS Management Console dan navigasi ke layanan EC2.
Di panel kiri, di bawah Elastic Block Store, pilih Volumes.
Klik “Create Volume”.
Konfigurasi Volume:
Volume Type: Pilih gp3 (Direkomendasikan karena rasio harga/kinerja yang lebih baik).
Size: Tentukan ukuran yang Anda butuhkan (misalnya, 100 GiB).
Availability Zone (AZ): Ini adalah langkah kritis. Pastikan Anda memilih AZ yang SAMA dengan Instance EC2 Anda yang sudah berjalan. Volume EBS hanya dapat dilampirkan ke Instance di AZ yang sama.
Klik “Create Volume”.
1.3 Langkah 2: Melampirkan Volume ke Instance EC2
Setelah Volume dibuat dan berstatus Available:
Pilih Volume EBS baru di Dasbor Volume.
Klik Actions, lalu pilih “Attach Volume”.
Instance: Cari dan pilih Instance EC2 yang ingin Anda tuju.
Device Name: AWS akan memberikan nama device rekomendasi, seperti
/dev/sdfatau/dev/sdg. Catat nama ini, karena ini adalah yang akan Anda gunakan saat mengakses disk dari dalam Instance.
Peringatan Penting: Meskipun AWS menyarankan
/dev/sdf, sistem operasi Linux mungkin mengubah nama ini menjadi/dev/xvdfatau yang serupa. Kita akan menggunakan perintah Linux untuk mengonfirmasi nama device yang sebenarnya.
Pilar 2: Persiapan Disk di Server Linux
Setelah volume terlampir, Anda perlu masuk ke server melalui SSH dan menyiapkan disk tersebut.
2.1 Langkah 3: Verifikasi Lampiran dan Identifikasi Volume
Hubungkan ke Instance EC2 Anda melalui SSH. Gunakan perintah lsblk untuk melihat semua disk yang terlampir:
lsblk
Anda akan melihat output yang menunjukkan disk utama (xvda) dan disk baru Anda yang terlampir (kemungkinan xvdf, tetapi tanpa mount point atau partisi).
# Contoh Output lsblk (Setelah Volume Baru Dilampirkan)
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 100G 0 disk <-- Volume Baru
2.2 Langkah 4: Membuat Filesystem (Memformat Disk)
Disk baru masih mentah dan perlu diformat dengan filesystem (seperti ext4 atau xfs) sebelum dapat menyimpan data. Ext4 adalah pilihan yang paling umum dan direkomendasikan untuk sebagian besar workload hosting.
Peringatan: Perintah ini akan menghapus semua data yang mungkin ada di volume baru (
/dev/xvdf). Pastikan Anda menggunakan nama device yang benar!
# Ganti /dev/xvdf dengan nama device yang Anda lihat di lsblk
sudo mkfs -t ext4 /dev/xvdf
Jika berhasil, Anda akan melihat konfirmasi bahwa filesystem ext4 telah dibuat.
2.3 Langkah 5: Membuat Direktori Mount Point
Kita perlu membuat direktori tempat disk baru akan diakses. Direktori ini sering disebut mount point. Kami akan menggunakan /data sebagai contoh.
sudo mkdir /data
2.4 Langkah 6: Melakukan Mount Sementara
Lakukan mount volume baru ke direktori yang baru dibuat:
sudo mount /dev/xvdf /data
Verifikasi mounting dengan lsblk lagi. Anda akan melihat /data di kolom MOUNTPOINTS. Anda juga dapat memeriksa penggunaan disk dengan df -h:
df -h
Pilar 3: Mounting Permanen Menggunakan fstab
Mount yang dilakukan di Langkah 6 hanya bersifat sementara; ia akan hilang saat Instance di-reboot. Untuk membuat mounting permanen, kita perlu mengedit file konfigurasi sistem /etc/fstab.
3.1 Langkah 7: Mengidentifikasi UUID Disk
Menggunakan nama device (/dev/xvdf) di fstab tidak direkomendasikan karena nama device terkadang dapat berubah saat reboot. Pendekatan terbaik adalah menggunakan Universally Unique Identifier (UUID).
Gunakan perintah blkid untuk mendapatkan UUID dari disk yang baru diformat:
sudo blkid
Cari baris yang sesuai dengan device Anda (/dev/xvdf) dan salin UUID-nya.
# Contoh Output blkid
/dev/xvdf: UUID="a1b2c3d4-e5f6-7g8h-9i0j-k1l2m3n4o5p6" TYPE="ext4"
3.2 Langkah 8: Mengedit File /etc/fstab
Kita akan menggunakan editor teks nano atau vim untuk mengedit fstab.
sudo nano /etc/fstab
Tambahkan baris baru di bagian bawah file (tanpa menghapus baris yang sudah ada). Gunakan format berikut:
# <file system> <mount point> <type> <options> <dump> <pass>
UUID="a1b2c3d4-e5f6-7g8h-9i0j-k1l2m3n4o5p6" /data ext4 defaults,nofail 0 2
Penjelasan Parameter Kunci:
UUID=...: Identitas permanen disk yang baru Anda salin./data: Mount point yang sudah kita buat.ext4: Tipe filesystem yang kita gunakan saat memformat.defaults,nofail:defaults: Menggunakan opsi standar (termasukrwread-write).nofail: Sangat Penting di AWS. Opsi ini memberi tahu sistem untuk melanjutkan proses boot jika disk ini gagal mount. Jika Anda tidak menggunakannofaildan disk mengalami kegagalan, Instance Anda mungkin gagal boot dan tidak dapat diakses.
0 2: Opsi dump (tidak digunakan) dan fsck (pemeriksaan disk saat boot).
Simpan file (Ctrl+O, Enter, Ctrl+X jika menggunakan nano).
3.3 Langkah 9: Menguji fstab dan Reboot
Sebelum melakukan reboot yang sebenarnya, jalankan perintah mount -a untuk menguji file fstab. Perintah ini akan mencoba mounting semua entri yang belum di-mount di fstab.
# Uji fstab
sudo mount -a
# Verifikasi Mount Point
df -h
Jika tidak ada error yang ditampilkan, Anda siap untuk melakukan reboot untuk menguji mounting permanen:
sudo reboot
Setelah Instance kembali online (biasanya 1–2 menit), login kembali melalui SSH dan jalankan df -h. Jika volume terlampir ke /data, konfigurasi mounting permanen Anda berhasil.
Pilar 4: Konfigurasi Kepemilikan dan Keamanan Data
Untuk server shared hosting atau aplikasi (seperti WordPress, yang dijalankan oleh user www-data atau nginx), Anda harus mengatur kepemilikan dan izin disk baru agar aplikasi dapat menulis dan membaca data.
4.1 Langkah 10: Mengatur Kepemilikan Direktori
Jika Anda menggunakan volume ini untuk data website (misalnya, di bawah CyberPanel, data berada di /home/), ubah kepemilikan sesuai dengan user yang digunakan aplikasi Anda. Untuk shared hosting dasar, mari kita ubah kepemilikan kepada user ubuntu untuk sementara dan group www-data (sering digunakan oleh Web Server).
# Ubah kepemilikan root direktori ke user:group yang relevan
sudo chown -R ubuntu:www-data /data
# Ubah izin untuk memastikan akses group yang memadai
sudo chmod -R 775 /data
Jika Anda menggunakan panel hosting (seperti CyberPanel yang diinstal di panduan sebelumnya), Anda dapat membuat symlink (tautan simbolik) dari /home/ lama ke volume data baru, atau mengatur mount point ini sebagai tujuan data Anda di panel.
4.2 Studi Kasus: Menggunakan Volume Sekunder untuk WordPress Data
Dalam kasus hosting WordPress yang optimal, data yang sering berubah (seperti /wp-content/uploads/) harus berada di volume yang terpisah.
Misalkan Anda ingin memindahkan folder /var/www/html/wp-content/uploads/ ke volume baru (/data).
Pindahkan Data Lama:
Bashsudo mv /var/www/html/wp-content/uploads /data/uploads_oldBuat Direktori Target:
Bashsudo mkdir /data/uploadsBuat Symlink: Buat tautan simbolik dari lokasi lama ke lokasi baru di disk sekunder.
Bashsudo ln -s /data/uploads /var/www/html/wp-content/uploads
Dengan cara ini, aplikasi WordPress masih mencari data di jalur lama, tetapi sebenarnya data tersebut disimpan di Volume EBS sekunder yang lebih besar dan terpisah.
Kesimpulan: Ketahanan dan Fleksibilitas Data EC2
Implementasi dua volume EBS dengan mounting permanen adalah praktik fundamental dalam mengelola server cloud yang scalable dan tahan banting. Dengan memisahkan OS dan data aplikasi menggunakan UUID di /etc/fstab dengan opsi nofail, Anda telah memastikan bahwa disk data Anda dapat di backup, diganti, atau diperbesar tanpa mengganggu stabilitas boot dan sistem operasi inti.
Ini adalah fondasi yang kokoh untuk layanan shared hosting, database server, atau storage file berskala besar di lingkungan AWS.
Perintah Kunci untuk Verifikasi dan Debugging Permanen
Gunakan perintah-perintah ini untuk memverifikasi dan memperbaiki masalah mounting volume EBS Anda:
# Perintah Kunci: Melihat UUID semua disk yang diketahui sistem
sudo blkid
# Perintah Kunci: Menguji fstab tanpa reboot
sudo mount -a
# Perintah Kunci: Melihat struktur disk dan mount point saat ini
lsblk
# Perintah Kunci: Melihat penggunaan disk secara rinci
df -h

