Utilitas pencadangan Linux untuk pencadangan tambahan

Meskipun tar memang memiliki mode inkremental, ada beberapa alat yang lebih komprehensif untuk melakukan pekerjaan itu:

• Duplikasi
• Duplikat

Mereka tidak hanya mendukung pencadangan inkremental, tetapi juga mudah untuk mengonfigurasi jadwal di mana pencadangan lengkap perlu dilakukan. Misalnya di duplicity :duplicity --full-if-older-than 1M akan memastikan pencadangan penuh telah berjalan. Mereka juga mendukung kembali ke masa lalu ke file tertentu, dengan tar biasa Anda harus menelusuri semua file inkremental sampai Anda menemukan file yang berisi file yang tepat.

Selain itu, mereka mendukung enkripsi dan mengunggah ke berbagai backend (seperti sftp, penyimpanan blob, dll). Tentunya jika Anda mengenkripsi, jangan lupa untuk membuat cadangan yang baik dari kunci Anda ke cadangan sekunder!

Aspek penting lainnya adalah Anda dapat memverifikasi integritas cadangan Anda, memastikan Anda dapat memulihkan, misalnya menggunakan duplicity verify .

Saya akan memberikan saran negatif tentang strategi cadangan berbasis git. Pemulihan besar membutuhkan waktu yang signifikan.

Saya mencoba rsync, tetapi tampaknya tidak dapat melakukan apa yang saya inginkan, atau kemungkinan besar, saya tidak tahu cara melakukannya.

Saya tahu saya mungkin dapat membuat skrip yang menjalankan diff dan kemudian memilih file untuk dicadangkan berdasarkan hasil (atau lebih efisien, dapatkan checksum dan bandingkan), tetapi saya ingin tahu apakah ada utilitas yang dapat melakukan ini a sedikit lebih mudah :)

rsync justru program yang disalin berdasarkan diff. Secara default, ini hanya menyalin ketika ada perbedaan dalam waktu atau ukuran yang terakhir diubah, tetapi bahkan dapat membandingkan dengan checksum dengan -c .

Masalahnya di sini adalah Anda tar membuat cadangan. Ini menjadi lebih mudah jika Anda tidak melakukan itu. Aku bahkan tidak tahu mengapa kau melakukannya. Mungkin masuk akal jika Anda mengompresnya, tetapi Anda bahkan tidak melakukannya.

Artikel Wikipedia untuk Incremental Backups memiliki contoh rsync perintah yang kira-kira berbunyi:

rsync -va \
  --link-dest="$dst/2020-02-16--05-10-45--testdir/" \
  "$src/testdir/" \
  "$dst/2020-02-17--03-24-16--testdir/"

Apa yang dilakukannya adalah menautkan file dari cadangan sebelumnya ketika tidak berubah dari sumbernya. Ada juga --copy-dest jika Anda ingin menyalinnya (masih lebih cepat saat $dst adalah remote atau pada drive yang lebih cepat).

Jika Anda menggunakan sistem file dengan subvolume seperti btrf, Anda juga dapat mengambil snapshot dari cadangan sebelumnya sebelum melakukan rsync. Snapshot bersifat instan dan tidak memakan ruang tambahan[1].

btrfs subvolume snapshot \
  "$dst/2020-02-16--05-10-45--testdir" \
  "$dst/2020-02-17--03-24-16--testdir"

Atau jika Anda menggunakan sistem file yang mendukung reflink, seperti ext4, Anda juga dapat melakukannya. Reflink dilakukan dengan membuat inode baru tetapi mengacu pada blok yang sama dengan file sumber, mengimplementasikan dukungan COW. Ini masih lebih cepat daripada penyalinan biasa karena tidak membaca dan menulis data, dan juga tidak memerlukan ruang tambahan[1].

cp --reflink -av \
  "$dst/2020-02-16--05-10-45--testdir" \
  "$dst/2020-02-17--03-24-16--testdir"

Lagi pula, setelah melakukan hal seperti itu, Anda bisa melakukan rsync biasa untuk menyalin perbedaan:

rsync -va \
  "$src/testdir/" \
  "$dst/2020-02-17--03-24-16--testdir/"

Padahal, Anda mungkin ingin menambahkan --delete , yang akan menyebabkan rsync menghapus file dari tujuan yang tidak lagi ada di sumber.

Pilihan lain yang berguna adalah -i atau --itemize-changes . Ini menghasilkan output yang ringkas dan dapat dibaca mesin yang menjelaskan perubahan apa yang dilakukan rsync. Saya biasanya menambahkan opsi itu dan pipa seperti:

rsync -Pai --delete \
  "$src/testdir/" \
  "$dst/2020-02-17--03-24-16--testdir/" \
|& tee -a "$dst/2020-02-17--03-24-16--testdir.log"

untuk mencatat perubahan melalui grep dengan mudah file yang bisa. |& adalah mem-pipe stdout dan stderr.

-P adalah singkatan dari --partial dan --progress . --partial menyimpan file yang ditransfer sebagian, tetapi yang lebih penting --progress melaporkan kemajuan per file.

