Large migrations · Verification · 진행률 표시줄 뒤의 증명
클라우드 간에 수백 GB 이동: 도착하는 모든 파일을 어떻게 알 수 있나요?
500GB에서는 "업로드가 완료된 것 같습니다"는 증거가 아닙니다. 신뢰할 수 있는 마이그레이션에는 내구성 있는 인벤토리, 모든 개체에 대한 상태 전환, 중단 후 반복 가능한 복구 및 대상 자체의 증명이 필요합니다.
업데이트 ; 16 분 소요.
간단한 답변
FileArk는 라이브러리를 파일별 레코드와 내구성 있는 대기열 메시지로 나눕니다. 작업자는 하나의 배달을 복사하고, 반환된 대상 ID를 저장하고, 크기를 검증하고, 정확한 객체를 다시 읽고, SHA-256을 소스 페이로드와 비교합니다. 해당 확인과 데이터베이스 업데이트가 성공한 후에만 레코드가 확인되고 메시지가 승인됩니다.
규모가 "일했다"의 의미를 바꾸는 이유
10개의 파일은 검사하기 쉽습니다. 10,000개의 파일은 그렇지 않습니다. 대규모 개인 라이브러리는 작은 문서, 수 기가바이트 비디오, 빈 파일, 중첩 폴더, 유니코드 이름, 보관된 프로젝트 및 클라우드 기반 형식을 결합할 수 있습니다. 하나의 실패가 인상적으로 보이는 비율 안에 숨어 있을 수 있습니다.
총계는 유용하지만 불완전합니다. 두 라이브러리는 동일한 겉보기 크기를 표시할 수 있지만 한 라이브러리에는 객체가 없거나 일부 관련되지 않은 파일과 균형을 이루는 잘린 객체가 포함되어 있습니다. 파일 수는 기본 문서 내보내기 또는 제외된 공급자 개체 후에도 다를 수 있습니다.
유용한 정보 단위는 파일 작업입니다. 즉, 어떤 소스 객체를 읽었는지, 어떤 대상 객체를 생성했는지, 어떤 바이트를 비교했는지, 확인이 언제 완료되었는지, 시도가 해결되지 않은 상태로 남아 있는지 여부 등이 있습니다.
주석이 달린 전체 FileArk 수명 주기
시작이 수락되면 API는 먼저 MongoDB에 스캔 작업을 쓴 다음 게시자 확인이 활성화된 지속성 RabbitMQ 대기열에 영구 스캔 메시지를 게시합니다. 게시에 실패하면 작업이 실패로 표시되고 API는 스캔을 안전하게 대기열에 넣을 수 없다고 보고합니다.
스캐너는 두 공급자를 모두 인증하고, 선택한 소스의 목록을 작성하고, 검색된 바이트에 대해 유한한 대상 할당량을 확인하고, 각 소스 파일에 대한 데이터베이스 레코드를 업데이트합니다. 지속적인 마이그레이션 메시지를 게시하고 해당 게시가 성공한 후에만 검색이 완료되었음을 표시합니다.
마이그레이션 작업자는 수동 확인과 프리페치 수 1을 사용합니다. 콘텐츠를 읽고, 업로드하고, 다시 읽고, 확인하고, 유지하는 동안 배달은 승인되지 않은 상태로 유지됩니다. 따라서 중지된 연결이나 프로세스는 완료되지 않은 작업을 대기열로 반환할 수 있습니다.
데이터베이스 행은 일회용 장부가 아닌 체크리스트 항목입니다.
모든 파일 기록은 보류 중으로 시작하고 시도 중에 InProgress로 이동하며 확인 후에만 업로드됨에 도달합니다. 시도 횟수, 마지막 시도 시간, 오류 세부 정보, 대상 개체 ID, SHA-256 다이제스트, 확인 방법 및 VerifiedAt가 레코드에 연결된 상태로 유지됩니다.
완료된 기록은 진행 상황 및 감사 추적으로 데이터베이스에 유지됩니다. "파일 삭제"는 증거를 삭제하는 것이 아니라 제어된 상태 변경을 의미합니다. 중복 대기열 전달은 해당 상태를 검사하고 이미 VerifiedAt로 업로드됨으로 표시된 레코드를 즉시 승인합니다.
세 번의 시도 실패 후 지속적인 문제는 시도 주기에 대한 완료 타임스탬프와 함께 실패 상태가 됩니다. 이렇게 하면 예외가 표시되고 대시보드가 멈춘 것처럼 보이는 동안 포이즌 메시지가 계속 회전하는 것을 방지할 수 있습니다.
Pending
→ InProgress (attempt recorded)
→ destination ID stored
→ destination size matches
→ exact destination object re-downloaded
→ source SHA-256 == destination SHA-256
→ Uploaded + VerifiedAt persisted
→ queue message acknowledged파일이 두 번 이상 전송될 수 있는 이유
신뢰할 수 있는 대기열은 일반적으로 클라우드 API, 메시지 브로커 및 데이터베이스 전반에 걸쳐 정확히 한 번만 전달한다는 마법의 약속이 아닌 최소 한 번 전달을 제공합니다. OneDrive 또는 Google Drive가 업로드를 수락한 후 작업자가 완료를 쓰기 전에 충돌이 발생할 수 있습니다.
FileArk는 멱등성 레코드 및 대상 복구를 통해 이러한 불확실성을 처리합니다. 작업자는 먼저 기록이 이미 검증되었는지 확인합니다. 그렇지 않은 경우 저장된 대상 ID를 사용하거나 다시 업로드를 결정하기 전에 중단된 결과에 대한 예상 대상 경로와 정확한 크기를 검색할 수 있습니다.
그런 다음 복구 후보는 동일한 정확한 객체 해시 검증을 받습니다. 익숙한 파일 이름을 찾는 것만으로는 충분하지 않습니다. 요점은 중단된 시도를 낙관적인 성공이 아닌 증거로 다시 전환하는 것입니다.
목적지와 작업자의 능력을 확인합니다.
파일별 작업이 게시되기 전에 스캐너는 음수가 아닌 소스 메타데이터 크기를 합산하고 공급자가 한정된 할당량을 제공할 때마다 요구 사항을 대상의 보고된 나머지 스토리지와 비교합니다. 크기가 작은 대상은 알려진 막다른 골목에 작업을 공급하는 대신 스캔에 실패합니다.
이 수치는 실행 전일 뿐 보장되지는 않습니다. 계정 활동은 실행 중에 공간을 소비할 수 있고, 공급자 할당량 보고서는 지연될 수 있으며, 내보낸 클라우드 기반 파일은 일반적인 소스 크기를 갖지 않을 수 있습니다. 공급자 적용 및 파일별 오류 처리는 활성 상태로 유지됩니다.
컴퓨터 디스크는 준비에 사용되지 않습니다. 마이그레이션 작업자에서 메모리 임계값을 초과하는 파일은 볼륨에 예상 개체를 위한 공간과 2GB 예약 공간이 확보된 후에만 격리된 임시 디렉터리에 배치됩니다. 시도가 성공하든 실패하든 임시 콘텐츠는 정리 시 제거됩니다.
대상 ID와 SHA-256이 중요한 이유
파일 이름은 고유한 ID가 아닙니다. 대상에 이미 동일한 표시 이름을 가진 두 개의 파일이 포함되어 있거나 메타데이터 목록이 확정되는 데 시간이 걸릴 수 있습니다. 업로드 응답은 공급자 개체 ID를 제공하고 FileArk는 최종 확인 단계 전에 해당 ID를 저장합니다.
작업자는 소스 페이로드 스트림 전체에서 SHA-256을 계산하고 이를 업로드한 다음 해당 ID로 정확한 대상 객체를 열고 SHA-256을 다시 계산합니다. 동일한 크기는 명백한 잘림을 포착합니다. 동일한 암호화 다이제스트는 더 강력한 바이트 수준 검사입니다.
전송된 파일 표현만 다룹니다. 다이제스트는 공유 규칙, 댓글, 버전, 라벨, 바로가기, 보관 설정 또는 내보낸 Google 문서가 사용자에게 렌더링되는 방식을 확인할 수 없습니다. 이는 수용 작업으로 남아 있습니다.
소스 삭제가 의도적으로 일반적인 성공 경로를 벗어났습니다.
가장 안전한 기본값은 복사 전용이며 FileArk의 삭제 옵션은 활성화하지 않는 한 꺼져 있습니다. 삭제가 비활성화되면 삭제가 요청되지 않으므로 확인 실패 시 원본을 제거할 수 없습니다.
의도적으로 이동 후 삭제를 활성화하는 경우 작업자는 소스 공급자의 삭제 작업을 호출하기 전에 대상 ID, 크기 및 SHA-256 유효성 검사를 기다립니다. 대체할 수 없거나 매우 큰 라이브러리에 대한 더 강력한 운영 선택은 여전히 옵션을 해제하고 사람이 승인한 중복 기간을 사용하는 것입니다.
마이그레이션에서는 "검증된 사본이 도착했습니까?"라고 대답합니다. 보존은 "오래된 사본은 언제 제거할 수 있습니까?"라고 대답합니다. 별도의 증거가 있는 별도의 결정으로 처리하십시오.
동일한 제어 모델이 양방향으로 작동합니다.
OneDrive에서 Google Drive로의 경우 소스 페이로드는 Microsoft Graph에서 읽혀지고 대상 개체는 반환된 ID를 통해 Google Drive를 통해 확인됩니다. Google Drive에서 OneDrive로의 경우 소스는 Google Drive를 통해 다운로드되거나 내보내지며 새 OneDrive 항목은 Microsoft Graph를 통해 다시 읽혀집니다.
대기열, 데이터베이스 상태, 제한된 시도, 실행 전 용량, 소스 다이제스트, 대상 ID, 대상 다이제스트 및 승인 순서는 방향 중립적입니다. 공급자 어댑터는 다양한 업로드, 폴더 및 콘텐츠 API를 처리합니다.
비대칭성은 콘텐츠 의미론입니다. Google 기본 문서를 내보내야 하며 두 플랫폼 모두 서비스별 공유 및 버전 동작이 있습니다. 바이트 검증 파일 콘텐츠를 모든 협업 기능의 완전한 복제품으로 홍보해서는 안 됩니다.
네 부분으로 구성된 수용 계획을 사용하세요.
시스템 기록 조정
완료됨, 보류 중, 진행 중 및 실패 횟수를 검토합니다. 전체 비율이 높기 때문에 실패한 항목을 폐기해서는 안 됩니다.
위험별 샘플
잃어버리면 가장 큰 피해를 입을 수 있는 파일과 대용량 미디어, 아카이브, 오래된 문서, 영어가 아닌 이름, 중첩 경로, 변환된 클라우드 기반 파일을 엽니다.
대상 동작 검증
실제 장치 및 사용자의 액세스를 테스트합니다. 필수 공유를 다시 구축하고 Office 또는 내보낸 Google 파일이 예상대로 열리는지 확인합니다.
중복 기간을 보유
정상적인 사용이 대상을 실행하는 동안 소스를 사용 가능하고 안정적으로 유지하십시오. 나중에 취소 또는 삭제 결정을 내리세요.
자주 묻는 질문
FileArk는 모든 파일에 대해 대기열을 사용합니까?
그렇습니다. 스캐너는 소스 파일당 데이터베이스 레코드를 생성하거나 재사용하고 지속적인 마이그레이션 메시지를 게시합니다. 작업자는 수동 확인을 통해 해당 메시지를 가져옵니다.
대기열 메시지는 언제 확인됩니까?
대상 개체 ID, 크기 및 SHA-256이 확인되고 Uploaded 및 VerifiedAt 상태가 유지된 후. 배송이 완료되지 않은 상품은 재배송될 수 있습니다.
완료된 파일 기록은 데이터베이스에서 삭제됩니까?
아니요. 완료는 지속성 기록의 상태 전환입니다. 행에는 진행 및 감사를 위한 대상 ID, 확인 증거, 타이밍, 시도 정보가 유지됩니다.
SHA-256은 권한과 버전 이동을 증명할 수 있나요?
아니요. 대상 파일 바이트가 전송된 소스 페이로드와 일치함을 증명합니다. 공유, 권한, 버전, 설명, 레이블, 바로가기 및 공급자 기본 동작에는 별도의 검증이 필요합니다.
OneDrive에서 Google Drive로의 확인은 반대의 경우와 동일한 방식으로 이루어지나요?
핵심 규칙은 소스 페이로드 다이제스트, 대상 객체 ID, 대상 크기, 정확한 객체 재다운로드 다이제스트, 지속적인 검증, 큐 승인 등 양방향에서 동일합니다.