そのため、毎月ddを使用してシステムドライブ(パーティションだけでなくドライブ全体)を外付けハードドライブにバックアップしたいと思います。だから私のcrontabにはこのようなものがあります。
0 9 1 * * dd if=/dev/sda | gzip -c > /mnt/5E13119070E2D202/Backups/system_drive.backup.img.gz
良い結果。しかし、/dev/sda(システムドライブ)を再起動後も持続するものに変える方法を見つけようとしています。
使用blkid
(トリム):
/dev/sda5: UUID="58141b62-72af-463c-a3c3-57d0b739c632" TYPE="swap" PARTUUID="c1b89110-05"
/dev/sda1: UUID="a97d9b38-e8a6-4cc2-9684-b7e579c1a990" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c1b89110-01"
/dev/sdg1: BLOCK_SIZE="512" UUID="5E13119070E2D202" TYPE="ntfs" PARTUUID="000b4ae7-01"
どんなアイデアがありますか?
答え1
しかし、/dev/sda(システムドライブ)を再起動後も持続するものに変える方法を見つけようとしています。
したがって、ディスク全体に「グローバルに一意の名前」を指定する必要があります。幸いなことに、Linuxはこれを解決します。
wwn-*
/dev/disk/by-idで正しいエントリを見つけて、ドライブの識別名を確認してください。ただls -l /dev/disk/by-id/wwn-*
探してもいいしsda
、そういうふうにしてもいいですfind /dev/disk/by-id -name 'wwn-*' -lname '*/sda'
。いずれにしても、/dev/disk/by-id/wwn-0x1234cafeのようなシンボリックリンクを取得します。- スクリプトから
devlink=/dev/disk/by-id/wwn-0x1234cafe
gzip < "${devlink}" > /mnt/5E13119070E2D202/Backups/system_drive.backup.img.gz
ここでは使用してもあまり利得がないからですdd
。正反対!dd
独自のブロックサイズと挿入のための潜在的なコピーオーバーヘッドを使用するのではなく、コンプレッサーに入力に対して直接作業を実行させます。
gzip
次の2つの理由でこれを行わないことをお勧めします。
- そのアルゴリズムは古くて遅く、圧縮が悪いです。
- これはシングルスレッドなので、すでに遅いアルゴリズムで別のボトルネックが発生します。
gzip
少なくともpigz
マルチスレッドを使用し、同じ機能を使用できます。しかし、私はAdlerと彼のコンプレッサーに大きな敬意を持っていますが、数十年が経ち、現代のコンプレッサーはより高速で圧縮性能に優れているので、速度と圧縮率の面でより良いパフォーマンスを発揮します。
#!/bin/sh
devlink=/dev/disk/by-id/wwn-0x1234cafe
zstd -5 -T0 --force -- "${devlink}" > /mnt/5E13119070E2D202/Backups/system_drive.backup.img.gz
# ^ ^ ^ ^ ^
# | | | | |
# \-------------------- -5: use a medium-low compression ratio.
# | | | | still better than `gzip --best`, typically, but also faster.
# | | | | Possible values are 1 to 18, where you typically see
# | | | | diminishing returns for values > 12.
# | | | |
# \----------------- -T0: use as many threads as you have CPU cores
# | | |
# \------------ --force: because the input is not a regular file, zstd want
# | | to be explicitly told that, yes, we want this.
# | |
# \---- --: afterwards there's file names. Just for good measure.
# |
# \- "${devlink}": input filename
他のコメントと一緒に:
- アクティブ、読み取り/書き込みマウントルートファイルシステムでバックアップを実行する:はい、それは可能ですが、復元を試みる瞬間に変更する必要があります。したがって、これは悪い考えです。リアルタイム画像または少なくとも
sync; mount -o remount,ro ${root partition} /
前後にこれを行うのが最善です。mount -o remount,rw …
はい、これはバックアップの実行中にシステムの動作を停止します。ただし、単に「特定の目的のためにどこかにバックアップを作成する」ためにバックアップするのではなく、コンピュータが回復可能で安定した状態になるようにバックアップを実行します。 - ライブシステムでこれを行う必要がある場合は、一般的に異なるアプローチがあります。 LVMまたはスナップショットファイルシステム(ZFS、btrfs)をルートおよびデータボリュームとして使用し、スナップショットを作成し、スナップショットをバックアップできます。もしあなたの部分パーティションのリストから、あなたのシステムがLVMを使用するように設定されていないことを正確に推測しました。これは本当に迷惑です(2023年には誰も生のパーティションを処理したくありません!今は90年代ではありません)。 LVM、btrfs、または ZFS を使用するには、システムを再インストールすることをお勧めします。
- NTFSボリュームにバックアップを書き込んでいます。 Linux NTFSドライバはバックアップには適していない可能性があります。また、ntfs-3gは遅いです!したがって、圧縮率を上げてください(
gzip
〜しなければならない-9
/を使用すると、主に圧縮速度ではなく書き込み速度によって制限され、少ない場合は状況が悪化するため、圧縮速度を犠牲にする傾向があります--best
。zstd
-12
-14
- 書き込まれたビット数が少ないことは、エラーの可能性が低いことを意味するため、より安定しています。
- 書き込むビット数が少なく、待ち時間が短いため高速です。