Uncovering the Causes of Corrupt Proxmox Backups: From ZSTD, GZIP, and PBS Digest Mismatches to Faulty RAM

Pendahuluan

Beberapa waktu terakhir saya mengalami masalah yang cukup membingungkan pada server Proxmox VE 8.x. Backup LXC Container ID 103 berulang kali gagal, bahkan setelah mencoba beberapa media penyimpanan dan metode backup yang berbeda.

Awalnya masalah terlihat seperti kerusakan file backup biasa. Backup ke Synology NAS menggunakan ZSTD gagal direstore karena checksum tidak cocok. Setelah itu saya mencoba backup ke TrueNAS menggunakan GZIP, tetapi hasilnya juga gagal dengan CRC error. Backup ke Proxmox Backup Server (PBS) pun tidak berhasil dan menghasilkan pesan:

Error: detected chunk with wrong digest.

Karena masalah muncul pada tiga media backup yang berbeda, dua algoritma kompresi yang berbeda, serta mode backup snapshot maupun stop, akhirnya saya melakukan troubleshooting secara sistematis.

Hasil akhirnya cukup mengejutkan: masalah utamanya bukan NAS, PBS, jaringan, maupun hard disk backup, tetapi memory subsystem pada server Proxmox.

Artikel ini mendokumentasikan seluruh proses troubleshooting, termasuk pengujian yang gagal, log error, asumsi yang ternyata salah, hingga bukti akhir setelah memory diganti.

---

1. Kondisi Server

Server Proxmox yang digunakan memiliki spesifikasi utama:

CPU       : Intel Core i9-9900K
Core      : 8 Core / 16 Thread
Motherboard: MSI MPG Z390 Gaming Pro Carbon
Proxmox VE: 8.3.x
Kernel    : Linux 6.8.12-4-pve
Boot Mode : EFI

Storage utama menggunakan:

Model      : Seagate SkyHawk ST4000VX007-2DT166
Capacity   : 4 TB
Interface  : SATA 6 Gb/s
LVM Thin   : pve-data

Container yang bermasalah:

CT ID      : 103
Root Disk  : /dev/pve/vm-103-disk-0
Disk Size  : 130 GB
Filesystem : ext4

Backup dilakukan ke beberapa tujuan:

Synology NAS
TrueNAS NFS
Proxmox Backup Server (PBS)

---

2. Masalah Pertama: Backup ZSTD di Synology Tidak Bisa Direstore

Backup awal dibuat otomatis ke Synology NAS dalam format:

vzdump-lxc-103-2026_08_04-21_06_39.tar.zst

Ketika direstore, Proxmox gagal dengan log:

recovering backed-up configuration from
'synology:backup/vzdump-lxc-103-2026_08_04-21_06_39.tar.zst'

Logical volume "vm-103-disk-0" created.

restoring 'synology:backup/vzdump-lxc-103-2026_08_04-21_06_39.tar.zst' now..

extracting archive
'/mnt/pve/synology/dump/vzdump-lxc-103-2026_08_04-21_06_39.tar.zst'

stdin: Decoding error (36) : Restored data doesn't match checksum

tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Logical volume "vm-103-disk-0" successfully removed.

TASK ERROR: unable to restore CT 103

Error terpenting adalah:

Restored data doesn't match checksum

Pada tahap ini dugaan awal adalah file .tar.zst rusak atau terdapat masalah saat penulisan backup ke Synology.

---

3. Mengganti ZSTD dengan GZIP: Tetap Gagal

Untuk memastikan masalah bukan berasal dari ZSTD, backup dibuat ulang ke TrueNAS menggunakan GZIP.

File yang dihasilkan:

vzdump-lxc-103-2026_08_05-09_23_04.tar.gz

Namun ketika direstore:

extracting archive
'/mnt/pve/truenas/dump/vzdump-lxc-103-2026_08_05-09_23_04.tar.gz'

gzip: stdin: invalid compressed data--crc error

tar: Child returned status 1
tar: Error is not recoverable: exiting now

Logical volume "vm-103-disk-0" successfully removed.

TASK ERROR: unable to restore CT 103

Artinya mengganti:

ZSTD → GZIP

tidak menyelesaikan masalah.

Hal ini mulai mengurangi kemungkinan bahwa algoritma kompresi adalah akar penyebab.

