/home에는 2.6PB의 저장 공간이 있는 파일 시스템이 마운트되어 있습니다. 현재 /home 디렉토리에는 300TB 이상의 데이터 분산이 있습니다. 300TB 이상의 데이터 전체를 백업하려고 합니다.매일매일/home/fs_backup으로 이동했지만 via를 통한 다음 명령이 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
내가 아는 가장 빠른 백업 방법은 이 프로그램이 파일 시스템 프로세스와 아카이브 I/O를 수행하는 다른 프로세스 사이에 있는 임의 크기의 링 버퍼를 구현하기 때문에 사용하는 것입니다 star( 에서 이 프로그램의 최신 버전 참조 ). schilytoolsFIFO 크기를 올바른 방법으로 선택하면 거의 모든 파일이 단일 read()syscall을 사용하여 읽혀지고 이로 인해 (최적화된 코드와 함께) 속도가 매우 빨라집니다.
이 링 버퍼는 호출되며 FIFO기본적으로 를 사용 8MB하지만 임의의 크기를 사용하도록 지시할 수 있습니다. 최대 유효 값은 RAM기계 양의 절반입니다.
star또한 증분 덤프 작업도 지원하며, 전체 덤프에 이어 증분 덤프를 수행하는 것은 마지막 단계에서 시간이 거의 걸리지 않는 방식으로 파일 시스템의 콘텐츠를 저장하는 것이 좋습니다.
맨 페이지를 살펴보는 것이 좋습니다.http://schilytools.sourceforge.net/man/man1/star.1.html
이 매뉴얼 페이지에서는 라이브 파일 시스템이 아닌 snapshot파일 시스템 수준에서 백업을 수행할 것을 권장합니다.