Docker Compose Down -v: Panduan Cegah Data Hilang 2026

Tolong ya, jangan pernah anggap remeh perintah yang satu ini. docker compose down di mata kebanyakan orang cuma perintah “bersih-bersih” biasa. Eh, begitu nempel huruf -v di belakangnya, dia berubah jadi alat penghapus data yang paling jahat. Aku ngga ngarang, karena bulan lalu aku pegang ticket client yang data database-nya raib total gara-gara satu baris perintah ini.

Yang bikin makin nyesek, ada kasus kedua yang justru “selamat”. Seorang engineer niatnya reset environment, dia ketik perintah yang dia kira udah bener, eh ternyata kurang satu flag. Dan justru karena kurang flag itulah data volume-nya masih utuh. Dia ngga pakai opsi -v waktu eksekusi docker compose down, dan itu nyelamatin dia dari bencana yang dia sendiri ngga sadari.

Nah, sebelum masuk ke detail kasusnya, aku mau jelasin dulu cara kerja dua perintah ini, soalnya akar masalahnya hampir selalu dari salah paham soal ini. docker compose down itu tugasnya menghentikan dan menghapus container yang dibuat oleh compose file, plus network default yang dibuat Compose. Bagian yang sering keliru: named volume yang kamu deklarasi di bagian volumes: pada compose file TIDAK ikut terhapus. Data kamu tetap aman. Tapi kalau kamu menambah flag -v atau --volumes, Docker bakal menghapus juga named volume tersebut plus anonymous volume yang menempel di container. Di situ data database, file upload user, atau cache aplikasi bisa hilang dalam hitungan detik, tanpa konfirmasi, tanpa undo.

Impact-nya bukan cuma data hilang doang. Di kasus yang aku tangani, client harus nunggu 3 hari sambil tim dev balikin data dari backup yang ternyata basi seminggu. Revenue loss, trust user turun, dan tim ops harus ekstra lembur ngejelasin ke client apa yang sebenernya terjadi. Dan penyebabnya cuma satu: yang jalanin perintah ngga sadar bedanya down dan down -v.

Kamu mungkin mikir, “masa sih bisa ketuker gitu, cuma beda satu huruf.” Percaya deh, ini lebih sering kejadian daripada yang kamu bayangin. Penyebabnya macam-macam: copy-paste snippet dari tutorial yang asal nulis docker compose down -v sebagai cara reset, alias di shell yang ketuker, atau kebiasaan bikin script cleanup yang isinya down -v biar “bersih total” terus lupa dikasih penjaga. Dari pengalaman lapangan, penyebab paling umum itu copy-paste dari dokumentasi dan alias yang bikin orang lupa bahwa perintah itu sebenernya destruktif. Dua-duanya gampang dicegah kalau kamu ngerti risikonya. Aku kasih kasus-kasus nyata biar kebayang, mulai dari yang beruntung sampai yang ngenes.

Kronologi Kasus 1: Beruntung karena Tidak Pakai -v

Kasus pertama ini sebenernya bikin aku mikir, untung yang salah malah jadi penyelamat. Ada tim yang mau “bersih-bersih” environment development mereka yang udah penuh container nyasar. Mereka copy command cleanup dari snippet di repo internal, isinya cuma docker compose down tanpa flag tambahan. Perintah itu jalan, semua container mati dan terhapus. Eh, begitu mereka mau lanjut kerja, baru sadar mereka jalanin di stack yang salah, stack yang isinya database development yang udah seminggu dipake testing.

Panik? Iya, sempat. Tapi sebelum nangis, salah satu dari mereka inget buat cek volume. Dan ini momennya: docker volume ls nunjukin semua named volume masih ada. Data masih utuh. Kenapa? Ya karena mereka ngga pakai -v waktu eksekusi docker compose down. Yang terhapus cuma container sama network, sedangkan volume-nya tetap nyangkut di disk. Mereka tinggal jalanin docker compose up -d, dan voila, data balik semua kayak ngga pernah terjadi apa-apa.

