Cara Update Container Docker Tanpa Kehilangan Data

Update container Docker tidak menghapus data, asalkan data itu disimpan di volume atau bind mount. Container sendiri memang dirancang untuk dibuang dan dibuat ulang; yang harus bertahan adalah folder data yang dipasang ke dalamnya.

Kenapa ini penting? Banyak kasus "data hilang setelah update" ternyata berasal dari container yang menyimpan data di lapisan tulisnya sendiri. Begitu container lama dihapus dan diganti versi baru, lapisan itu ikut lenyap. Daftar berikut membantu kamu memastikan hal itu tidak terjadi.

1. Di mana sebenarnya datamu tersimpan?

Mulai dari sini, sebelum menyentuh image apa pun. Jalankan:

docker inspect -f '{{ json .Mounts }}' nama-container

Hasilnya menunjukkan setiap mount: tipe (volume atau bind), sumber di host, dan tujuan di dalam container. Bandingkan dengan dokumentasi image. Misalnya image database resmi menyimpan data di /var/lib/mysql atau /var/lib/postgresql/data. Kalau folder data penting tidak muncul di daftar mount, data itu ada di dalam container dan akan hilang saat container dihapus.

Ada satu jebakan lagi: volume anonim. Image yang mendeklarasikan VOLUME di Dockerfile akan membuat volume tanpa nama bila kamu tidak memasang volume sendiri. Docker Compose umumnya memakai ulang volume anonim saat membuat ulang container, tapi docker run biasa tidak. Container baru akan mendapat volume anonim baru yang kosong. Solusinya: selalu pakai volume bernama atau bind mount untuk data penting.

2. Backup dulu, apa pun ukurannya

Untuk database, dump lebih aman daripada menyalin file mentah selagi database berjalan:

docker exec nama-db sh -c 'mariadb-dump -uroot -p"$MARIADB_ROOT_PASSWORD" --all-databases' > db.sql

Untuk PostgreSQL, padanannya pg_dumpall atau pg_dump. Untuk volume berisi file biasa, arsipkan lewat container sementara:

docker run --rm -v nama-volume:/data -v "$PWD":/backup alpine tar czf /backup/nama-volume.tar.gz -C /data .

Backup yang belum pernah dicoba dipulihkan belum bisa diandalkan. Kebiasaan ini dibahas di uji restore backup berkala.

3. Catat versi yang sedang berjalan

docker inspect -f '{{ .Config.Image }}' nama-container
docker image ls

Kalau compose file memakai latest, kamu tidak tahu persis versi lamanya. Pakai tag versi yang jelas, misalnya nginx:1.27 atau postgres:17. Dengan begitu, rollback cukup mengganti tag kembali.

4. Baca catatan rilis untuk lompatan versi besar

Update patch dan minor biasanya aman. Update versi mayor perlu dibaca dulu, terutama untuk database:

• PostgreSQL tidak bisa langsung membaca folder data dari versi mayor sebelumnya. Mengganti postgres:16 menjadi postgres:17 tanpa migrasi membuat container gagal start. Jalurnya adalah dump lalu restore, atau pg_upgrade.
• MySQL dan MariaDB melakukan upgrade data saat start, tapi turun versi setelahnya tidak selalu bisa.
• Aplikasi seperti Nextcloud atau GitLab punya urutan upgrade yang tidak boleh dilompati.

Perubahan dari penerbit image juga perlu diperhatikan. Contohnya ada di perubahan image Bitnami.

5. Update dengan Docker Compose

Bila layanan dikelola Compose, prosesnya pendek:

docker compose pull
docker compose up -d

pull mengunduh image baru, lalu up -d hanya membuat ulang container yang image atau konfigurasinya berubah. Volume bernama tetap dipakai. Untuk satu layanan saja: docker compose pull db && docker compose up -d db. Contoh susunan Compose dengan volume yang benar ada di WordPress dengan Docker Compose.

6. Update container yang dibuat dengan docker run

Tanpa Compose, kamu harus membuat ulang container dengan opsi yang sama persis. Cara yang memberi jalan mundur:

Simpan perintah docker run di file skrip agar opsi tidak terlupa. Lebih baik lagi, pindahkan ke compose file.

7. Hindari perintah yang ikut menghapus volume

Perintah prune sangat berguna untuk merapikan disk, tapi jalankan hanya saat semua container penting sedang berjalan atau setidaknya masih ada. Daftar kebiasaan berisiko lainnya ada di kesalahan umum Docker di produksi.

8. Bersihkan image lama setelah yakin

Setelah versi baru berjalan stabil beberapa hari, hapus image lama dengan docker image prune. Jangan terburu-buru; image lama adalah tiket rollback tercepat.

9. Verifikasi setelah update

Container yang berstatus "Up" belum tentu sehat. Setelah update, periksa beberapa hal berikut:

• docker compose ps atau docker ps: pastikan tidak ada container yang terus restart.
• docker logs --tail 100 nama-container: cari pesan error migrasi atau izin file.
• Buka aplikasinya dan coba alur penting, misalnya login, menyimpan data, dan mengunggah file.
• Pastikan data lama tetap ada. Untuk database, hitung jumlah baris tabel penting dan bandingkan dengan sebelum update.

Kalau ada yang janggal, kembalikan tag image lama di compose file, jalankan docker compose up -d, lalu pulihkan dari backup bila data ikut berubah. Mencatat semua langkah ini dalam satu catatan pendek per server membuat update berikutnya jauh lebih tenang.