Apakah aman menggunakan HDD saat rsync berjalan?


27

Saya berencana untuk mencadangkan HDD besar saya pada rsync, dan mengantisipasi bahwa dibutuhkan beberapa hari. Apakah aman menggunakan HDD asli (menambahkan file) saat rsyncsedang bekerja? Atau lebih baik membiarkan HDD tidak tersentuh sampai rsyncselesai?


1
Perhatikan bahwa "menggunakan" mungkin sesederhana membuka browser tanpa melakukan apa pun. Peramban cenderung menulis banyak hal acak di direktori data mereka. Dalam kasus terburuk, yang Anda dapatkan adalah cadangan yang tidak konsisten, yaitu saat memulihkan, Anda mungkin tidak dapat mengembalikan tab, bookmark Anda mungkin hilang (karena basis data rusak) atau sesuatu dengan urutan besarnya.
Jonas Schäfer

Jika Anda memiliki banyak data untuk dicadangkan, Anda mungkin ingin mempertimbangkan untuk memecah cadangan menjadi potongan-potongan kecil (sub-pohon). Kemudian, hanya bagian yang saat ini berjalan yang perlu dibuat se-statis mungkin - dan Anda dapat melihat bagian mana yang mengikuti perkembangan skrip Anda (dengan log, dll.). Karena ini bukan satu cadangan besar, beberapa bagian mungkin tidak selaras dengan yang lain, tetapi jika Anda menjalankan satu cadangan besar pada sistem live, itu akan tetap terjadi.
Joe

Jawaban:


34

Seperti yang telah ditunjukkan orang lain, aman untuk membaca dari disk sumber, atau menggunakan disk target di luar direktori target, ketika rsync sedang berjalan. Juga aman untuk membaca di dalam direktori target, terutama jika direktori target sedang diisi secara eksklusif oleh run rsync.

Yang umumnya tidak aman adalah menulis di dalam direktori sumber saat rsync berjalan. "Menulis" adalah segala sesuatu yang mengubah konten direktori sumber atau subdirektori apa pun darinya, jadi sertakan pembaruan file, penghapusan, pembuatan, dll.

Melakukannya tidak akan merusak apa pun, tetapi perubahan tersebut mungkin atau mungkin tidak benar-benar diambil oleh rsync untuk disalin ke lokasi target. Itu tergantung pada jenis perubahan, apakah rsync telah memindai direktori tertentu itu, dan apakah rsync telah menyalin file atau direktori yang dimaksud.

Namun, ada cara mudah untuk melakukannya: Setelah selesai, jalankan rsync lagi, dengan parameter yang sama. (Kecuali jika Anda memiliki beberapa parameter penghapusan yang funky; jika Anda melakukannya, maka berhati-hatilah.) Melakukannya akan memindai ulang sumber, dan mentransfer perbedaan yang tidak diambil selama proses awal.

Run kedua harus mentransfer hanya perbedaan yang terjadi selama run rsync sebelumnya, dan dengan demikian akan menyelesaikan lebih cepat. Dengan demikian, Anda dapat merasa bebas untuk menggunakan komputer secara normal selama menjalankan pertama, tetapi harus menghindari sebanyak mungkin membuat perubahan pada sumber selama menjalankan kedua. Jika Anda bisa, pertimbangkan untuk melakukan remount sistem file sumber hanya-baca sebelum memulai menjalankan rsync kedua. (Sesuatu seperti mount -o ro,remount /media/sourceharus dilakukan.)


7
Seseorang bahkan dapat melakukan putaran ketiga setelah putaran kedua: mungkin butuh waktu lebih sedikit ... ;-)
gerlos

5
@gerlos Pola tampaknya sedang muncul. Kedengarannya hampir seperti orang bisa terus menjalankan perintah rsync pada akhir setiap sesi penggunaan, dan dalam beberapa hari itu akan selesai dalam waktu singkat.
Monty Harder

