☰

dd를 사용하여 동일한 드라이브를 자동으로 백업하려면 cron 작업을 사용하세요.

tag-icon • tag-icon cron backup dd
dd를 사용하여 동일한 드라이브를 자동으로 백업하려면 cron 작업을 사용하세요.

그래서 매달 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가 이를 해결해 드립니다.

  1. 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와 같은 심볼릭 링크를 얻게 됩니다.
  2. 스크립트에서
devlink=/dev/disk/by-id/wwn-0x1234cafe

gzip < "${devlink}" > /mnt/5E13119070E2D202/Backups/system_drive.backup.img.gz

여기서는 사용해도 별 이득이 없기 때문입니다 dd. 정반대! dd자체 블록 크기와 삽입을 위한 잠재적인 복사 오버헤드를 사용하는 대신 압축기가 입력에 대해 직접 작업을 수행하도록 하세요.

gzip다음 두 가지 이유로 이 작업을 수행하지 않는 것이 좋습니다 .

  1. 그 알고리즘은 오래되고 느리며 압축이 좋지 않습니다.
  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
    • 기록된 비트 수가 적다는 것은 오류 가능성이 적다는 것을 의미하므로 더 안정적입니다.
    • 쓸 비트 수가 적고 대기 시간이 짧기 때문에 더 빠릅니다.

관련 정보