rsync lewat VPN: percobaan ulang yang memakai ulang transfer yang rusak

Unggahan Anda macet di empat gigabyte dari arsip dua belas gigabyte, dan kebiasaan dari pengelola unduhan mengatakan tekan lanjutkan. rsync tidak akan melanjutkan aliran TCP, karena aliran itu sudah hilang bersama pengiriman ulang terakhir dari terowongan. Yang bisa dilakukannya adalah menyimpan byte yang sudah diterima dan memakainya sebagai dasar untuk percobaan berikutnya, sebuah mekanisme berbeda dengan seperangkat aturan berbeda. Flag yang Anda pilih menentukan apakah pemakaian ulang itu terjadi sama sekali.

Percobaan ulang membangun ulang keadaan, bukan melanjutkan aliran

Saat sesi SSH putus, di ujung jauh hanya tersisa apa yang sempat ditulis ke disk, dan tidak ada yang lain. Tidak ada token sesi untuk disambungkan kembali dan tidak ada nomor urut untuk diputar ulang. Jalankan berikutnya membuka koneksi baru, membaca sumbernya lagi, dan bertanya kepada penerima apa yang sudah dimilikinya.

Pertanyaan terakhir itulah sebabnya berkas sebagian layak disimpan. Salinan penerima memberi rsync sesuatu untuk dibandingkan, dan algoritme hanya mengirim perbedaan yang bisa dikenali. Ini masih transfer metadata baru dan satu lintasan baru atas sumber, jadi waktu yang dihemat sebanding dengan berapa banyak berkas yang cocok, bukan dengan sejauh mana koneksi sebelumnya berjalan. Jika penerima tidak menyimpan apa pun, percobaan berikutnya adalah salinan penuh, berapa pun gigabyte yang dipindahkan yang pertama.

Putuskan di mana fragmen yang bisa dipakai ulang tinggal

Perilaku bawaan menulis berkas sebagian di jalur tujuan, yang membuat arsip setengah tertulis terlihat dengan nama akhir. --partial-dir memindahkannya ke direktori pilihan Anda, dan manual menjelaskan direktori itu disimpan untuk dipakai sebagai data oleh transfer berikutnya. Nama relatif diselesaikan di bawah direktori tujuan, itu yang Anda inginkan ketika kedua ujung mungkin punya tata letak berbeda.

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

Urutan juga penting di tujuan: direktori sebagian perlu ruang yang cukup untuk fragmen, dan volume perlu ruang yang cukup juga untuk berkas jadi. Memenuhi volume tujuan di tengah transfer menghasilkan kegagalan yang tampak seperti masalah jaringan tetapi bukan, dan dapat meninggalkan fragmen yang disimpan dalam keadaan terpotong. Periksa ruang kosong di host penerima sebelum jalannya dimulai, bukan setelah gagal. Beberapa detik dengan df -h melalui jalur SSH yang sama adalah uji termurah yang mungkin atas rencana itu.

Izin adalah kekhawatiran yang lebih kecil tetapi nyata. Direktori sebagian yang bisa ditulis akun tak bertalian memungkinkan orang lain mengganti isi yang akan diperlakukan jalankan berikutnya sebagai sudah diterima. Simpan dalam kepemilikan akun transfer, dan jangan taruh di tempat yang dipakai layanan lain untuk menerbitkan.

Jalankan salinan yang sama, bukan yang lebih pintar

Pemakaian ulang hanya berlaku bila sumber dan tujuan masih menjelaskan objek yang sama. Jalur sama, nama sama, berkas sama. Mengganti nama sumber atau menunjuk direktori tujuan lain memulai perbandingan baru terhadap tidak ada yang berguna.

Jangan tambahkan --whole-file sambil mengharapkan perilaku delta. Opsi itu menyuruh rsync menyalin seluruh berkas tanpa perbandingan checksum bergulir, yang merupakan pilihan wajar pada tautan lokal cepat dan justru salah setelah unggahan jarak jauh yang gagal. --inplace juga mengubah cerita: ia menulis langsung ke berkas tujuan, jadi gangguan meninggalkan berkas yang mencampur isi lama dan baru tanpa fragmen terpisah untuk kembali.

Baris kemajuan melaporkan kemajuan agregat transfer. Itu bukan sinyal penyelesaian. Angka yang mencapai seratus persen selagi koneksi masih terbuka berarti data sudah didorong, bukan bahwa penerima sudah mengganti nama, menyinkronkan, atau menerima apa pun.

Terima objek hanya setelah cocok

Konfirmasikan status keluar lebih dulu, lalu bandingkan hasilnya daripada mempercayai tidak adanya galat. Pemeriksaan ukuran menangkap sebagian besar transfer terpotong; perbandingan checksum menangkap sisanya, dan keduanya murah dibanding menjalankan ulang unggahan.

Jika arsip diterbitkan proses hilir, buat proses itu menunggu berkas yang diterima. Fragmen tersimpan yang mendarat di direktori terpantau dengan nama akhir akan diambil pemindaian berikutnya, dan galat konsumen akan tentang masukan rusak, bukan tentang transfer yang tidak pernah selesai.

Biarkan sumber apa adanya sampai penerima mengonfirmasi. Membuat ulang arsip di antara percobaan mengubah dasar perbandingan, dan jalankan berikutnya entah mentransfer hampir semuanya atau menghasilkan berkas yang tidak cocok dengan sumber lama maupun baru.

Ketika tautan, bukan flag, yang menjadi batas

Overhead header dan protokol adalah satu biaya transfer, dan jarang yang menentukan berapa lama berkas besar butuh. Perilaku mulai ulang lebih penting: metode yang bertahan dari putus tanpa langkah manual memberi berkas yang bisa dipakai lebih cepat daripada metode lebih cepat yang harus mulai lagi. Penyimpanan di kedua ujung dan jalur autentikasi masuk dalam perbandingan yang sama.

Bandingkan jalur alternatif yang diizinkan dengan berkas yang sama dan tujuan yang sama, dan catat dari mana masing-masing mulai lagi setelah gangguan. Satu kolom itu memberi tahu Anda lebih banyak tentang unggahan dua belas gigabyte lewat VPN daripada kecepatan puncak apa pun yang diukur dalam uji singkat.