5
@gerlos Jika Anda melakukan remount hanya-baca sebelum menjalankan rsync untuk kedua kalinya, itu tidak diperlukan dan cadangan akan semuanya kecuali dijamin konsisten sambil meminimalkan waktu selama Anda tidak dapat menulis ke sistem file sumber.
CVn

1
@gerlos Sebagai tambahan, itu sebabnya saya punya entri seperti @reboot root find / -print &>/dev/nulldi crontab sistem saya, untuk mengisi cache. (Entri yang sebenarnya lebih kompleks untuk menjelaskan beberapa kasus khusus pada sistem saya.) Menggunakan beberapa RAM dan beberapa waktu wallclock lebih awal setelah startup untuk meningkatkan pemindaian direktori-pohon sedikit IME.
CVn

1
@ MichaelKjörling: ide interresting untuk men-cache hierarki. Tapi mungkin Anda harus menjalankan updatedb(membangun basis data loc) atau slocate -u(sama, jika Anda memiliki slocate)? Dengan cara itu Anda masih men-cache hierarki tetapi Anda juga membangun basis data lokasi atau slocate, yang memungkinkan Anda menggunakan perintah-perintah itu untuk dengan cepat menemukan banyak file?
Olivier Dulac

22

Ini tergantung pada sistem cadangan yang Anda gunakan, tetapi secara umum itu adalah ide yang buruk untuk mengubah konten perangkat saat Anda mencadangkannya. Namun, Anda dapat membaca isinya; itu operasi yang aman, bahkan jika itu akan memperlambat proses.

Dalam kasus Anda, rsyncakan membangun daftar file dan kemudian memulai pencadangan. Karena itu file apa pun yang Anda tambahkan ke HDD sumber setelah pencadangan dimulai tidak akan disalin.

Apa yang saya lakukan adalah tidak menggunakan perangkat sama sekali selama cadangan. Ini adalah cara yang lebih aman untuk mendapatkan cadangan yang cepat dan konsisten.


14
Saya biasanya membiarkannya berjalan dan kemudian menjalankan yang kedua rsyncyang akan selesai dalam beberapa detik karena hanya file yang telah saya ubah selama menjalankan akan disalin. Semuanya akan ada dalam cache, jadi jauh lebih mudah untuk menahan diri dari modifikasi selama periode itu.
Martin Ueding

15

Aman untuk membaca data dari area sumber saat rsyncsedang beroperasi, tetapi jika Anda memperbarui apa pun, salinan yang rsyncmembuat / memperbarui kemungkinan tidak konsisten:

  1. Jika Anda memperbarui file yang telah dipindai rsync maka file tersebut tidak akan melihat pembaruan hingga dijalankan di masa mendatang. Jika Anda memperbarui file itu belum memindai perubahan akan dihormati di tujuan. Jika Anda memperbarui file yang keduanya telah dan belum dipindai Anda akan berakhir dengan campuran versi lama dan baru di tujuan.

  2. Jika Anda menambahkan file ke direktori yang telah dipindai, file tersebut akan hilang dari salinan tujuan kali ini. Jika Anda menghapus file dari direktori yang telah dipindai, file itu akan tersisa di salinan tujuan kali ini. Bergantung pada bagaimana Anda memohon rsyncseluruh pohon dapat dipindai pada awal atau mungkin dipindai secara bertahap ketika proses sinkronisasi terjadi.

  3. Dalam beberapa keadaan rsyncakan melihat ketidakkonsistenan dan memperingatkan Anda. Jika Anda menghapus file atau sub-direktori dari direktori yang telah dipindai sendiri tetapi belum dipindai isinya, Anda akan mendapatkan pesan kesalahan tentang objek yang hilang. Dalam keadaan yang sama kadang-kadang dapat (jika ukuran dan / atau stempel waktu telah berubah) juga memperingatkan tentang file yang mengubah mid-scan.

Untuk beberapa cadangan, ketidakkonsistenan ini mungkin bukan masalah besar, tetapi untuk sebagian besar akan sangat disarankan agar Anda tidak mencoba menyinkronkan sumber yang berubah secara aktif.

