Backup cloud lambat lewat VPN: temukan fase yang sebenarnya

Backup yang merangkak lewat VPN mengundang eksperimen yang jelas: putuskan tunnel lalu ukur lagi. Eksperimen itu sering menjawab pertanyaan lain, karena tugasnya mungkin sedang menghitung hash file atau menunggu percobaan ulang alih-alih memindahkan byte. Pisahkan fasenya lebih dulu, dan keluhan berubah menjadi uji spesifik dengan hasil yang diharapkan spesifik. Rute baru menjadi kandidat ketika fase transferlah yang benar-benar lambat.

Di fase mana tugas itu berada saat terasa lambat

Alat backup melewati fase-fase: menemukan file, membacanya dan menghitung hash, mengompresi, mengenkripsi, mengunggah, lalu memverifikasi. Setiap fase punya hambatannya sendiri, dan hanya sebagian yang menyentuh jaringan sama sekali. Alat yang belum melaporkan fase apa pun memberi tahu Anda bahwa alat itu belum selesai memindai.

Tugas yang menghabiskan dua puluh menit menyiapkan sejuta file kecil tidak akan lebih cepat ketika tunnel menjadi lebih cepat. Tugas yang memenuhi tautan unggah adalah masalah kapasitas dengan solusi berbeda. Baca keluaran kemajuan selama penundaan terjadi, catat fasenya, dan tuliskan stempel waktunya, karena fase pada saat keluhan hanyalah satu-satunya yang penting. File kecil juga berperilaku berbeda dari satu objek besar, karena perjalanan bolak-balik per file mendominasi dan transfer tidak pernah mencapai laju yang stabil. Bandingkan hal yang sebanding sebelum menarik kesimpulan tentang tunnel.

Endpoint publik dan NAS privat gagal dengan cara berbeda

Layanan backup publik membawa koneksi aplikasi terautentikasinya sendiri, dan tunnel hanyalah satu lompatan pada jalur yang lebih panjang. NAS privat biasanya bergantung pada tunnel itu untuk keterjangkauan dasar ke jaringan Anda. Perbedaan itulah yang menentukan apakah memutus koneksi merupakan garis dasar yang sah atau uji atas ketiadaan.

Pada kasus publik, tugas yang sama melalui rute lain bisa menjadi perbandingan yang adil bila kebijakan mengizinkan. Pada kasus privat, menghapus tunnel tidak menyisakan rute sama sekali ke server, jadi hasilnya menggambarkan jalur yang Anda hapus, bukan yang Anda gunakan.

Berhenti mendadak adalah kegagalan yang berbeda dari transfer lambat

Kolom ketiga tabel itu menentukan apakah uji stabilitas dapat dijalankan sama sekali, karena garis dasar yang menghapus tunnel hanya bermakna di tempat ada jalur lain. Dengan garis dasar yang bisa dipakai, perhatikan bentuk kegagalannya, bukan laju rata-ratanya. Unggahan rendah tetapi mantap menunjuk ke kapasitas, sedangkan tugas yang berhenti lalu mulai ulang menunjuk ke gangguan, autentikasi, atau satu file yang bermasalah. Keduanya menghasilkan keluhan yang hampir sama dan perbaikan yang sangat berbeda.

Percobaan ulang mendistorsi setiap pengukuran, karena byte di jaringan bisa lebih besar daripada jumlah yang benar-benar berubah. Baca perilaku melanjutkan sebelum menghentikan tugas lagi untuk melihat apa yang terjadi, karena unggahan terpotong yang bisa dilanjutkan pulih dengan murah dan mulai ulang seluruh file tidak. Tunnel yang menyambung ulang setiap beberapa menit juga tampak seperti masalah bandwidth padahal sebenarnya masalah stabilitas. MTU jalur memperparahnya, karena tunnel yang mengurangi muatan berguna menghentikan segmen besar sementara yang kecil lewat.

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

Satu unggahan dapat membuat semua aliran lain kelaparan

Unggahan yang memenuhi tautan unggah membuat panggilan dan penjelajahan tidak responsif, dan backup jarang menjadi satu-satunya yang bersaing untuknya. Klien sinkronisasi kedua menimbulkan gejala yang sama sendiri. Sebelum menyalahkan tunnel, lihat apa lagi yang sedang mengunggah.

Gunakan jadwal atau batas bandwidth yang didokumentasikan alat alih-alih berebut puncak throughput; menyisakan ruang untuk pekerjaan interaktif biasanya lebih berharga daripada beberapa persen terakhir. Lalu periksa apa yang sebenarnya dikenai batas itu, karena sebagian alat membatasi per file, sebagian seluruh proses, dan sebagian lagi mengabaikan biaya file kecil sama sekali. Batas yang tidak cocok dengan beban kerja tidak mengubah apa pun. Split tunneling juga patut dicurigai di sini, karena mengecualikan peluncur dari tunnel tidak mengecualikan layanan pembantu yang melakukan unggahan. Rclone, misalnya, menerbitkan batas transfer dan perilaku percobaan ulang di dokumentasinya, yang menjadikannya rujukan berguna tentang apa yang seharusnya dikendalikan batas.

Akhiri dengan pemulihan, bukan uji kecepatan

Unggahan yang selesai bukan backup sampai ada yang dipulihkan darinya. Pastikan versi yang diharapkan ada, lalu pulihkan file perwakilan dengan prosedur yang didokumentasikan alat. Simpan informasi pemulihan di tempat selain mesin atau profil yang mungkin Anda kehilangan, dan jangan pernah membuang backup yang berfungsi hanya agar eksperimen tetap rapi.

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

Ulangi transfer dan pemulihan setelah perubahan jaringan, agar peningkatannya terbukti melayani backup dan bukan sekadar memindahkan data lebih cepat. Proses kedua itulah yang menutup tiket. Transfer lebih cepat dengan pemulihan yang belum diuji adalah cara lebih lambat untuk tetap tanpa perlindungan.