---

4. Memeriksa Integritas Backup GZIP

Backup TrueNAS kemudian diuji tanpa melakukan restore:

FILE="/mnt/pve/truenas/dump/vzdump-lxc-103-2026_08_05-09_23_04.tar.gz"

gzip -t -v "$FILE"
echo "Exit code: $?"

Hasil:

gzip: ... invalid compressed data--crc error

gzip: ... invalid compressed data--length error

Exit code: 1

Dengan demikian file GZIP memang terbukti tidak valid.

Ini bukan sekadar masalah proses restore Proxmox.

---

5. Temuan Aneh: SHA-256 File yang Sama Berubah

Kemudian saya menghitung SHA-256 dari file backup TrueNAS dua kali melalui mount NFS Proxmox:

sha256sum "$FILE"
sha256sum "$FILE"

Hasilnya:

87657446535e72a21d928facc330c8e00cdc6d074c4ae51e5b57d7e88668e214

274f10f0dee822acdf63e9549116a50397fb9d4e0617af41b08529b1a9718a63

Ini merupakan temuan penting.

File statis yang sama seharusnya menghasilkan SHA-256 yang sama setiap kali dibaca.

Saat itu kemungkinan penyebab menjadi lebih luas:

• TrueNAS/ZFS;

• jaringan/NFS;

• NIC;

• RAM Proxmox;

• RAM TrueNAS;

• disk;

• controller.

---

6. Memeriksa File Langsung dari TrueNAS

Untuk memastikan apakah file di TrueNAS berubah, pengujian dilakukan langsung dari shell TrueNAS.

Lokasi sebenarnya:

/mnt/pool1/192.168.22.2/dump/vzdump-lxc-103-2026_08_05-09_23_04.tar.gz

SHA-256 dihitung tiga kali:

FILE="/mnt/pool1/192.168.22.2/dump/vzdump-lxc-103-2026_08_05-09_23_04.tar.gz"

for i in 1 2 3; do
    echo "Tes ke-$i"
    sha256sum "$FILE"
done

Hasil:

90b6756942cb6975a5cdea8443dd219e224cad2c0d4eb4c65bc02b3500dade99

90b6756942cb6975a5cdea8443dd219e224cad2c0d4eb4c65bc02b3500dade99

90b6756942cb6975a5cdea8443dd219e224cad2c0d4eb4c65bc02b3500dade99

Ketiganya identik.

Artinya TrueNAS mampu membaca file tersebut secara konsisten.

Tetapi ketika diuji GZIP langsung di TrueNAS:

gzip -t -v "$FILE"

hasilnya:

gzip: ... invalid compressed data--crc error

Exit code: 1

Kesimpulan pada tahap ini:

File yang tersimpan di TrueNAS memang konsisten, tetapi file tersebut sudah dalam keadaan corrupt.

Dengan kata lain, TrueNAS tidak sekadar membaca file secara salah. Data yang ditulis ke sana memang sudah bermasalah.

---

7. Mencoba Proxmox Backup Server

Karena backup file tradisional bermasalah, saya mencoba PBS.

Namun backup juga gagal.

Contoh pertama:

INFO: processed 5.444 GiB in 6m, uploaded 5.327 GiB

INFO: unclosed encoder dropped
INFO: closed encoder dropped with state
INFO: unfinished encoder state dropped
INFO: finished encoder state with errors

INFO: catalog upload error - channel closed

INFO: Error: detected chunk with wrong digest.

ERROR: Backup of VM 103 failed

Percobaan berikutnya bahkan berjalan sampai sekitar 63 GB sebelum gagal:

INFO: processed 60.447 GiB in 31m, uploaded 53.508 GiB
INFO: processed 63.064 GiB in 32m, uploaded 55.58 GiB

INFO: unclosed encoder dropped
INFO: catalog upload error - channel closed

INFO: Error: detected chunk with wrong digest.

Error yang sama muncul:

detected chunk with wrong digest

Ini sangat relevan karena PBS menggunakan chunk dan digest untuk menjaga integritas data.

---

8. Mencoba Backup Mode Stop

Saya kemudian mempertanyakan apakah snapshot LVM menjadi penyebab.

Container dimatikan dan backup dilakukan dengan:

