Linux AMI를 사용하는 Amazon EC2 서버에서는 현재 일일 백업 cron 작업이 실행되고 있습니다.
TMP_BACKUP_FILE="/tmp/backup.tar"
BACKUP_FILE="/home/ec2-user/Dropbox/Backup/backup.tar"
rm -f "$TMP_BACKUP_FILE"
tar cf "$TMP_BACKUP_FILE" \
/home /root /var/lib/redis /var/spool /etc
mv "$TMP_BACKUP_FILE" "$BACKUP_FILE"
chown ec2-user:ec2-user "$BACKUP_FILE"
tar 덤프가 Dropbox에 업로드됩니다.
파일 이름은 항상
backup.tar
. 타임스탬프가 추가되지 않습니다. Dropbox에서 버전 관리를 담당합니다.tar 파일은 압축되지 않았으므로 Dropbox를 쉽게 사용할 수 있습니다. 델타 동기화.
그러나 Dropbox로의 dropbox.py
업로드 시간을 모니터링할 때 backup.tar
Dropbox 클라이언트가 델타 동기화를 사용하지 않는 것 같은 인상을 받았습니다. 이것은 나쁘다:
델타 동기화가 없으면 서버 대역폭이 낭비됩니다.
백업 폴더를 개인용 Dropbox와 공유했기 때문에 매일
backup.tar
내 노트북에 다운로드됩니다(거기서 오프라인 백업 시스템으로 이동합니다). 델타 동기화가 없으면 다운로드에 시간이 오래 걸리고 대역폭이 낭비됩니다.
특정 목적에 적합한 백업 아카이브 형식은 무엇입니까?
루프 마운트 이미지 파일로 재동기화할 수 있습니다.좋은 생각인 것 같나요?
업데이트
rdiff
방금 librsync의 일부인 유틸리티를 사용하여 테스트를 수행했습니다 .위키피디아에 따르면Dropbox는 librsync에 의존합니다. 테스트 결과 델타의 크기는 2.6MB에 불과하므로 백업 아카이브의 354MB보다 상당히 작은 것으로 나타났습니다. 따라서 아마도 tar는 주어진 목적에 적합한 형식일 것입니다. 시험:
$ mv ~/Dropbox/Backup/backup.tar /tmp
$ sudo ~/bin/backup.sh
$ mv ~/Dropbox/Backup/backup.tar /tmp/backup_new.tar
$ cd /tmp
$ rdiff signature backup.tar >backup.tar.signature
$ rdiff delta backup.tar.signature backup_new.tar >backup_new.tar.delta
$ ls -lh backup.tar backup_new.tar backup_new.tar.delta
-rw-rw-r-- 1 ec2-user ec2-user 354M Dec 21 13:39 backup_new.tar
-rw-rw-r-- 1 ec2-user ec2-user 2.6M Dec 21 13:55 backup_new.tar.delta
-rw-rw-r-- 1 ec2-user ec2-user 354M Dec 21 00:10 backup.tar
Dropbox 포럼에 질문했습니다.Dropbox가 업로드하는 델타 크기를 찾는 방법에 대해 알아보세요.