Nah, ini pelajaran pertama yang wajib kamu catat: docker compose down tanpa -v itu menyimpan volume. Command ini aman buat ngereset state aplikasi, karena data yang kamu simpan di named volume bakal tetap ada dan tinggal di-mount lagi pas container dibuat ulang. Perintah yang justru bahaya itu yang ada -v-nya, atau kombinasi down lalu docker volume prune.

Kronologi Kasus 2: Sekali -v, Data Ikut Tenggelam

Kasus kedua ini kebalikannya, dan jujur aja, ini yang bikin aku paling kesel. Ada temen se-profesi yang ikutin tutorial “bersih-bersih docker” dari blog (bukan blog ini, hehe). Di tutorial itu, penulisnya asal nulis docker compose down -v sebagai cara reset total, tanpa ada warning sama sekali. Temenku ini jalanin di stack yang udah dipake 2 bulan buat project client, yang di dalamnya ada volume PostgreSQL berisi data testing yang penting.

Hasilnya? Semua container hilang, network hilang, volume PostgreSQL ikut hilang. Begitu dia jalanin docker compose up -d, database yang naik itu kosong melompong, kaya fresh install. Dia baru nyadar kejadian 4 jam kemudian, dan backup terakhir ada di seminggu sebelumnya. Mau cerita ke client? Malu, tapi mau gimana lagi. Kurang lebih seminggu kerjaan dia ilang, plus dia harus jujur ke tim.

Dari kasus ini aku belajar, tutorial yang ngga ngasih warning itu sebenernya berbahaya. Kalau kamu nulis dokumentasi atau snippet buat tim, selalu tulis perbedaan down dan down -v. Bener-bener worth it buat nolong orang lain di kemudian hari.

Kronologi Kasus 3: Kombinasi down + volume prune

Kasus ketiga ini lebih licik, karena ngga ada perintah yang “salah” sepenuhnya, tapi urutannya yang bikin celaka. Ada orang yang jalanin docker compose down (tanpa -v) buat ngurangin beban server. Karena container-nya ilang, named volume-nya jadi “unused” alias ngga dipake container mana pun. Terus, di lain waktu, ada proses maintenance yang jalanin docker volume prune buat bersihin sisa-sisa docker, tanpa nyadar bahwa volume yang “nganggur” itu sebenarnya masih penting.

Nah, di sinilah jebakannya. docker volume prune itu ngapus SEMUA volume yang ngga dipake container. Dan setelah docker compose down, semua volume stack kamu masuk kategori ini. Jadinya, down dulu, prune belakangan, sama aja bahayanya kayak langsung down -v. Yang bikin tambah bahaya, command prune ini bikin prosesnya keliatan “aman” karena dipisah, padahal efeknya akumulatif.

Pelajaran dari kasus ketiga ini: kalau kamu ngereset stack, jangan asal prune. Selalu cek dulu volume mana yang masih kepake. Di bagian verifikasi di bawah ini aku kasih command-commandnya biar kamu bisa mutusin dengan tenang.

Cara Verifikasi Volume Sebelum & Sesudah Eksekusi

Oke, sekarang bagian yang paling berguna. Sebelum kamu jalanin perintah destruktif apa pun yang nyangkut docker volume, biasakan verifikasi. Ini checklist yang aku pake di tim:

1. Lihat container yang jalan: docker ps -a --format '{{.Names}} {{.Image}}'
2. Cek mount tiap container: docker inspect <container> --format '{{range .Mounts}}{{.Name}} -> {{.Destination}}{{end}}'
3. List semua volume yang ada: docker volume ls
4. Inspect volume tertentu: docker volume inspect <nama-volume>
5. Kalau pakai Compose, cek definisi volume: docker compose config --volumes

Output dari docker volume inspect itu kayak gini, perhatiin bagian Mountpoint:

$ docker volume inspect db_data
[
    {
        "CreatedAt": "2026-06-11T08:14:32Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/db_data/_data",
        "Name": "db_data",
        "Options": null,
        "Scope": "local"
    }
]