vzdump 103 \
  --storage proxmox_backup_server \
  --mode stop \
  --remove 0

Namun hasilnya tetap gagal:

INFO: backup mode: stop

INFO: processed 17.87 GiB in 9m, uploaded 16.693 GiB

INFO: unclosed encoder dropped
INFO: closed encoder dropped with state
INFO: unfinished encoder state dropped
INFO: finished encoder state with errors

INFO: catalog upload error - channel closed

INFO: Error: detected chunk with wrong digest.

ERROR: Backup of VM 103 failed

Dengan demikian:

Snapshot mode → gagal
Stop mode     → gagal

Snapshot LVM semakin kecil kemungkinannya sebagai akar masalah.

---

9. Benchmark PBS Ternyata Normal

Koneksi antara Proxmox dan PBS kemudian diuji:

proxmox-backup-client benchmark \
  --repository 'root@pam@192.168.22.43:backup-lokal'

Hasil:

Uploaded 156 chunks in 5 seconds.

TLS speed: 117.33 MB/s
SHA256 speed: 639.87 MB/s
Compression speed: 649.23 MB/s
Decompress speed: 934.46 MB/s
AES256/GCM speed: 4844.87 MB/s
Verify speed: 378.96 MB/s

Tidak terdapat:

wrong digest
I/O error
connection closed

Ini menunjukkan:

Koneksi dasar Proxmox → PBS dan fungsi SHA-256/compression dapat bekerja dengan baik pada benchmark singkat.

Karena itu PBS bukan tersangka utama lagi.

---

10. Menguji Logical Volume CT 103 Secara Langsung

Container 103 kemudian dimatikan:

pct stop 103

Logical volume dikonfirmasi:

lvs -o lv_path,lv_name,lv_size | grep vm-103-disk-0

Hasil:

/dev/pve/vm-103-disk-0 vm-103-disk-0 130.00g

Saya kemudian membaca 20 GiB pertama sebanyak tiga kali:

for i in 1 2 3; do
  echo "===== READ TEST $i ====="

  dd if=/dev/pve/vm-103-disk-0 \
     bs=4M count=5120 \
     status=none | sha256sum

done

Hasilnya mengejutkan:

===== READ TEST 1 =====
19c48465a8c73ce9782e6eee9f948bfb0cfb908466e47c044c3da1f6f56a1c43

===== READ TEST 2 =====
f96cce6c9257fe5075d2183fbcefbf335f5922fd8b6ce551af6486e44e01ac74

===== READ TEST 3 =====
3dbff03b8051fe8c79995883398e93a29094711131463c87b7e3e22fcf558be3

Padahal:

• CT berhenti;

• logical volume sama;

• blok disk yang dibaca sama;

• ukuran pembacaan sama.

Hash seharusnya identik.

Pada titik ini terbukti bahwa masalah sudah terjadi sebelum data mencapai PBS maupun NAS.

---

11. Memeriksa Hard Disk

Storage Proxmox ternyata menggunakan satu disk:

/dev/sda
ST4000VX007-2DT166
Seagate SkyHawk
4 TB

SMART kemudian diperiksa:

smartctl -x /dev/sda

Hasil utama:

SMART overall-health self-assessment test result: PASSED

Atribut kritis:

Reallocated_Sector_Ct = 0
Reported_Uncorrect = 0
Command_Timeout = 0
End-to-End_Error = 0
Current_Pending_Sector = 0
Offline_Uncorrectable = 0
UDMA_CRC_Error_Count = 0

SMART error log:

No Errors Logged

SATA interface CRC:

Number of Interface CRC Errors = 0

Temperatur sekitar:

31°C

Disk memang sudah memiliki sekitar:

Power_On_Hours = 64727 jam

atau lebih dari tujuh tahun operasional, sehingga usia disk tetap perlu menjadi perhatian.

Namun tidak ditemukan indikasi SMART klasik berupa bad sector, pending sector, uncorrectable sector, atau SATA CRC error.

SMART juga mencatat:

No Errors Logged

pada error log.

Dengan demikian hard disk belum dapat dinyatakan sebagai penyebab utama.

---

12. Direct I/O Menghasilkan Hash Konsisten

Pengujian logical volume kemudian diulang tetapi menggunakan direct I/O:

