답변:
나는 이것에 대한 연구를 해왔다.
최종 일관성으로 인해 지역에 따라 S3 로의 백업이 실패 할 수 있습니다. 기본 경고는이 작업을 충분히 수행하면 어느 시점에서 서버 간 Amazon 동기화의 배경에서 파일 시스템 마법으로 파일을 열거 나 찾는 데 오류가 발생하여 백업이 신뢰할 수 없다는 것입니다.
다른 방법으로 저장해야하는지 여부는 위험 관리에 따라 다릅니다. 아마존이 귀하의 데이터를 보유하고 있다고 믿습니까?
스토리지 시스템에 문제가 발생하거나 더 큰 장애가 발생할 수 있습니다. 그들은 계약서에 데이터를 잃어 버렸을 때 그것이 당신의 문제 라는 것을 명시한 조항을 가지고 있습니다. 그들의 것이 아닙니다. 또한 데이터가 다른 곳에 저장되어있는 것을 보면 데이터로 어떤 작업을 수행할지 모릅니다. 법 집행 기관에서 데이터를 원하십니까? 다른 사람이 액세스 한 것을 알지 못할 수도 있습니다.
당신은 그것을 믿습니까? 데이터가 비즈니스의 핵심이 아니고이 위험을 감수 할 의향이있는 경우 오프 사이트 스토리지로 다운로드 할 필요가 없습니다. Amazon의 스토리지 서버에서 데이터가 안전하게 보호 될 위험이 없다면 정기적으로 자체 스토리지에 데이터를 덤프하도록 준비해야합니다.
다시 말해서 나는 이것이 당신의 위험 감수성과 비즈니스 요구에 달려 있기 때문에 이것에 대한 정답이 없다고 생각합니다. 많은 사람들이 클라우드 스토리지에만 전적으로 자신의 수입을 완전히 신뢰하지는 않을 것입니다.
이를 위해 토론과 연구에서 고려해야 할 또 다른 접근 방식은 데이터를 저장하고 EC2 인스턴스에 연결하여 데이터를 저장 한 다음 볼륨을 마운트 해제하고 해당 데이터를 S3에 저장할 수있을 정도로 큰 EBS 볼륨을 생성하는 것입니다. . 볼륨 파일 자체를 S3 또는 내용에 저장하여 수행할지 여부를 조사하는 중이지만 스토리지 비용을 절약하기 위해 EBS 인스턴스를 삭제할 수 있습니다.
편집 나는 다시 읽음으로써 S3에서 EC2 인스턴스로 저장하는 것이 아니라 그 반대의 경우가 아니라는 것을 알 수 있습니다 (결국 일관성 문제가 여전히 문제를 일으킬 수 있는지는 모르겠지만). EC2 인스턴스에 데이터를 백업으로 저장하려고합니까? 비용 측면에서는 건전한 전술이 아니라고 생각합니다. VM 시간과 함께 이러한 종류의 데이터의 장기 저장을 고려할 때 로컬 드라이브에 백업하는 것이 더 저렴할 수 있습니다. 드라이브 비용으로 데이터를 백업으로 로컬 디스크에 복사 할 수 있습니다.
나는 여전히 아마존과 그들의 스토리지를 신뢰하는 것에 대한 경고를 유지합니다. Amazon S3에 모든 것을 유지하고 싶지만 중복성이 더 많은 경우 리전간에 S3 버킷을 복제하고 정전이 한 리전에 영향을 미치더라도 모든 버킷을 녹아웃해서는 안됩니다. 당신은 희망합니다. 그래도 가능합니다.
데이터의 가치, 지불하고자하는 금액, 허용 할 위험의 정도가 중요합니다.
s3cmd를 사용 s3cmd sync하여이 작업을 수행했습니다. 그것은 작동에서 약간 rsync와 같으며 S3과 선택한 다른 Linux 시스템 사이의 전체 디렉토리를 밀고 당길 수 있습니다.
s3cmd syncEC2 인스턴스 또는 자체 개발자 워크 스테이션 (또는 스토리지 서버)을 실행할 수없는 이유는 없습니다 .
VPC 인스턴스를 설정 한 다음 VPC 내부의 작은 노드에 백업 서버 역할을 할당하고 로컬 서브넷 내부뿐만 아니라 Amazon 네트워크 내부에 IP를 둘 수 있습니다.
이것은 오래된 스레드이지만 Googling S3 백업시 가장 먼저 나타나는 일이므로 추가 할 것이라고 생각했습니다 ...
이 자체에 대한 조사를 통해 Rclone https://rclone.org/를 발견 했습니다. 클라우드 파일 스토리지 서비스간에 복사하고 대부분을 지원하도록 설계된 rsync-ish 소프트웨어입니다. 제휴 관계가 없으며 아직 사용하지 않아서 그것이 좋은지 나쁜지 말할 수는 없지만 누군가에게 도움이 될 것이라고 생각했습니다.
클라우드 호스팅 파일 (S3, Google 스토리지, 랙 스페이스 클라우드 파일 등)의 '오프 사이트'백업을 수행하는 호스팅 서비스가있을 것 같습니다 ....