Linux에서 파티션을 생성하는 것이 쉬운 복구를 위한 좋은 솔루션인 이유는 무엇입니까?

Linux에서 파티션을 생성하는 것이 쉬운 복구를 위한 좋은 솔루션인 이유는 무엇입니까?

Linux가 파티션되지 않으면 데이터 복구가 매우 어렵다고 들었습니다. 파티션을 적게 생성하면 데이터를 쉽게 복구할 수 있습니다.

예를 들어 이렇게 하면 회복에 더 좋습니다 /par1 /part2 /part3.

/home/user/{all data here}하지만 이제 내 친구들 중 일부 는 회복 측면과 다르지 않다고 말합니다 /par1 /part2 /part3.

어느 것이 맞으며 그 이유는 무엇입니까?

답변1

간단하고 효과적인 방법으로 문제를 설명하려면 다음 두 가지 상황을 고려하십시오.

  • 파티션 없이 전체 디스크에 원하는 Linux 배포판을 설치할 수 있습니다.

    운영 체제가 특정 섹터에 액세스할 수 없고 부팅에 실패하여 시스템이 충돌한다고 가정해 보십시오. 불량 섹터로 인해 일부 데이터 블록이 손실되어 하드 드라이브의 다른 데이터 블록에 액세스하지 못할 수도 있습니다. 게다가 일부 불량 섹터가 전체 데이터에 영향을 미치고 있습니다. 따라서 여기에서 복구하는 것은 다양한 데이터 범주에 대해 여러 파티션을 사용하는 것보다 더 어려울 수 있습니다.

  • 하드 드라이브를 분할하여 원하는 Linux 배포판을 설치할 수 있습니다.

    하드 드라이브를 부팅용 sda1, 루트용 sda2, opt용 sda3, usr용 sda4, 가정용 sda5 등으로 분할하는 경우 이제 일종의 충돌이나 불량 섹터 문제가 있는 경우 이전보다 그럴 가능성이 더 높습니다. 다른 파티션을 저장/복원할 수 있는 상황. 이는 다음 상황에서도 유용합니다. 예를 들어 시스템이 충돌하고(OS 문제로 생각) 시스템이 부팅되지 않는 경우, 기본 파티션을 건드리지 않고 시스템을 다시 설치할 수 있으므로 기본 파티션이 격리되고 안전합니다. . 기타 혜택은 다음과 같습니다.

    1. 파일 시스템 검사에는 시간이 덜 걸립니다.
    2. 다양한 파일 시스템을 자유롭게 선택할 수 있습니다.
    3. 파일 시스템을 보호하십시오.
    4. 문제가 있는 파일 시스템을 찾아내 파일 시스템을 쉽게 복구할 수 있습니다.

물론, 단일 볼륨 그룹으로 시작한 다음 필요한 파일 시스템을 보관하기 위해 여러 논리 볼륨을 생성하는 LVM(논리 볼륨 관리)에는 이점이 있습니다. 저는 개인적으로 LVM을 사용하지 않기 때문에 더 많은 정보를 얻을 수 있습니다.위키피디아그리고루트 다이어그램

답변2

파티션 누락은 복구의 일반적인 이유입니다.

파티션 테이블은 디스크가 사용 중임을 선언하는 가장 일반적이고 표준적인 방법입니다(그리고 파티션 유형이 너무 많기 때문에 일반적으로 각 파티션의 정확한 목적도 선언합니다).

많은 프로그램에서 파티션되지 않은 디스크는 사용되지 않은 디스크처럼 보입니다. 설치 프로그램은 설치를 위해 해당 디스크를 선택하고, 파티셔너는 해당 디스크에 파티션 테이블을 생성합니다. 파일 시스템 메타데이터 또는 LUKS 헤더에 대한 파티션을 직접 생성하지 않으면 쉽게 손상됩니다.

자신이 수행 중인 작업을 정확히 알고 환경을 완벽하게 제어할 수 있다면 파티셔닝이 필요하지 않을 것입니다. 그러나 나는 여전히 그것들을 사용하는 것이 좋습니다.

답변3

이것은 사실이었습니다. 드라이브가 더 작고 더 느렸던 때가 있었고 테이프도 마찬가지였습니다. 대규모 RAID 그룹이 있고 (복합) 오류가 발생하는 경우 RAID 그룹의 모든 데이터를 복구해야 합니다.

크기가 커지면 필요한 테이프의 양도 늘어납니다.

따라서 대규모 파일 시스템에서는 전체 복원을 수행합니다. 이는 전체 백업 및 후속 증분 백업을 호출하는 일련의 테이프에서 모든 것을 복원하는 것을 의미할 수 있습니다. 대규모 파일 서버에서는 시간이 많이 걸릴 수 있습니다.

마찬가지로 백업 주기도 오랜 시간이 걸릴 수 있습니다. 매일 "일일" 백업 일정을 완료하지 못할 위험이 매우 높습니다.

따라서 수행할 작업은 서로 다른 물리적 장치에 별도의 파일 시스템을 생성하고 독립적으로 백업하는 것입니다. 그런 다음 시차를 두고 백업하거나 다른 테이프 장치로 스트리밍할 수 있습니다. 오류가 발생하면 세그먼트를 교체하고 복원하기만 하면 작업이 완료됩니다.

이러한 이유는 여전히 어느 정도 적용되지만 드라이브와 테이프는 더 크고 빠릅니다. (어쨌든 많은 사람들이 디스크에 직접 백업합니다.) 자동 재구축도 더 매끄러워졌습니다.

이제 분할하는 주요 이유는 다음과 같습니다.

  • 공간 사용을 제어합니다. 사용자가 "홈"에 너무 많은 정크 파일을 다운로드했기 때문에 "루트"를 삭제하는 것을 원하지 않습니다.
  • "백업이 필요한 것"과 "백업할 필요가 없는 것"을 구분하세요. 자동 재구축 프로세스가 충분히 잘 진행되면 복원할 수 있는 것보다 빠르게 재구축할 수 있어야 하며 그런 다음 임시 데이터(데이터베이스 파일, 사용자 데이터 등)만 추가하면 됩니다.
  • 디스크 구성 격리. 고성능이나 복원력이 뛰어난 디스크는 필요하지 않을 수도 있습니다. 그런 다음 다른 디스크 기술이나 RAID 유형을 선택할 수 있습니다.
  • 디스크 수준 백업 - 스냅샷 또는 복제가 가능하지만 일반적으로 LUN별 수준에서만 이 작업을 수행할 수 있습니다. 이 기술을 사용하면 매우 멋진 복원/롤백/포워드 옵션을 사용할 수 있지만 사용 중인 저장소를 격리해야 합니다. (오라클 데이터베이스를 롤백할 때마다 기본 드라이브를 지우고 싶지는 않습니다.)

관련 정보