for i in 1 2 3; do

  echo "===== DIRECT READ TEST $i ====="

  dd if=/dev/pve/vm-103-disk-0 \
     bs=4M count=5120 \
     iflag=direct \
     status=none | sha256sum

done

Hasilnya:

===== DIRECT READ TEST 1 =====
10a6e5a3399c7ea9156768dda5c91f8dc4f9820c6fe739f2e08302ce0e5ed8c1

===== DIRECT READ TEST 2 =====
10a6e5a3399c7ea9156768dda5c91f8dc4f9820c6fe739f2e08302ce0e5ed8c1

===== DIRECT READ TEST 3 =====
10a6e5a3399c7ea9156768dda5c91f8dc4f9820c6fe739f2e08302ce0e5ed8c1

Ketiganya sama.

Ini menjadi titik balik diagnosis.

Secara sederhana:

Disk/LVM → Direct I/O → konsisten

Disk/LVM → Buffered I/O → tidak konsisten

Karena direct I/O mengurangi keterlibatan Linux page cache, perhatian mulai beralih sangat kuat ke memory subsystem.

---

13. Membersihkan Page Cache Tidak Menyelesaikan Masalah

Untuk memastikan bukan sekadar cache lama, dilakukan:

for i in 1 2 3; do

  echo "===== CLEAN CACHE TEST $i ====="

  sync
  echo 3 > /proc/sys/vm/drop_caches

  dd if=/dev/pve/vm-103-disk-0 \
     bs=4M count=5120 \
     status=none | sha256sum

done

Hasil:

TEST 1
fd1ad88221bfd69975376a4fe0e064a9ef862efd78aa9904b3fb83887128a7a5

TEST 2
c5f916eb1c361246d5dad2fcafa5a70ad883e95d21b2f2ea7cc718a11d99826f

TEST 3
b7f72fc37af413bc0d780fa4f949088864e76b1ef67cf2715322d46cb7b555b6

Ketiganya tetap berbeda.

Jadi bukan sekadar cache yang belum dibersihkan.

---

14. Kernel Menampilkan "Bad Page State"

Saat konfigurasi RAM diubah, server pernah menampilkan pesan kernel:

BUG: Bad page state in process swapper

Pesan seperti ini sangat relevan karena kernel mendeteksi kondisi page memory yang tidak semestinya.

Jika dikombinasikan dengan:

buffered SHA berbeda
direct SHA konsisten
PBS wrong digest
gzip CRC error
ZSTD checksum error

kecurigaan terhadap RAM atau memory subsystem menjadi semakin kuat.

---

15. Memtest86+ Memberikan Bukti Definitif

Server menggunakan motherboard:

MSI MPG Z390 Gaming Pro Carbon

dengan:

Intel Core i9-9900K
4 × Corsair 16 GB
Total 64 GB

Memtest86+ bawaan boot menu Proxmox kemudian dijalankan.

Belum sampai satu pass penuh, Memtest sudah menunjukkan:

Status: Failed!
Pass: 7%
Errors: 5953

Banyak error muncul pada alamat sekitar:

33.6 GiB
42.2 GiB

dan antara nilai yang seharusnya dibaca dengan nilai yang ditemukan terdapat perbedaan bit.

Contohnya secara konsep:

Expected: 0202020202020202
Found   : 02020a0202020202

Ini merupakan bukti langsung bahwa memory subsystem server tidak stabil.

Dengan ribuan error hanya pada sebagian kecil pengujian, backup yang melewati RAM tersebut memang tidak dapat dipercaya.

 

---

16. Mengapa Masalah RAM Bisa Menyebabkan Backup Corrupt?

Proses backup bukan sekadar:

Disk → NAS

Data melewati sejumlah tahap:

Disk
 ↓
Kernel
 ↓
RAM / Page Cache
 ↓
TAR/PXAR
 ↓
Compression / Chunking
 ↓
SHA / CRC / Digest
 ↓
Network
 ↓
NAS / PBS

Jika RAM menghasilkan bit yang salah pada salah satu tahap tersebut, data yang kemudian dikompresi atau dihitung checksum-nya juga dapat menjadi salah.

Akibatnya dapat muncul berbagai error yang tampaknya tidak berkaitan:

ZSTD:
Restored data doesn't match checksum

GZIP:
invalid compressed data--crc error