Bagaimana hal ini dibandingkan dengan mengarsipkan perubahan dengan tar

Solusi di atas menghasilkan direktori yang tampaknya menyimpan segalanya. Meskipun demikian, secara total untuk jumlah/frekuensi cadangan apa pun, mereka akan menempati jumlah ruang yang sama dengan memiliki arsip tar biasa dengan hanya perubahan. Itu karena cara kerja hardlink, reflink, dan snapshot. Penggunaan bandwidth saat membuat cadangan juga akan sama.

Keuntungannya adalah:

• cadangan mudah dipulihkan dengan rsync dan lebih cepat, karena rsync hanya akan mentransfer perbedaan dari cadangan.
• mereka lebih mudah untuk dijelajahi dan dimodifikasi jika diperlukan.
• penghapusan file dapat dikodekan secara alami karena file tidak ada dalam cadangan baru. Saat menggunakan arsip tar, seseorang harus menggunakan peretasan, seperti menghapus file foo , tandai foo.DELETED atau melakukan sesuatu yang rumit. Saya tidak pernah menggunakan duplikasi misalnya, tetapi melihat dokumentasinya, sepertinya itu mengkodekan penghapusan dengan menambahkan file kosong dengan nama yang sama di tar baru dan menahan tanda tangan asli file tersebut di file .sigtar terpisah. Saya membayangkan ini membandingkan tanda tangan asli dengan file kosong untuk membedakan antara penghapusan file dan perubahan ke file kosong yang sebenarnya.

Jika seseorang masih ingin mengatur setiap cadangan karena hanya menyimpan file yang berbeda (ditambahkan atau dimodifikasi), maka seseorang dapat menggunakan --link-dest solusi yang dijelaskan di atas dan kemudian hapus hardlink menggunakan sesuatu seperti berikut:

find $new_backup -type f ! -links 1 -delete

[1] Sebenarnya, mereka menggunakan ruang tambahan dalam bentuk duplikat metadata, seperti nama file dan semacamnya. Namun, saya pikir siapa pun akan menganggap itu tidak penting.

Dan mengapa Anda tidak mempertimbangkan git diri?

Strategi yang Anda jelaskan, setelah satu pencadangan penuh dan dua pencadangan tambahan, memiliki kerumitan saat Anda melanjutkan. Membuat kesalahan itu mudah, dan bisa menjadi sangat tidak efisien, tergantung pada perubahan. Harus ada semacam rotasi, yaitu dari waktu ke waktu Anda membuat cadangan lengkap yang baru - lalu apakah Anda ingin mempertahankan yang lama atau tidak?

Diberikan bekerja dir "testdir" berisi beberapa proyek (file, dan subdirektori), git membuat secara default .git tersembunyi subdirektori untuk data. Itu untuk kontrol versi tambahan lokal fitur. Untuk pencadangan, Anda dapat mengarsipkan/menyalinnya ke media atau mengkloningnya melalui jaringan.

kontrol revisi Anda dapatkan (tanpa meminta) adalah efek samping dari penyimpanan diferensial git.

Anda dapat meninggalkan semua percabangan/percabangan dan sebagainya. Ini berarti Anda memiliki satu cabang yang disebut "master".

Sebelum Anda dapat melakukan (sebenarnya menulis ke arsip/repo git), Anda harus mengonfigurasi pengguna minimal untuk file konfigurasi. Maka Anda harus mempelajari dan menguji terlebih dahulu di subdirektori (mungkin tmpfs). Git terkadang sama rumitnya dengan tar.

Bagaimanapun, seperti yang dikatakan komentar:mencadangkan itu mudah, bagian yang sulit adalah memulihkan.

Kerugian dari git hanya akan menjadi overhead/overkill yang kecil.

Keuntungannya adalah:git trek konten dan nama file. Ini hanya menyimpan apa yang diperlukan, berdasarkan diff (setidaknya untuk file teks).

Contoh

Saya punya 3 file di dir. Setelah git init , git add . dan git commit Saya memiliki 260K .git dir.

Lalu saya cp -r .git /tmp/abpic.git (tempat yang bagus untuk menyimpan cadangan :). saya rm jpg 154K, dan juga ubah satu file teks. Saya juga rm -r .git .

  ]# ls
    atext  btext

  ]# git --git-dir=/tmp/abpic.git/ ls-files
    atext
    btext
    pic154k.jpg

Sebelum memulihkan file, saya bisa mendapatkan perbedaan yang tepat:

]# git --git-dir=/tmp/abpic.git/ status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   atext
        deleted:    pic154k.jpg

no changes added to commit (use "git add" and/or "git commit -a")

Di sini saya ingin mengikuti git restore petunjuk.

Setelah git --git-dir=/tmp/abpic.git/ restore \* :

]# ls -st
total 164
  4 atext  156 pic154k.jpg    4 btext

jpeg kembali, dan file teks btext tidak telah diperbarui (menjaga stempel waktu). Modifikasi di atext ditimpa.

