/home에는 2.6PB의 저장 공간을 갖춘 파일 시스템이 마운트되어 있습니다. 현재 300TB 이상의 데이터가 /home 디렉토리에 분산되어 있습니다. 300TB 이상의 데이터 전체를 백업할 계획입니다.일상적으로/home/fs_backup으로 이동했지만 다음 명령이 tar
매우 느린 것으로 나타났습니다.
cd /home/fs_backup && tar -cpf backup.tar.gz --exclude="/home/fs_backup" --one-file-system "/home"
제 생각에는 분당 10GB만 생성할 수 있는 것으로 추정됩니다. 즉, 300TB가 넘는 데이터 전체를 24시간 내에 백업할 수 없다는 의미입니다. /home에서 현재 데이터가 잘 압축되었는지(심지어 전혀 압축되지 않았는지) 또는 짧은 시간 내에 압축되지 않았는지 여부에 관계없이 현재 데이터를 "복사"하는 방법을 알아보세요. 감사합니다.
답변1
할당된 24시간 내에 300GB 전체를 백업할 수 없다고 판단했으므로 요구 사항을 검토해야 합니다.
star
파일 수준에서 , duplicity
, 또는 심지어 rsync
/ 와 같은 증분 도구는 rsnapshot
기본 백업을 생성하는 데 여전히 하루 이상 걸릴 수 있지만 그 이후에는 훨씬 더 빨라질 것입니다. 분명히 이는 각 24시간 백업 주기 동안 변경되는 파일의 수와 크기에 따라 달라집니다.
파일 시스템 수준에서는 스냅샷만으로도 충분할 수 있습니다(실제로 백업은 아니지만). 특히 백업을 완료하는 데 걸리는 시간에 대해 너무 많이 생각하지 않고 스냅샷에서 실제 백업을 만들 수 있기 때문입니다. 이전과 마찬가지로 기본 백업이 설정되면 증분 백업을 생성하는 데 훨씬 더 적은 시간이 걸릴 수 있습니다.
백업 저장 방법을 지정하지 않았지만 많은 작은 파일의 경우 이와 같은 방법이 rsnapshot
적절할 수 있습니다. (복구를 위해 개별 파일에 쉽게 액세스할 수 있기 때문에 많은 내부 파일 서버의 파일 기반 백업에 사용합니다.)
그런데 동일한 호스트의 다른 디스크에 백업하는 것은 실제로 안전한 백업으로 간주되어서는 안 됩니다. 다른 호스트로의 전체 백업이 훨씬 더 좋습니다. ( /home/fs_backup
다른 서버에서 원격으로 마운트하는 경우 원격으로 마운트된 파일 시스템을 통하기보다는 원격 호스트와 직접 통신하거나 duplicity
사용 rsync
하는 것을 심각하게 고려하십시오.)rsnapshot
답변2
내가 아는 가장 빠른 백업 방법은 사용하는 것입니다 star
(이 프로그램의 최신 버전은 참고자료 참조 schilytools
). 왜냐하면 이 프로그램은 파일 시스템 프로세스 사이에 위치하며 다른 프로세스 간에 아카이브 I/O를 수행하는 임의 크기의 링 버퍼를 구현하기 때문입니다. . FIFO 크기를 올바른 방식으로 선택하면 read()
단일 시스템 호출을 사용하여 거의 모든 파일을 읽을 수 있으므로 (최적화된 코드와 함께) 속도가 매우 빨라집니다.
이 링 버퍼는 FIFO
기본적으로 호출되어 사용되지만 8MB
임의의 크기를 사용하도록 지시할 수 있습니다. 최대 유효 값은 RAM
기계 내 사용량의 절반입니다.
star
작업 증분 덤프도 지원됩니다. 먼저 전체 덤프를 수행한 다음 최종 단계에서 거의 시간이 걸리지 않는 방식으로 파일 시스템의 내용을 저장하기 위해 증분 덤프를 수행하는 것이 좋습니다.
매뉴얼 페이지를 확인하고 싶을 수도 있습니다.http://schilytools.sourceforge.net/man/man1/star.1.html
이 매뉴얼 페이지에서는 라이브 파일 시스템이 아닌 snapshot
파일 시스템 수준에서 백업할 것을 권장합니다.