PBS:
detected chunk with wrong digest

Linux:
BUG: Bad page state

Padahal seluruhnya dapat berasal dari satu sumber yang sama: data di memory tidak stabil.

---

17. Mengapa Lokasi Error Backup Selalu Berbeda?

Backup PBS pernah gagal pada sekitar:

5 GiB
17–18 GiB
63 GiB

Jika masalahnya adalah satu file tertentu atau satu sektor disk tertentu, kegagalan biasanya cenderung muncul di lokasi yang relatif sama.

Tetapi error yang berpindah-pindah lebih konsisten dengan masalah intermiten seperti:

RAM
memory controller
motherboard
timing memory

daripada sebuah sektor HDD tertentu.

---

18. Setelah Memory Diganti, Backup Berhasil

Setelah konfigurasi memory bermasalah diganti/dikurangi dan Proxmox berjalan dengan konfigurasi RAM yang stabil, backup CT 103 kembali diuji ke PBS.

Yang menarik:

hard disk tidak diganti.

PBS tidak diganti.

CT 103 juga tetap sama.

Jaringan tetap sama.

Backup dijalankan menggunakan mode snapshot.

Lognya:

INFO: Starting Backup of VM 103 (lxc)

INFO: backup mode: snapshot

INFO: creating Proxmox Backup Server archive
'ct/103/2026-08-12T07:39:26Z'

Proses terus berjalan:

INFO: processed 30.171 GiB in 15m
INFO: processed 45.373 GiB in 21m
INFO: processed 60.433 GiB in 27m
INFO: processed 75.576 GiB in 33m
INFO: processed 88.559 GiB in 38m
INFO: processed 92.615 GiB in 41m

Kemudian:

INFO: root.pxar: had to backup 82.95 GiB of 94.603 GiB
(compressed 70.859 GiB)
in 2515.61 s
(average 33.766 MiB/s)

INFO: root.pxar: backup was done incrementally,
reused 11.653 GiB (12.3%)

INFO: Uploaded backup catalog (4.517 MiB)

INFO: Duration: 2518.13s

INFO: End Time: Wed Aug 12 16:21:24 2026

INFO: cleanup temporary 'vzdump' snapshot

Logical volume "snap_vm-103-disk-0_vzdump"
successfully removed.

INFO: Finished Backup of VM 103 (00:42:07)

INFO: Backup job finished successfully

TASK OK

Ini merupakan bukti A/B paling kuat dalam troubleshooting ini.

Sebelumnya:

RAM bermasalah
+
HDD yang sama
=
backup gagal

Sesudah perubahan memory:

RAM stabil
+
HDD yang sama
=
backup sukses 94+ GiB

Karena variabel storage utama tidak berubah, memory subsystem menjadi akar masalah yang paling kuat berdasarkan seluruh bukti yang ada.

 

---

19. Hubungan dengan Grey Question Mark (?) di Proxmox

Masalah lain yang pernah muncul adalah seluruh node, VM, dan LXC menampilkan tanda tanya abu-abu di dashboard Proxmox.

Biasanya tampilan dapat dipulihkan dengan:

systemctl restart pvestatd

Namun penting untuk membedakan gejala dan akar penyebab.

Grey question mark tidak secara otomatis berarti RAM rusak.

Tampilan tersebut dapat terjadi ketika daemon status Proxmox tidak mampu mendapatkan informasi resource secara normal, misalnya karena:

storage timeout
NFS lambat
service hang
I/O tersendat
backup process stuck
kernel problem

Pada kasus saya, memory corruption sangat mungkin menjadi salah satu pemicu upstream yang membuat backup atau proses sistem gagal secara abnormal.

---

20. Hubungan dengan Error "Snapshot Already Exists"

Masalah yang pernah muncul:

Logical Volume
"snap_vm-103-disk-0_vzdump"
already exists

Ini berarti snapshot sementara dari operasi sebelumnya masih ada.

Cara memeriksa:

lvs

Jika benar ada snapshot sisa seperti:

snap_vm-103-disk-0_vzdump

maka setelah memastikan tidak ada proses backup aktif, snapshot dapat dihapus:

lvremove /dev/pve/snap_vm-103-disk-0_vzdump

Untuk LXC yang terkunci:

pct unlock 103

Untuk VM:

qm unlock <VMID>

Namun perlu ditegaskan:

snapshot already exists bukan bukti bahwa RAM rusak.

Snapshot tertinggal merupakan efek dari proses sebelumnya yang tidak menyelesaikan cleanup secara normal.

Dalam kasus ini alur yang mungkin terjadi adalah:

Memory tidak stabil
        ↓
backup mengalami error/crash
        ↓
cleanup tidak selesai
        ↓
snapshot sementara tertinggal
        ↓
backup berikutnya mencoba nama snapshot yang sama
        ↓
"snapshot already exists"

Jadi snapshot tertinggal adalah efek lanjutan, bukan akar masalah.

---

21. Mengapa Restart pvestatd Bukan Solusi Permanen?

Ketika GUI menjadi tanda tanya, menjalankan:

systemctl restart pvestatd

memang dapat membuat GUI kembali normal.

Tetapi tindakan tersebut hanya memperbaiki daemon status.

Jika penyebab sebenarnya adalah:

RAM error
storage timeout
backup stuck
kernel error

maka masalah dapat kembali.

Karena itu troubleshooting tidak boleh berhenti setelah GUI kembali hijau.

---

22. Urutan Troubleshooting yang Lebih Tepat

Berdasarkan pengalaman ini, ketika backup Proxmox berulang kali mengalami checksum error, sebaiknya jangan langsung mengganti algoritma kompresi atau menyalahkan NAS.

Gunakan alur berikut.

Langkah 1 — Uji Backup

Untuk GZIP:

gzip -t -v backup.tar.gz

Untuk ZSTD:

zstd -t -v backup.tar.zst

Jika gagal, backup jangan dianggap valid.

---

Langkah 2 — Hitung SHA-256 Beberapa Kali

sha256sum backup-file
sha256sum backup-file
sha256sum backup-file

File statis harus menghasilkan hash identik.

---

Langkah 3 — Uji dari Storage Aslinya

Jika file berada pada NAS, hitung checksum langsung di NAS.

Jangan hanya melalui NFS/SMB client.

---

Langkah 4 — Uji PBS

proxmox-backup-client benchmark \
  --repository 'USER@REALM@IP:DATASTORE'

Jika benchmark sehat tetapi backup besar gagal wrong digest, masalah mungkin berada sebelum atau selama pembentukan stream backup.

---

Langkah 5 — Uji Logical Volume secara Langsung

Dengan VM/CT berhenti:

dd if=/dev/pve/vm-103-disk-0 \
   bs=4M count=5120 \
   status=none | sha256sum

Ulangi tiga kali.

Hash harus sama.

---

Langkah 6 — Bandingkan dengan Direct I/O

dd if=/dev/pve/vm-103-disk-0 \
   bs=4M count=5120 \
   iflag=direct \
   status=none | sha256sum

Jika:

Buffered read → berbeda
Direct read   → sama

memory/page-cache path harus menjadi tersangka utama.

---

Langkah 7 — Periksa SMART

smartctl -x /dev/sda

Perhatikan:

Reallocated_Sector_Ct
Current_Pending_Sector
Offline_Uncorrectable
Reported_Uncorrect
UDMA_CRC_Error_Count
Command_Timeout

Jangan mengganti disk hanya karena backup corrupt apabila belum ada bukti disk yang mendukung diagnosis tersebut.

---

Langkah 8 — Jalankan Memtest86+

Jika Proxmox boot menu menyediakan Memtest86+, gunakan itu.

Tidak perlu USB tambahan.

Satu saja error sudah berarti memory subsystem tidak boleh dipercaya untuk workload produksi.

Jika banyak DIMM terpasang dan terjadi error, lakukan isolasi:

DIMM #1 → satu slot yang sama → test
DIMM #2 → satu slot yang sama → test
DIMM #3 → satu slot yang sama → test
DIMM #4 → satu slot yang sama → test

Dengan cara ini kita dapat membedakan:

DIMM rusak
slot bermasalah
motherboard bermasalah
memory controller CPU bermasalah
konfigurasi multi-DIMM tidak stabil

---

23. Jangan Mengandalkan "TASK OK" Saja

Backup sukses merupakan langkah pertama.

Untuk PBS, backup sebaiknya dilanjutkan dengan Verify dari datastore PBS.