Kalau volume-nya masih ada di docker volume ls setelah kamu jalanin docker compose down, berarti kamu aman. Data kamu masih nyimpen di /var/lib/docker/volumes/<nama>/_data. Kamu tinggal up lagi dan container bakal nge-mount volume yang sama. Tapi kalau volume-nya udah ngga muncul di list, itu tandanya udah kehapus, dan kamu harus balik ke backup.

Buat kamu yang pengen tau lebih dalam soal backup restore volume, aku tulis panduan khusus di artikel cara backup restore docker volume. Dan kalau kamu pengen ngatur Compose dengan aman di production, cek juga best practice docker compose production.

Tabel Perbandingan Perintah yang Sering Ketuker

Baca tabelnya pelan-pelan, soalnya ini inti dari semua kasus di atas. Semua perintah yang ada di baris kedua dan terakhir itu yang paling sering bikin orang nangis. Ngga heran banyak yang bilang, docker volume itu pisau bermata dua: bisa bikin data kamu abadi, bisa juga bikin data kamu hilang.

Backup Volume Sebelum Eksekusi Destruktif

Kalau kamu memang terpaksa harus ngereset total, biasakan backup dulu. Buat volume docker, cara paling simpel pakai container alpine:

docker run --rm 
  -v db_data:/data 
  -v /home/ops/backup:/backup 
  alpine tar czf /backup/db_data-$(date +%F).tar.gz -C /data .

Perintah di atas nge-pack seluruh isi volume db_data ke file /home/ops/backup/db_data-2026-07-01.tar.gz. Restore-nya tinggal kebalikannya:

docker run --rm 
  -v db_data:/data 
  -v /home/ops/backup:/backup 
  alpine sh -c "rm -rf /data/* && tar xzf /backup/db_data-2026-07-01.tar.gz -C /data"

Catatan penting: sebelum restore, pastikan container yang pake volume itu di-stop, biar ngga ada proses yang nulis ke file waktu kita timpa. Dan kalau yang kamu backup itu database kayak MySQL atau PostgreSQL, lebih bagus pakai dump tool bawaan masing-masing, misalnya pg_dump buat Postgres atau mysqldump buat MySQL, biar konsisten. Ada juga cara lain yang lebih otomatis, aku bahas di panduan backup database MySQL.

Pencegahan Biar Ngga Kejadian Lagi

Biar kasus kayak gini ngga mampir ke kamu, ini beberapa langkah preventif yang bisa langsung kamu terapin:

• Jangan taruh -v di script otomatis. Kalau ngga ada kebutuhan jelas untuk ngapus volume, jangan pernah masukin flag -v ke script cleanup. Bikin script terpisah yang butuh konfirmasi manual.
• Kasih konfirmasi sebelum eksekusi. Di script, pakai konfirmasi interaktif sebelum perintah destruktif jalan. Mending kena telat 2 detik daripada data hilang.
• Jangan alias down ke down -v. Kalau kamu pengen jalanin down biasa, pakai docker compose down apa adanya. Jangan bikin shortcut yang sebenernya destruktif.
• Backup terjadwal. Setiap environment yang isinya data berharga wajib punya backup rutin, entah pakai cron atau tool lain. Backup itu asuransi paling murah.
• Cek compose config dulu. Sebelum jalanin apa pun, pastikan docker compose config nunjukin definisi volume yang bener, biar ngga salah stack.

Kalau kamu pengen tau lebih banyak soal cara baca log docker buat tracing masalah kayak gini, aku juga punya artikel troubleshooting log docker yang bisa kamu pelajari. Semua masalah yang aku sebut di atas sebenernya ketauan dari awal kalau kita mau liat log dan output-nya teliti.

Tolong ya, jangan ngulang kesalahan yang kayak gini. Pelajarin baik-baik bedanya down dan down -v sebelum kamu sentuh production server. Satu huruf bisa beda nasib: data kamu selamat, atau data kamu hilang. Take it seriously. Kalau kamu punya cerita horror soal docker volume, drop di komentar, biar yang lain juga belajar dari pengalaman kamu.