버전 제어 소프트웨어를 통해 파일 시스템을 백업하면 어떤 이점이 있습니까?

버전 제어와 백업은 다양한 관리 수준에서 다양한 목적으로 사용됩니다. 프로젝트에서는 구성 관리 및 버전 제어 시스템을 사용하여 코드를 제어하고 관리하며, 시스템 수준에서는 관리자(IT 부서 또는 로컬 관리자)가 데이터베이스 백업 또는 프로젝트의 버전 제어 데이터베이스 백업을 수행합니다. 개인 환경에서는 그 차이가 그렇게 명확하지 않을 수도 있지만, 둘 다 "데이터 저장"이라는 "동일한" 목적을 제공한다는 생각을 놓으면 매우 분명해집니다. 프로젝트에서 버전 제어를 사용하여 안정적이고 반복 가능한 소프트웨어 구성을 얻고 백업을 사용하여 시스템 데이터를 안전하게 유지합니다(우발적이거나 악의적인 데이터 삭제, 하드 드라이브 충돌, 화재 발생 시 롤백 등을 방지하기 위해). ).

분산(비중앙화) 버전 제어를 사용하는 것은 보다 일반적인 백업 방법을 보완하는 효과적인 백업 전략입니다. 두 가지 접근 방식을 동시에 사용하는 방법에 대해서는 할 말이 많습니다.

표준 백업이 어떻게 작동하는지 검토해 보겠습니다. 대개,모두파일 시스템의 파일은 일부 원격 위치에 복사됩니다. 이는 일반적으로 cron을 사용하여 고정된 주기적인 일정에 따라 수행됩니다. 여기에는 증분 백업 옵션이 포함될 수 있습니다. 즉, 일부 백업은 기존 백업과의 차이점만 저장할 수 있습니다. 이는 일반적으로 공간을 절약하고 주어진 공간에서 더 많은 백업을 수행할 수 있도록 하기 위해 수행됩니다. 이 경우 백업 소프트웨어는 선택한 백업을 재조립하는 작업도 수행합니다.

여기서는 중복 제거 백업 소프트웨어에 대해 특별히 언급합니다.보그 백업그리고레스틱. 이 최첨단 증분 백업 기술은 데이터를 중복하지 않고 새롭고 고유한 데이터만 저장하려고 시도합니다.

이점:

1. 상태모두파일은 특정 시점에 저장됩니다.
2. 최소한 완전히 자동화된 백업의 경우에는 사용자에게 실제 작업이 필요하지 않습니다. 이는 표준입니다.

결점:

1. 저장된 상태는 특정 파일과 관련이 없습니다. 이것은 단지 임의의 시점일 뿐입니다.
2. 실제로 이전 버전의 파일은 결국 손실/폐기됩니다. 이론적으로는 모든 백업의 전체 기록을 보관할 수 있지만 공간상의 이유로 거의 수행되지 않습니다. 그러나 중복 제거 백업 소프트웨어의 효율성이 향상되고 데이터 저장 비용이 낮아지고 낮아짐에 따라 이제 모든 백업을 보존하는 것이 더 실현 가능해졌습니다.
3. 정기적으로 파일 시스템 스냅샷을 저장하는 자동 백업 전략의 본질적인 한계로 인해 특정 시점의 파일 상태는 저장되지 않습니다. 보다 구체적으로 말하면, 관련 파일 시스템이 손상된 경우 마지막 백업 이후의 모든 변경 사항이 손실됩니다.
4. 중요한 백업 소프트웨어에 확인 옵션이 있더라도 테스트/상호작용 없이는 백업이 유효한지 알 수 있는 방법이 없습니다. 이는 압축된 백업의 경우 특히 문제가 됩니다.

이제 이를 DVCS(분산 버전 제어)를 사용한 백업과 비교해 보세요. 제가 2015년 초에 이 글을 썼을 당시에는 Git과 Mercurial이라는 두 가지 주요 무료 분산 버전 제어 시스템이 있었습니다. 나는 독점 버전 제어 소프트웨어를 사용하는 것이 여러 가지 이유로 나쁜 생각이라고 생각하므로 그러한 짐승의 존재를 무시하겠습니다. 물론 다음과 같은 다른 분산 버전 제어 시스템도 존재합니다.비즐,다르코스,단조로운그리고화석, 그러나 DVCS 분야에서는 Mercurial과 Git이 가장 많이 사용됩니다.

백업에 DVCS를 사용하는 방법은 무엇입니까? 매우 간단합니다. 리포지토리에 커밋한 다음 다른 물리적 위치에 있는 원격 시스템에 푸시하는 것이 좋습니다. 단, 연결된 USB 드라이브를 긴급하게 사용할 수도 있습니다.

이점:

1. 각 파일의 저장 상태는 정의에 따라 각 파일에 따라 사용자 정의되고 특정됩니다.
2. 저장소는 각 파일의 전체 스냅샷 기록을 유지합니다. 결국, 이것이 바로 버전 관리에 관한 것입니다.
3. 적절한 커밋이 아직 준비되지 않았다고 가정하더라도 매우 짧은 간격으로 각 파일의 로컬 상태를 저장할 수 있습니다. 이는 Mercurial에서 다음 방법을 사용하여 수행할 수 있습니다. 수은 대기열 확장또는 새로운진화적 확장. 이를 수행하는 방법에 대한 자세한 내용은 이 문서의 범위를 벗어나지만 효과적인 작업 흐름은 나중에 영구 커밋으로 병합/정제/조정될 수 있는 매우 세분화된 임시 커밋입니다. 자식은비슷한 대기열 특성. 내가 아는 한. Git은 Evolve와 유사하지 않습니다.
4. 원격 DVCS로 푸시하는 것은 원격 시스템의 백업/저장소가 제대로 작동하는지 확인하는 기본 방법입니다. 100% 보장은 아니지만(손상된 저장소로 푸시 가능) 최소한 이전에 수행한 가장 최근 커밋이 여전히 원격 저장소에 존재하고 올바른 해시 등을 가지고 있다는 사실을 알려줍니다. 표준 DVCS는 원격 저장소의 구조에 문제가 있으면 큰 소리로 불평합니다.

결점:

1. 모든 파일이 저장되는 것은 아니며 버전 관리 파일만 저장됩니다.
2. 버전 제어를 통해 특정 크기 이상의 파일을 저장하는 것은 종종 비현실적입니다. Mercurial의 경우 파일 크기가 약 10-20MB 정도에서 성능 문제가 발생하기 시작합니다. 다음을 포함하여 이 문제를 해결하기 위해 시도할 수 있는 몇 가지 해결 방법/요령이 있습니다.Mercurial의 대용량 파일 확장자유명한 곳도 있어요자식 첨부, 유명한 Joey Hess가 작성했지만 제가 아는 한 이것은 적절한 백업 전략을 대체할 수 없습니다.
3. 사용자는 저장소를 설정하고, 커밋을 하고, 로그 메시지를 작성하고, 임시 커밋을 영구 커밋으로 병합 및 조정하기 위해 매우 열심히 일해야 합니다.

"표준 백업"과 "DVCS를 사용한 백업"의 장단점을 의도적으로 반영했습니다. DVCS Con 2를 제거하면 정확한 이미지가 생성됩니다. 이 기사의 시작 부분에서 말했듯이 이러한 전략은 상호 보완적입니다.

내 의견으로는 현명한 사용자는 어쨌든 DVCS를 사용해야 하기 때문에 DVCS Con 3은 실제로 Con이 아닙니다.