Menghapus container Docker yang paling penting sering terasa seperti akhir dari semuanya. Namun, kasus yang dialami FreshRSS menunjukkan bahwa satu keputusan penyelamatan yang tepat masih bisa menghidupkan kembali layanan yang tampak hilang total.
Masalahnya muncul saat ruang penyimpanan hard drive menyusut cepat. Setelah mengecek penggunaan disk, ruang yang habis ternyata banyak tersedot oleh build cache, image aktif, image tidak aktif, container, dan volume yang terkait dengan Docker.
Saat pembersihan berubah jadi bencana
Awalnya, Docker dicurigai sebagai penyebab utama karena mesin itu dipakai hampir eksklusif untuk bereksperimen selama satu minggu penuh. Pemeriksaan dengan perintah docker system df memperlihatkan bahwa build cache memakan banyak ruang, sementara ada pula beberapa image dan container yang tidak aktif.
Langkah pembersihan yang lebih tepat sebenarnya tersedia, seperti docker image prune --all dan docker builder prune. Tanpa opsi --all, prune hanya menghapus dangling images, sedangkan --all akan menghapus semua image yang tidak punya minimal satu container yang terkait.
Di titik itu, proses pembersihan masih berjalan normal. Namun, keputusan yang terlalu agresif justru menghapus container FreshRSS dengan perintah yang memuat rm, dan seluruh instalasi FreshRSS ikut lenyap.
Kenapa container yang terhapus tidak bisa “dibangunkan” lagi
Dalam konteks Docker, image adalah template yang berisi dependensi, library, tool sistem, dan kode aplikasi. Container adalah instance yang bisa dijalankan dari image itu, jadi saat container dihapus, instance tersebut memang tidak bisa dipulihkan.
Itulah yang terjadi ketika FreshRSS tidak bisa dimuat lagi. Awalnya, keadaan itu sempat dianggap hanya sebagai layanan yang berhenti berjalan, tetapi ternyata aplikasi lengkapnya sudah hilang dari sistem.
Jalan keluar datang dari persiapan sebelumnya
Untungnya, ada rencana cadangan yang sudah disiapkan. Instalasi FreshRSS dibangun ulang dari awal dengan proses yang sama seperti saat pertama kali memasang pembaca RSS tersebut, kali ini menggunakan Docker Compose.
Langkah penting lain adalah impor data langganan melalui file OPML. Sebelumnya, file itu sempat diekspor karena sedang bereksperimen dengan newsboat, dan OPML digunakan sebagai format untuk impor, ekspor, serta pencadangan seluruh feed.
Setelah image FreshRSS baru selesai dibuat, akun pengguna baru dibuat terlebih dahulu. Lalu menu Subscription Management > Import/Export > Import digunakan untuk memilih file OPML, dan seluruh RSS feed dari instance sebelumnya berhasil masuk kembali.
Pemulihan tidak hanya mengembalikan data lama
Setelah layanan kembali aktif, beberapa pengaturan juga disesuaikan. Opsi seperti Hide articles after reading dan Clicking outside of article text area closes the article dipilih karena dianggap lebih baik daripada konfigurasi sebelumnya.
Di sisi cadangan, file OPML diekspor lewat jalur Subscription Management > Import/Export > Export. File itu kemudian diunduh sebagai ZIP, sehingga salinan feed tetap tersedia jika kejadian serupa terulang.
Pengalaman ini juga menghasilkan kebiasaan baru dalam menjaga data. Backup OPML kini dibuat secara rutin setiap ada penambahan atau penghapusan sumber berita, kira-kira setiap dua minggu.
Pelajaran dari satu kesalahan kecil
Kasus ini menegaskan bahwa eksperimen di lingkungan hobi memang memberi ruang untuk salah langkah. Kehilangan feed pribadi bukan bencana besar, tetapi menjalankan perintah tanpa benar-benar memahami fungsinya tetap berisiko tinggi.
Ada juga pelajaran teknis yang lebih luas: jangan memperlakukan pembersihan storage sebagai alasan untuk menebak-nebak perintah Docker. Dengan cadangan yang tepat, aplikasi penting masih bisa dibangun ulang, sementara pengalaman buruk itu menjadi pengingat untuk lebih hati-hati saat memakai teknologi baru.
