저장소를 복제하는 명령이 성공했다고 서비스 복구 준비까지 끝난 것은 아니다. GitHub를 업무에 사용하는 팀은 Git 이력, 대용량 파일, 위키와 협업 정보를 구분해 백업 범위를 정해야 한다. 2026년 10월 28일 확인한 GitHub 공식 문서를 바탕으로, 백업 완료 기준을 정하는 방법을 설명한다.
mirror clone의 범위부터 명시한다
GitHub는 Git 저장소의 파일과 수정 이력을 백업하는 방법으로 mirror clone을 안내한다. Git LFS를 사용한다면 객체를 추가로 가져오는 단계도 제시한다. 위키는 별도 Git 저장소이므로 별도로 복제해야 한다. GitHub 저장소 백업 안내
팀의 백업 목록에는 “GitHub 전체” 같은 이름 대신 무엇을 되살릴 수 있는지를 적자. 브랜치와 태그를 포함한 Git 이력을 복구하려는지, 위키 문서까지 필요한지, 이슈·리뷰 같은 협업 기록도 별도로 보존해야 하는지 나눠 판단한다. Git clone의 성공 로그만으로 GitHub 서비스에 연결된 모든 정보가 들어 있다고 인정하지 않는다.
LFS 포인터와 실제 파일은 다르다
Git LFS는 실제 대용량 파일 대신 그 파일을 가리키는 포인터를 Git 저장소에 저장한다. 따라서 백업 검사에서는 경로가 존재한다는 사실만 보지 말고 필요한 실제 파일을 열 수 있는지 확인해야 한다. GitHub가 만드는 ZIP 등 소스 압축 파일에 LFS 객체를 포함할지는 별도 설정의 영향을 받는다. Git LFS의 포인터와 파일 저장 방식
공식 백업 절차는 LFS 객체가 있을 때 git lfs fetch --all로 가져오도록 안내한다. 복원 대상을 새 원격 저장소로 옮길 때도 Git 참조 전송과 LFS 객체 전송은 구분된다. LFS를 포함한 저장소 복제 절차
검증용 환경에서 필요한 릴리스 버전을 선택한 뒤, 이미지·모델·설계 파일 등 팀이 지정한 LFS 표본이 실제 내용으로 열리는지 확인하는 것을 권한다. 이는 운영 제안이며 이 글에서 실제 저장소를 복제하거나 파일을 내려받았다는 뜻은 아니다.
최신 미러와 과거 시점 백업을 구분한다
미러 동기화는 원본의 최신 상태를 다른 위치에 맞추는 데 유용하다. GitHub 문서는 mirrored clone의 참조가 fetch 때 원본과 같아지도록 덮어써지는 점을 설명한다. 따라서 계속 갱신하는 미러 하나를 과거 시점의 독립 백업과 동일하게 취급하지 않는 편이 좋다. 다른 위치에 미러 유지하기
예를 들어 월요일과 화요일에 원본 상태가 달라졌다면, 화요일 미러가 최신이라는 사실만으로 월요일에 존재하던 모든 참조와 필요한 자료를 복원할 수 있다고 보장할 수 없다. 팀이 되돌아가야 할 시점을 정하고, 해당 시점의 보관본과 수집 내역을 따로 식별해야 한다.
복구 시험은 운영 저장소를 대상으로 한 덮어쓰기 시험으로 시작하지 않는다. 별도 허용된 테스트 위치에서 대상 커밋·태그·파일을 확인하고, 실제 복원 절차가 기존 원격의 참조를 변경하거나 삭제할 수 있는지 사전에 검토한다.
협업 기록은 수집과 복원을 따로 검토한다
GitHub는 선택된 메타데이터를 담는 migration archive도 설명하지만, 모든 데이터가 포함되지는 않는다. 공식 안내에는 LFS 객체·Discussions·Packages가 빠지는 예와, 이 아카이브를 GitHub에 복원하는 지원되고 문서화된 방법이 없다는 주의가 있다. 보관용 자료 확보와 서비스를 그대로 복원하는 능력은 다르다. Migration archive의 범위와 복원 주의
따라서 “다운로드할 수 있다”만으로 복원 계획을 승인하지 말고, 필요한 정보가 어떤 형식으로 들어오며 어디까지 다시 쓸 수 있는지 확인한다. 외부 유료 도구를 도입하기 전에도 동일한 질문을 적용할 수 있다. 이 글은 특정 상품 구매나 과금되는 API 사용을 권하지 않는다.
백업 완료를 판정하는 네 가지 증거
- Git 이력: 필요한 브랜치·태그·커밋 식별자를 백업과 대조한다. 복제 시각과 원본 식별자를 함께 남긴다.
- 파일 실체: LFS 사용 여부와 수집 결과를 기록하고, 지정한 버전의 실제 파일을 시험 환경에서 확인한다. 파일 이름만으로 완료 처리하지 않는다.
- 부가 정보: 위키와 협업 기록을 별도 항목으로 두고, 미수집·보관만 가능·복원 검증 완료를 구분한다.
- 복구 시험: 보관본만으로 필요한 결과를 재현했는지, 원본 서비스에 다시 접근해야 했던 부분은 무엇인지 기록한다. 원본이 없을 때도 필요한 작업을 수행할 수 있는지 판단하기 위한 항목이다.
대용량 파일 수집과 보관에는 환경별 저장·전송 비용이 생길 수 있다. 통화·세금·약정 조건을 포함한 특정 견적이나 복구 시간 보장은 제시하지 않는다. CI 결과물은 Git 저장소와 별도일 수 있으므로 GitHub Actions 아티팩트 보관 기간 점검도 참고하자.
AI 에이전트가 공식 출처와 점검표를 검토했다. 이미지는 설명용이며 실제 저장소, 고객 파일 또는 복구 성공 사례를 나타내지 않는다.