Alurnya:

Datastore
→ Content
→ ct/103
→ pilih snapshot terbaru
→ Verify

Target:

Verification successful

Prinsipnya sederhana:

Backup yang belum pernah diuji integritasnya belum layak dianggap sebagai backup yang dapat diandalkan.

---

24. Kondisi Hard Disk Belum Bisa Disebut 100% Sehat

Walaupun kasus ini sangat kuat mengarah ke memory, bukan berarti HDD otomatis dinyatakan sempurna.

Pada disk saya:

SMART = PASSED
Bad sector = 0
Pending sector = 0
Uncorrectable = 0
SATA CRC = 0

tetapi umur operasinya sudah lebih dari:

64.000 jam

Karena itu langkah berikutnya tetap menjalankan:

smartctl -t short /dev/sda

dan kemudian:

smartctl -t long /dev/sda

Hasilnya harus diperiksa dengan:

smartctl -l selftest /dev/sda

Jadi kesimpulan yang tepat bukan:

“HDD pasti sehat.”

Tetapi:

“Sampai titik troubleshooting ini, belum ditemukan bukti SMART atau pengujian I/O yang menunjukkan HDD sebagai sumber utama corruption.”

---

25. Kesimpulan Akhir

Kasus ini menunjukkan mengapa troubleshooting infrastruktur tidak boleh berhenti pada pesan error paling depan.

Awalnya terlihat sebagai:

backup ZSTD corrupt

Kemudian:

backup GZIP corrupt

Lalu:

PBS wrong digest

Sehingga sangat mudah menyalahkan:

Synology
TrueNAS
NFS
PBS
ZSTD
GZIP
HDD

Namun setelah dilakukan pengujian berlapis:

TrueNAS membaca file secara konsisten
PBS benchmark berhasil
SMART HDD bersih
Direct disk read konsisten
Buffered read tidak konsisten
Kernel menunjukkan Bad Page State
Memtest86+ menemukan ribuan error

akar masalah akhirnya mengarah sangat kuat ke memory subsystem server Proxmox.

Setelah memory bermasalah diganti/dikeluarkan dari konfigurasi, dengan:

HDD yang sama
PBS yang sama
CT yang sama
jaringan yang sama

backup berhasil selama lebih dari 42 menit dan selesai dengan:

TASK OK

Pelajaran terbesar dari kasus ini:

RAM yang tidak stabil tidak selalu menyebabkan server langsung crash.

Server bisa tetap:

boot normal
GUI normal
VM berjalan
SSH bisa digunakan
website tetap hidup

tetapi secara diam-diam menghasilkan bit error yang kemudian terlihat sebagai:

CRC error
checksum mismatch
wrong digest
corrupted archive
Bad page state
backup tidak bisa direstore

Itulah alasan mengapa integritas memory harus menjadi bagian dari troubleshooting ketika beberapa media backup dan beberapa metode kompresi mengalami corruption yang tidak konsisten.

---

Ringkasan Diagnosis

Pengujian	Hasil
Restore ZSTD Synology	❌ Checksum mismatch
Restore GZIP TrueNAS	❌ CRC error
gzip -t TrueNAS	❌ CRC error
SHA file via Proxmox/NFS	❌ Berubah-ubah
SHA langsung di TrueNAS	✅ Konsisten
PBS snapshot backup	❌ Wrong digest
PBS stop-mode backup	❌ Wrong digest
PBS benchmark	✅ Normal
Buffered raw disk read	❌ Hash berubah
Direct raw disk read	✅ Hash konsisten
Drop-cache + buffered read	❌ Hash berubah
SMART HDD	✅ Tidak ada error kritis
Kernel	❌ Bad page state
Memtest86+	❌ Ribuan memory error
Backup setelah perubahan RAM	✅ TASK OK

Kesimpulan

Akar masalah paling kuat: memory subsystem yang tidak stabil.

Hard disk: belum ditemukan bukti sebagai penyebab corruption, tetapi karena usia operasionalnya tinggi, extended SMART test tetap wajib dilakukan.

Snapshot tertinggal dan grey question mark di Proxmox: lebih tepat dipandang sebagai gejala/efek lanjutan dari proses yang gagal atau hang, bukan langsung sebagai akar masalah.

Subscribe to receive free email updates: