Bermigrasi ke LVM


3

Drive di server media Ubuntu saya hampir penuh. Saya berharap untuk menambah 2TB kapasitas lain ke mesin dan akan lebih suka untuk semua 3,5 TB diakui sebagai drive tunggal. Untuk memperumit masalah, saya tidak ingin kehilangan data di drive atau harus mengkonfigurasi ulang program apa pun.

Rencana saya adalah menggunakan LVM untuk membuat grup volume pada drive baru dan gunakan dd untuk menyalin konten drive lama. Kemudian saya berencana untuk menghapus drive lama dan menambahkannya ke grup volume.

Apakah rencana ini akan berhasil?

Pertanyaan terbesar saya adalah: -Apakah saya akan dapat menyalin instalasi saya ke drive lain tanpa masalah? Bahkan jika ini adalah grup volume? -Apakah dd dapat menyalin drive 1,5TB ke drive 2TB dan membiarkan ruang yang tersisa kosong.

Jawaban:


4

Jika Anda sudah menggunakan LVM:

  • Pastikan disk baru dipasang dan dipartisi untuk LVM (beralih bit LVM)
  • Buat PV di disk baru ( pvcreate /dev/your-new-disk)
  • Perpanjang VG Anda untuk memasukkan PV baru ( vgextend your-volume-group /dev/your-new-disk)
  • pvmovedata Anda dari disk lama ke yang baru. Tidak perlu dd. ( pvmove /dev/your-old-diskakan memaksa LVM untuk memindahkan data dari disk lama ke disk lain yang tersedia.)

Jika Anda belum menggunakan LVM:

  • Buat PV dan VG pada disk baru.
  • Salin data Anda ke LV baru di VG baru.
    Saya akan menggunakan dump+ restorejika tersedia untuk sistem file Anda, tetapi Anda dapat menggunakan cpioatau taratau bahkan ddjika Anda mau.
  • Memformat disk lama, mengubahnya menjadi PV, menambahkannya ke VG.

Berikut ini adalah beberapa pendapat dan tidak ada hubungannya dengan LVM.

  • dump+ restore:
    • Beroperasi di perangkat blok mentah, sehingga sumber atimedll tidak terpengaruh dan tujuan ctimedll dapat diatur dengan benar.
    • Mempertahankan semua hardlink, dan harus memahami internal filesystem dengan cukup baik untuk mempertahankan semua atribut yang diperluas, kebijakan keamanan, dan metadata khusus sistem file lainnya.
    • Sumber dan tujuan dapat dari berbagai ukuran; hanya menyalin data yang digunakan.
    • Harus menjadi metode tercepat.
  • cpio/ tar/ rsync/ cp:
    • Beroperasi di sistem file yang terpasang, jadi sumber atimediubah, tujuan ctimetidak dapat dipertahankan, nomor inode berubah, dll.
    • Melestarikan hardlink membutuhkan menjaga semua inode yang dikenal dalam memori, dan mungkin atau mungkin tidak dilakukan dengan benar. Alat mungkin atau mungkin tidak memahami sistem file dengan cukup baik, atau memiliki hak istimewa, untuk mempertahankan atribut yang diperluas, kebijakan keamanan, dan metadata khusus sistem file lainnya.
      (Misalnya, ext4 mendukung cap waktu sub-milidetik, tetapi sejauh yang saya ketahui, tidak ada alat ini yang melestarikannya.)
    • Sumber dan tujuan dapat dari berbagai ukuran; hanya menyalin data tertentu.
    • Menghabiskan banyak waktu di syscalls ( stat, opendir, readdir, closedir, mkdir, open, read, write, close, ...).
  • dd:
    • Merupakan salinan tepat dari perangkat blok mentah.
    • Menyalin semua blok, apakah sedang digunakan atau tidak.
    • Gandakan semua struktur sistem file, termasuk hal-hal yang harus unik (seperti UUID).
      Tidak dapat memasang keduanya (secara default) pada saat yang sama pada sistem yang sama jika keduanya XFS.
    • Tidak dapat mengubah ukuran saat menyalin.
    • Relatif lambat jika sistem file tidak terlalu penuh.

Apa keuntungan menggunakan dump + restore over dd? Apakah saya akan berakhir dengan ruang yang tidak dapat digunakan jika menggunakan dump + restore ke disk yang lebih besar?
Evan Gillespie

dd bukan alat yang tepat untuk pekerjaan ini. Saya hanya menggunakan cp atau tar.
Flimzy
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.