Jika Anda menggunakan LVM untuk membagi sistem penyimpanan Anda, Anda dapat menggunakan snapshot sementara untuk mengambil cadangan point-in-time. Ini mengharuskan Anda memiliki cukup ruang pada grup volume untuk membuat volume foto yang cukup besar untuk menampung semua perubahan yang akan terjadi selama durasi foto itu diperlukan. Periksa dokumentasi LVM (atau salah satu dari banyak contoh online: cari "backup snapshot LVM" atau yang serupa) untuk detail lebih lanjut.

Bahkan tanpa LVM beberapa sistem file mendukung snapshot sendiri - jadi Anda mungkin ingin melihat opsi itu juga.

Jika Anda ingin membuat cadangan volume aktif besar tanpa waktu henti yang lama dan tidak dapat menggunakan snapshot, mungkin cukup untuk menjalankan pemindaian "langsung" hingga selesai kemudian menghentikan akses ke volume dan menjalankan proses rsync lain yang mungkin memerlukan waktu jauh lebih sedikit (jika sangat sedikit yang berubah itu hanya akan memindai pohon direktori kemudian beberapa file yang diperbarui). Dengan cara ini, durasi di mana Anda harus menghindari perubahan bisa jauh lebih pendek.


Saya paling suka jawaban Anda karena Anda masuk ke detail tentang apa yang terjadi jika file diubah. Anda tidak hanya memberikan alternatif tetapi juga mengatasi ketidakkonsistenan yang dapat ditimbulkannya (melewatkan pembaruan, memperingatkan tentang file yang hilang, dll.). Dalam situasi saya, menggunakan rsync untuk membuat cadangan lama dan menyegarkannya beberapa hari kemudian bukan masalah besar, dan itu terdengar seperti situasi OP juga. Itu tidak terdengar seperti dia membutuhkan cadangan tingkat perusahaan saat pertama kali lewat, tetapi hanya ingin menggunakan komputer untuk sementara waktu. Saya katakan jalankan saja rsync untuk menangkap file yang diperbarui.
ibennetch

11
  • Sumber HDD dapat membaca apa pun saat rsync.

  • Sumber HDD dapat menulis konten apa pun yang tidak terkait dengan konten rsync.

  • HDD Tujuan dapat membaca apa pun saat rsync.

  • HDD Tujuan dapat menulis apa pun saat rsync dengan syarat memiliki ruang yang cukup dicadangkan untuk konten yang disinkronkan.

Tentu saja, dalam setiap kasus, akan ada pengurangan kinerja.


0

Semua jawaban saat ini berbicara tentang keamanan data dalam hal konsistensi dan mengasumsikan perangkat keras sempurna.

Satu hal yang perlu dipertimbangkan adalah keamanan perangkat keras itu sendiri. Jika Anda memiliki hard drive yang tidak didukung yang mungkin hampir gagal (Anda mungkin belum tahu) dan Anda sedang membuat cadangan komprehensif awal jangan menggunakannya. Jangan memasangkannya jika datanya kritis. Anda dapat menggunakan alat seperti dduntuk mengkloning disk sebagai perangkat blok. Apa yang Anda tidak ingin mencari kepala disk, dan mungkin menulis saat Anda mencoba membuat cadangan. Plus ddharus lebih cepat untuk cadangan awal karena hanya menyalin bit dalam urutan (Jika sebagian besar drive tidak penuh saya kira rsync akan menang dalam kasus awal juga).

Untuk backup incremental berikutnya rsync adalah pilihan yang bagus dan saya setuju dengan jawaban lainnya 100%.


1
Jika media marjinal atau bahkan berpotensi marjinal, ddbukan pilihan terbaik. Gunakan ddrescuesebaliknya; itu menangani kegagalan parsial jauh lebih baik. Tapi itu bukan pertimbangan dalam pertanyaan awal.
CVn

@ MichaelKjörling Itu poin bagus.
Zak
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.