비슷한 것 tar cz * | ssh <host> "tar xfc -"? 진심으로, 문제가 무엇입니까 tar? 이 명령은 중간 파일을 생성하지 않습니다.

다른 답변에서 아이디어를 개발하면 로컬에서 파일을 만들지 않고도 파이프를 통해 정보를 보낼 수 있습니다 tar. 명령은 다음과 유사합니다.

tar cf - * | aws s3 cp - s3://some-bucket/archive.tar

이 명령의 장점은 명령을 병렬로 실행할 수 있다는 것 tar입니다 aws. 압축을 추가할 수도 있습니다(이 작업은 다시 병렬로 수행됩니다).

tar cf - * | gzip -c | aws s3 cp - s3://some-bucket/archive.tar.gz

작업을 더 쉽게 하려면 다음을 사용하는 대신 파일의 최상위 디렉터리를 사용할 수 있습니다 *.

tar cf - top_level_directory | aws s3 cp - s3://some-bucket/archive.tar
tar cf - top_level_directory | gzip -c | aws s3 cp - s3://some-bucket/archive.tar.gz

다른 답변에서 영감을 받아 사용할 수 있습니다 cpio. 더 빨라 보이고 더 작은 파일을 생성합니다.

ls |cpio -o |gzip -c | aws s3 cp - s3://some-bucket/archive.cpio.gz

예, 다양한 옵션이 있습니다.

하나는 다른 답변에서 제안한 것처럼 중간 파일을 만들지 않는 것입니다. 이렇게 하면 로컬 IO가 줄어들지만 부분 업로드를 재개하지 못합니다.

추가로 개선할 수 있는 다른 옵션이 있습니다.

• 아카이브에는 압축을 사용하십시오. GZip은 고전적이지만 약간 느립니다. LZ4는 요즘 매우 널리 사용되고 있으며 매우 빠르며 여전히 적절한 압축률 tar과 설명을 제공합니다. ZSTD는 LZ4만큼 빠르지는 않지만 더 짧은 시간에 GZip과 비슷한 압축률을 달성합니다. 선택에 관계없이 전송될 총 데이터 양이 크게 줄어들 가능성이 높습니다.
• cpio대신 사용을 고려해 보세요 tar. tar정확히 공간 절약형 아카이브 형식은 아닙니다. 이것대개별로 중요하지 않지만 수백만 개의 매우 작은 파일을 처리하는 경우 오버헤드는 실제로 상당히 상당합니다. cpio여전히 상당한 양의 오버헤드가 있지만 tar실용적이지 않으므로 이론적으로 cpio여기에서 이를 사용하면 전송되는 데이터 양이 크게 줄어듭니다.
• 각각 파일의 하위 집합을 포함하는 여러 개의 아카이브를 생성하고(예: 각 아카이브에 최대 100,000개 파일) 아카이브를 병렬로 업로드하는 것을 고려하십시오. 소스 시스템이 빠른 인터넷 연결과 상대적으로 빠른 스토리지를 가지고 있다고 가정하면 로컬 IO를 더 효과적으로 병렬화할 수 있기 때문에(그리고 AWS도 최종적으로 이를 병렬화할 수 있기 때문에) 대규모 아카이브를 업로드하는 것보다 (거의 확실하게) 더 빠릅니다. 여기서 "최적" 크기는 일반적으로 멀티파트 업로드를 사용할 필요가 없을 만큼 작습니다. 이렇게 하면 아직 업로드되지 않은 아카이브만 업로드하면 되므로 로컬에서 중간 파일 생성을 건너뛰더라도 부분 업로드를 재개하는 데 도움이 됩니다.

나는 멀티스레딩을 많이 사용하기 위해 rclone을 사용하고 있습니다. 서버와 S3 사이에서 비슷한 작업을 수행했습니다.