Untuk menyatukan kembali repo dan dir (berfungsi), Anda cukup menyalinnya kembali.

]# cp -r /tmp/abpic.git/ .git
]# git status
On branch master
nothing to commit, working tree clean

File di direktori saat ini identik dengan .git arsip (setelah restore ). Perubahan baru akan ditampilkan dan dapat ditambahkan dan dilakukan, tanpa perencanaan apa pun. Anda hanya perlu menyimpannya ke media lain, untuk tujuan cadangan.

Setelah file dimodifikasi, Anda dapat menggunakan status atau diff :

]# echo more >>btext 

]# git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   btext

no changes added to commit (use "git add" and/or "git commit -a")

]# git diff
diff --git a/btext b/btext
index 96b5d76..a4a6c5b 100644
--- a/btext
+++ b/btext
@@ -1,2 +1,3 @@
 This is file b
 second line
+more
#]

Dan seperti git tahu tentang "+lebih" di file 'btext', itu juga hanya akan menyimpan baris itu secara bertahap.

Setelah git add . (atau git add btext ) status perintah beralih dari merah ke hijau dan commit memberi Anda info.

]# git add .
]# git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   btext

]# git commit -m 'btext: more'
[master fad0453] btext: more
 1 file changed, 1 insertion(+)

Dan Anda benar-benar bisa mendapatkan isinya, entah bagaimana caranya:

]# git ls-tree @
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf    atext
100644 blob a4a6c5bd3359d84705e5fd01884caa8abd1736d0    btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d    pic154k.jpg

Dan kemudian 4 digit hash hex pertama

]# git cat-file blob a4a6
This is file b
second line
more

Untuk melakukan perjalanan kembali ke masa lalu dengan satu komit adalah:

]# git ls-tree @^
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf    atext
100644 blob 96b5d76c5ee3ccb7e02be421e21c4fb8b96ca2f0    btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d    pic154k.jpg

]# git cat-file blob 96b5
This is file b
second line

gumpalan btext memiliki hash yang berbeda sebelum komit terakhir, yang lain memiliki hash yang sama.

Ikhtisarnya adalah:

]# git log
commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4 (HEAD -> master)
Author: Your Name <[email protected]>
Date:   Sun Feb 16 10:51:51 2020 +0000

    btext: more

commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <[email protected]>
Date:   Sun Feb 16 08:45:16 2020 +0000

    added 3 files with 'add .'

Alih-alih file tar yang diberi cap waktu secara manual, Anda telah melakukan dengan pesan dan tanggal (dan penulis). Secara logis terlampir pada komit ini adalah daftar file dan konten.

git sederhana 20% lebih rumit daripada tar , tetapi Anda mendapatkan fungsionalitas 50% lebih banyak darinya.

Saya ingin membuat perubahan ketiga OP:mengubah file ditambah dua file 'gambar' baru. Ya, tapi sekarang saya punya:

]# git log
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <[email protected]>
Date:   Sun Feb 16 17:56:18 2020 +0000

    didn't add the pics before :(

commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <[email protected]>
Date:   Sun Feb 16 17:54:03 2020 +0000

    Two new picture files
    Had to change btext...

commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4
Author: Your Name <[email protected]>
Date:   Sun Feb 16 10:51:51 2020 +0000

    btext: more

commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <[email protected]>
Date:   Sun Feb 16 08:45:16 2020 +0000

    added 3 files with 'add .'
]# 

Jadi, apa tepatnya yang dilakukan Pria Nama Anda itu, dalam dua komitmennya, sesaat sebelum pukul 6 sore?

Detail komit terakhir adalah:

]# git show
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <[email protected]>
Date:   Sun Feb 16 17:56:18 2020 +0000

    didn't add the pics before :(

diff --git a/picture2 b/picture2
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/picture2
@@ -0,0 +1 @@
+1
diff --git a/picture3 b/picture3
new file mode 100644
index 0000000..0cfbf08
--- /dev/null
+++ b/picture3
@@ -0,0 +1 @@
+2
]# 

Dan untuk memeriksa komit kedua hingga terakhir, yang pesannya mengumumkan dua gambar:

]# git show @^
commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <[email protected]>
Date:   Sun Feb 16 17:54:03 2020 +0000

    Two new picture files
    Had to change btext...

diff --git a/btext b/btext
index a4a6c5b..de7291e 100644
--- a/btext
+++ b/btext
@@ -1,3 +1 @@
-This is file b
-second line
-more
+Completely changed file b
]# 

Ini terjadi karena saya mencoba git commit -a untuk pintasan git add . , dan kedua file tersebut baru (tidak terlacak). Itu ditampilkan dengan warna merah dengan git status , tetapi seperti yang saya katakan git tidak kalah rumitnya dengan tar, atau unix.

"Debutan Anda hanya tahu apa yang Anda butuhkan, tetapi saya tahu apa yang Anda inginkan" (atau sebaliknya. Intinya tidak selalu sama)