하나의 큰 파티션에 Linux를 설치하는 것이 얼마나 나쁜가?

새 서버에서 CentOS 7을 실행합니다. 서버 내부에는 raid6에 6 개의 300GB 드라이브가 있습니다. (스토리지는 40TB RAID 박스 형태로 대부분 외부에 있습니다.) 단일 볼륨으로 포맷하면 내부 볼륨은 약 1.3TB가됩니다. 우리 시스템 관리자는 하나의 큰 1.3TB 파티션에 OS를 설치하는 것이 정말 나쁜 생각이라고 생각합니다.

나는 생물 학자입니다. 우리는 지속적으로 새로운 소프트웨어를 설치하고 실행하고 테스트하며, 대부분은 / usr / local에 있습니다. 그러나 우리는이 시스템을 사용하는 컴퓨터에 정통하지 않은 약 12 ​​명의 생물학자가 있기 때문에 / home에서도 많은 cruft를 수집합니다. 마지막 서버에는 /에 200GB의 파티션이 있었고 2.5 년 후에는 90 %가 찼습니다. 나는 그런 일이 다시 일어나길 원하지 않지만 전문가의 조언에 반하고 싶지도 않습니다!

필요한 공간과 공간을 확보하기 위해 1.3TB를 사용하는 것이 가장 좋지만 시스템 관리자를위한 유지 관리의 악몽을 만들지 않겠습니까?

파티셔닝의 주요 (역사적) 이유는 다음과 같습니다.

• 하는 사용자 및 응용 프로그램 데이터에서 운영 체제를 분리 . RHEL 7이 출시 될 때까지 지원되는 업그레이드 경로 가 없었고 주 버전을 업그레이드하려면 다시 설치해야하고 /home별도의 파티션 (또는 LVM 볼륨) 에 예를 들어 기타 (애플리케이션) 데이터가 있으면 사용자 데이터를 쉽게 보존 할 수 있습니다 응용 프로그램 데이터 및 OS 파티션을 삭제하십시오.

• 디스크 공간이 완전히 부족하면 사용자가 제대로 로그인 할 수없고 시스템이 흥미로운 방식으로 실패하기 시작합니다. 다중 파티션을 사용하면 OS에 하드 예약 된 디스크 공간을 할당하고이를 사용자 및 / 또는 특정 응용 프로그램에서 쓰기가 허용되는 영역 (예 : /home /tmp/ /var/tmp/ /var/spool/ /oradata/등) 과 별도로 유지 하여 잘못 작동하는 사용자 및 / 또는 응용 프로그램의 운영 위험 을 완화 할 수 있습니다 .

• 몫. 디스크 할당량을 통해 관리자는 개별 사용자가 사용 가능한 공간을 모두 사용하지 못하게하여 시스템의 다른 모든 사용자에게 서비스를 중단 할 수 있습니다. 개별 디스크 할당량은 파일 시스템마다 할당되므로 단일 파티션과 단일 파일 시스템은 하나의 디스크 인용 만 의미합니다. 다중 (LVM) 파티션은보다 세부적인 할당량 관리를 허용하는 다중 파일 시스템을 의미합니다. 사용 시나리오에 따라 예를 들어 각 사용자가 홈 디렉토리에서 10GB, 외부 스토리지 배열의 / data 디렉토리에서 2TB를 허용하고 누구나 홈 디렉토리에 대해 너무 큰 데이터 세트를 덤프 할 수있는 큰 공유 스크래치 영역을 설정할 수 있습니다. 정책이 "전체 꽉 참"이되는 곳이 발생하면 아무 일도 일어나지 않습니다.

• 전용 IO 경로 제공 . SSD와 회전 디스크의 조합이있을 수 있으며 다른 방식으로 해결하는 것이 좋습니다. 범용 서버에서는 그다지 문제가되지 않지만 데이터베이스 설정에서 매우 일반적인 문제는 특정 스핀들 (디스크)을 다른 목적으로 할당하여 IO 경합을 방지하는 것입니다 (예 : 트랜잭션 로그의 별도 디스크, 실제 데이터베이스 데이터의 별도 디스크 및 별도) 임시 공간을위한 디스크. .

• 부팅 별도의 /boot파티션 이 필요할 수 있습니다 . 역사적으로 1024 실린더 한계를 넘어서 부팅하는 BIOS 문제를 해결하기 위해 요즘에는 암호화 된 볼륨을 지원해야하는 요구 사항, 특정 RAID 컨트롤러, SAN에서 부팅을 지원하지 않는 HBA 또는 설치 프로그램이 즉시 지원하지 않는 파일 시스템 등을 지원하는 경우가 많습니다.

• 튜닝 다른 튜닝 옵션 또는 완전히 다른 파일 시스템이 필요할 수 있습니다.

하드 파티션을 사용하는 경우 설치 시점에 하드 파티션을 어느 정도 가져와야하며, 하나의 큰 파티션은 최악이 아니지만 위의 몇 가지 제한 사항이 있습니다.

일반적으로 주 볼륨을 하나의 큰 Linux LVM 물리 볼륨 으로 분할 한 다음 현재 요구 사항과 나머지 디스크 공간에 맞는 논리 볼륨 을 생성 하여 할당 될 때까지 할당하지 않은 상태로 두는 것이 좋습니다.

필요에 따라 해당 볼륨과 파일 시스템을 확장하거나 (실제 시스템에서 수행 할 수있는 간단한 작업) 추가 볼륨을 생성 할 수 있습니다.

LVM 볼륨 축소는 쉽지 않지만 종종 파일 시스템 축소는 잘 지원되지 않으므로 피해야합니다.

다중 파티션을 사용하는 개념은 잘못된 위치에있는 전체 파티션으로 인해 전체 시스템이 예기치 않게 작동하지 않는다는 것입니다.

사용 가능한 여유 공간이 없을 때까지 로그 파일을 채우는 시스템의 프로세스를 고려하십시오. 예를 들어 단일 파티션 머신에서 시스템이 / tmp에 새 데이터를 쓰지 못하게 할 수 있습니다. / tmp에 쓰려는 다른 프로세스가 있으면 오류와 함께 종료되어 예기치 않은 동작이 발생합니다.

사용자 또는 프로세스가 일반적으로 쓰는 위치 (/ home, / var, / tmp)에 다른 파티션을 사용하는 경우이를 방지 할 수 있습니다.

어떤 폴더가 커지는 경향이 있는지 이전 서버를 확인하는 것이 좋습니다. 명령 행에서 다음을 수행 할 수 있습니다.

du -h -d 1 / 2> /dev/null

가장 많은 데이터가 누적되는 위치를 확인하고 다음 시스템을 적절하게 설계하십시오. "-d 1"은 한 수준의 폴더 수준으로 만 출력을 제한하여 더 읽기 쉽습니다.

하나의 큰 파티션을 갖는 주된 문제는 파일 시스템을 채우면 더 이상 로그인이 불가능하다는 것입니다.

이 때문에 사용자 루트의 홈 폴더 ( /root)가 외부에 /home있습니다. 어떤 상황에서 파일 시스템이 가득 차면 루트조차도 로그인 할 수없고 시스템을 복구 할 수 없습니다.

이것은 일반적으로 별도의 설치 지점을 만들 이유입니다 /var, /tmp그리고 /home다른 파티션 중 하나가 가득 때 시스템을 복구하는 루트로 적어도 로그인 할 수 할 수 있습니다.

IMHO는 하나의 파티션을 /로 사용하는 것이 매우 합리적입니다.

그러나 lvm (논리 볼륨 관리자)을 사용할 수 있습니다. 모든 디스크를 lvm 그룹으로 사용하지만 /, / home, / usr 및 sysadmin이 선호하는 모든 것을위한 작은 논리 디스크를 작성하십시오. 그런 다음 시스템이 가득 차기 시작할 때 모니터링을 시작하고 필요한 디스크를 확장하십시오. lvresize 및 resize2fs는 온라인 도구이며 서버를 다시 시작하지 않고도 확장을 수행 할 수 있습니다. 그러나 디스크를 줄일 수 없으므로 합리적으로 작게 시작하고 필요에 따라 증가시켜야합니다.

Linux의 단일 단일 파티션 설정에는 최소한의 문제가 있지만 큰 보상이 있습니다.

파티션 레이아웃을 변경하는 것은 약간 어렵고 위험한 일이며, 다운 타임이 길지 않으면 종종 할 수 없습니다.

유일한 장점은 디스크 전체 문제에 대한 보호 기능이 있다는 것입니다. 하지만 당신은 이러한 문제를 발견 할 것이다 훨씬 자주. 파티션 중 하나가 가득 차서 다른 파티션의 공간이 거의 비어 있어도 상황을 상상해보십시오 !

일부 전문 시스템 관리자는 이에 대해 완전히 다른 의견을 가지고 있습니다. 여러 파티션을 사용하면 시스템을보다 안정적으로 만들 수 있으며 파티션을하기 전에 파티션의 크기를 알아야합니다. 내 생각에 이것은 단순히 말할 수 없으며 시스템의 유연성에 대한 끔찍한 단점이며 실제로 동기 부여는 파티션 맵을 가지고 노는 것을 좋아 한다는 것 입니다.

lvm 이라는 간단한 시스템이 있는데 , 이는 "파티션"(용어, 볼륨)의 즉각적인 이동 / 크기 조정을 가능하게합니다. 그러나 단일 로컬 부서 서버에서 IMHO는 일반적으로 필요하지 않습니다.

파티셔닝에는 두 가지 주요 이유가 있습니다.

1. 정적 데이터를 비 정적 데이터로부터 멀리 유지하려면
2. 공개 데이터를 개인 데이터로부터 멀리 유지하려면

첫 번째 이유는 가장 분명한 것입니다. 부팅 할 수없는 시스템을 피하기 위해, 특히 /를 보호하지 않으려는 파일과 파일로 채워지는 영역을 분리해야합니다. 예를 들어, / var 디렉토리는 일반적으로 로그 파일이 저장되는 위치이며 (var은 "변수"를 나타냄) / var가 /와는 별도의 파티션에 마운트되는 이유입니다.

위의 두 번째 이유는 덜 인용되어 있으며 (약 15 년 전 Veritas Volume Manager 과정에서 들었습니다) 실제로 많은 사람들이 로그인하여 작업을 수행하는 시스템과 관련이 있습니다.

효과적인 패 러닝을하는 데에는 예술적인 것이 있습니다. 이것이 아마도 Sys Admins가 그것을 너무 멀리 가져가는 이유 일 것입니다 (IMO). 파일 시스템 내부를 알아야 할뿐만 아니라 의도 된 용도도 알아야합니다. 나는 개인적으로 그것이 오늘날 서버가 사용되는 방식과 점점 관련성이 떨어지는 구식 접근 방식이라고 생각합니다.

소프트웨어 개발자로서 특히 사용 가능한 총 디스크 공간에 관계없이 / tmp, / home, / var 및 /의 크기를 심각하게 제한하는 사려 깊은 파티셔닝 구성표를 사용하여 가상 머신을 구축하는 Ops 부서에 매진하고 있습니다. / usr 또는 / opt와 같은 명백한 선택을 별도로 마운트하지 마십시오. 이러한 시스템은 일반적으로 요청한 디스크 공간에서 남은 모든 것을 "/ stuff"볼륨에 넣게되어 필연적으로 모든 것을 설치하고 연결하게되지만, 그다지 큰 문제는 아닙니다. 그 결과 실제 작업보다 파일을 섞고 경고 이메일을 보내는 데 더 많은 시간을 소비하게됩니다.

단일 파티션을 갖는 것에 대해 본질적으로 "나쁜"것은 없습니다. 어느 시스템에서나 디스크 사용량을 사전에 모니터링하고 합리적인 하우스 키핑 전략 (예 : 로그 회전, 홈 디렉토리의 할당량)을 사용해야하므로 유일한 질문은 몇 개의 개별 파일 시스템을 걱정하고 싶습니까?

따라서 특정 사용 사례에 맞게 시스템을 효과적으로 분할 할 수 있다고 100 % 확신하지 않는 한 전혀 분할하지 마십시오 .

IMHO 그것은 전적으로 당신에게 달려 있습니다. 우선은 몇 가지 사항을 고려하십시오.

• 이 시스템은 자주 관리됩니까?
• 이 시스템은 한 명 이상의 사용자가 사용합니까?
• 이 시스템이 데스크탑 또는 서버 또는 둘 다의 역할을합니까?

마운트 지점은 거의 모든 디렉토리를 고려할 수 있기 때문에 약간 증가하는 데이터가 포함 된 것과 증가하는 데이터가 포함 된 것을 고려해야합니다.

리눅스 시스템 (데이터가 약간 증가)이 실행하는 데 필요한 양이 적고 데이터가 증가하여 소비되는 양 (일반적으로 / var / opt / home / srv)에 놀랄 것입니다.

또한 파티셔닝 요구 사항을 요약 한이 시스템의 사용을 정의하는 방법에 따라 다릅니다. LVM 사용이 포함되었습니다.

일반적인 데스크톱 시스템은 많은 양의 소프트웨어를 설치하는 데 약 20GB가 필요하며 나머지는 전용 / home에 할당하면 정상적으로 작동합니다. LVM은 시스템에 약간의 오버 헤드를 유발하며이 경우 특별한 이점이 없습니다. 의견은 다를 수 있습니다.

서버에서는 설치된 소프트웨어가 데스크탑 시스템처럼 동적 일 가능성이 적습니다. / tmp / var / usr / home / opt / srv와 같은 일반적인 파일 시스템 구성 요소에 대한 실제 마운트 지점을 갖는 것이 더 현명합니다. 여기서 LVM을 사용하는 것은 필수는 아닙니다.

이를 통해 시스템의 모듈성을 향상시킬 수 있으며 예를 들어 해당 파티션을 VM에 복제하는 등의 어리석은 작업을 수행 할 수 있습니다. 또는 dd를 사용하여 블록 레벨 백업을 작성하십시오.

일부 경험을 바탕으로 몇 가지 참고 사항이 있습니다. 또한 여러 개의 마운트 포인트를 사용하여보다 효과적으로 제어 할 수 있다는 점을 고려하십시오. 빠른 또는 느린 디스크 장치를 마운트 포인트에 할당하면 차이가 생길 수 있으며 현저하게 비용 효율성이 높아질 수 있습니다.

마운틴 포인트 /

• 1GB (/ var / usr / opt / home / tmp에 별도의 마운트 지점을 사용하는 경우)
• 별도의 / home이있는 데스크탑 시스템으로 사용하는 경우 +10 또는 + 20GB

마운트 포인트 / home을 사용하는 경우

• 사용 가능한 경우 모든 여유 공간을 지정하십시오. / home ne

마운트 포인트 / opt를 사용하는 경우

마운트 포인트 / usr을 사용하는 경우

• 이것은 까다 롭고 설치된 소프트웨어 기반에 크게 의존합니다.

마운트 포인트 / var를 사용하는 경우

• 이것은 까다 롭고 설치된 소프트웨어 기반에 크게 의존합니다.
• 예를 들어, 데이터베이스가 모든 Linux가 아닌 데비안 기반 시스템에 여기에 데이터를 기록합니다.
• 별도의 / var / tmp를 갖는 것은 무리가 없습니다

마운트 포인트 / tmp를 사용하는 경우

• tmpfs가 존재하고 / tmp를 RAM에 할당 한 것으로 간주
• 일부 응용 프로그램은 여기에 많은 데이터를 쓸 수 있습니다

우선, 왜 당신이 여기 에이 질문을 게시했는지, 하드 드라이브 파티션의 더 좋은 점에 대해 분명히 유능한 시스템 관리자와 논쟁하고있는 생물 학자 인 질문을해야합니다! (죄송합니다. 왜 sysadmin을 신뢰하지 않는지 궁금합니다.)

따라서 몇 가지 관찰 사항은 다음과 같습니다.

• 1.3TB는 더 이상 큰 드라이브가 아닙니다. 2TB는 요즘 데스크탑 세계에서 표준 SATA 드라이브 크기입니다.

• 모든 Linux Distro 설치에는 100GB 이상이 필요하지 않습니다. 확실히 / (루트) 및 (스왑)의 크기는 크기를 충분히 크게 (루트 용) 또는 시스템 구성 지침 (스왑)에 의해 상한으로 쉽게 결정해야합니다.

• / home의 마운트 지점은 40TB RAID 서버에서 무언가를 가리켜 야합니다. 사용자의 홈 디렉토리 인 해당 데이터가 해당 루트 장치의 어느 곳에 나있을 필요는 없습니다. RAID 서버에 배치하면 보호 기능이 향상 될 수 있습니다. 서버 박스에 내장 된 작은 RAID는 그렇지 않은 반면 NAS는 쉽게 확장 가능한 NAS 기능 일 것입니다.

• OS 업데이트 및 루트 파티션 와이프에서이를 보존 할 수 있도록 특수 소프트웨어를 별도의 파티션 (/ usr / local / bin의 마운트 지점 등)에 넣어야합니다. 그렇지 않으면 OS 업그레이드 / 수정 / 무엇을 수행 한 후에 "특별한"소프트웨어 앱을 다시 설치해야 할 가능성에 직면하게됩니다.

• 시스템 관리에 대해 걱정하고 싶다면 다른 질문을하겠습니다. 건물이 화재를 당하고 서버와 RAID 상자가 파괴 된 후 재해 복구 프로세스는 무엇입니까? 관심있는 데이터가 완전히 머리 속에 남아 있지 않는 한, 이는 모든 사용자가 IT / 시스템 관리자에게 질문해야하는 문제입니다. 이 전략에는 "필요한 하드웨어를 복제하는 방법"및 "백업 및 실행에 걸리는 시간"과 같은 질문이 포함되어야합니다. 서버 가상화에 대한 일부 논의는 OS를 재구성 할 필요없이 하드웨어 종속성과 관련된 문제를 해결하고 백업 및 실행하는 데 도움이 될 수 있습니다 (변경되지 않는 "소프트"장치 환경에서 실행되도록 구성 할 수 있기 때문에,

• 마찬가지로 프로그램 및 사용자 오류 데이터 손실로부터 사용자 데이터를 보호하기위한 전략이 무엇인지 물어볼 수 있습니다. 연구 논문의 초안 위에 빈 파일을 저장하거나 사용자가 잘못된 명령 (예 : rm -rf *)을 입력하면 지진, 화재 또는 기타 물리적 손상과 마찬가지로 데이터가 손실 될 수 있습니다. 개별 파일 복구 솔루션은 도매 재해 복구에 가장 유용한 솔루션과 약간 다릅니다 (또는 가능할 수도 있습니다).

-

이를 통해 사용자 데이터와 독립적으로 운영 체제를 백업, 복원 또는 재설치 할 수 있습니다. 이것은 당신에게 자유, 독립 및 안전을 제공합니다.

1. 여전히 대다수의 사용자 데이터를 보존하는 다른 Linux 배포로 쉽게 마이그레이션 할 수 있습니다.

2. 운영 체제 파티션의 백업을 적용하여 버그가있는 업데이트를 쉽게 되돌릴 수 있습니다 (이중 부팅 필요). 이 백업은 다소 오래된 것일 수도 있습니다. 백업을 적용하고 나중에 안정적인 버전으로 업데이트 할 수 있습니다.

3. 최근에 적용된 "주요 업그레이드"(이중 부팅 필요)가 마음에 들지 않으면 이전 버전의 운영 체제로 되 돌리는 것이 간단합니다.

이 방법을 최대한 활용하려면 운영 체제를 다른 운영 체제에서 실행하는 동안 한 운영 체제 파티션을 덮어 쓸 수 있도록 이중 부팅 (CentOS / CentOS 일 수도 있음)도 구성해야합니다. 그리고 적어도 몇 달에 한 번 시스템 파티션을 백업해야합니다.

짧은 대답은 데스크탑조차도 "하나의 큰 파티션"을 사용해서는 안된다는 것입니다. 나는 최근에 "단지 랩톱"이었고 자동 설치 프로그램이 단일 파티션을 사용했기 때문에 더 나은 판단에 반대하여 시도했지만 버튼을 클릭했습니다.

다른 배포판을 설치하려고 할 때 설치 관리자가 기존 배포판 위에 설치하지 않기 때문에 드라이브를 다시 파티션해야했습니다. 자체 파티션에 있으면 / home을 그대로 유지할 수 있습니다. 그래서 gparted live-cd를 부팅하고 파티션을 축소하고 / home 및 기타 파티션을 새로 만들고 데이터를 새 파티션으로 옮긴 다음 새로운 OS의 설치 프로그램으로 부팅했습니다.

이상적으로는 SSD에 /를, 하드 드라이브에 / home을, 하드 드라이브에 / var를, / usr은 업그레이드 계획 빈도에 따라 SSD 또는 HDD에있을 수 있습니다. / tmp를 하드 드라이브로 나는 보통 내 / home에서 심볼릭 링크가있는 mp3 및 영화와 같은 공유 미디어 파일을위한 다른 파티션을 만듭니다. / sbin은 루트의 일부이며 / bin 및 / root입니다. / bin과 / usr / bin의 차이점은 / usr은 모든 드라이브가 마운트 될 때까지 사용할 수없는 것들이므로 mount 명령은 / usr에있을 수 없습니다! 나는 일반적으로 다른 리눅스 배포판을 위해 여분의 파티션을 두 개 이상 유지합니다. 이것은 실제로 나쁜 것을 망칠 경우를 대비하여 gparted one이 내 하드 드라이브에 있다는 것입니다. 복구 작업을 할 준비가 된 다른 라이브 시스템이 있습니다.

물건을 옮겨 다니고, 스토리지를 동적으로 추가하고 항상 유지해야하는 서버의 경우 반드시 LVM을 사용하십시오 !!!

/ usr / local에 소프트웨어를 설치할 필요는 없으며 / home에있는 다른 접두사로 모든 ​​소프트웨어를 설치할 수 있습니다. 대부분의 소프트웨어는 다음을 실행하여 소스에서 컴파일 할 때이 작업을 수행 할 수 있습니다. ./configure --prefix=/home/bin

당신은 생물 학자이기 때문에 rpm이나 deb에 제대로 패키징되지 않은 많은 소프트웨어에 관심이있을 수 있으며 어쨌든 소스에서 컴파일해야합니다.

저는 사용자들 사이에 많은 생물 학자들이있는 HPC 시스템의 sysadmin입니다. 우리는 그들이 요청한 모든 소프트웨어를 / apps / 파일 시스템 아래에 설치합니다. 매우 힘들다. 이 문제를 해결하기 위해 내 동료와 EasyBuild (무료 및 오픈 소스) 라는 도구를 작성했습니다. 소스에서 소프트웨어를 컴파일하고 설치하고 다른 폴더에 설치하고 자동으로 환경 모듈 파일을 만들 수 있습니다. 실제로 동일한 소프트웨어의 두 가지 버전을 설치할 수 있으며 충돌이 없습니다.

하나의 명령으로 설치할 수 있는 패키지 목록을 살펴보십시오 . 생물학자는 많은 것을 인식 할 수 있습니다. ;-)

면책 조항 : 저는 EasyBuild의 개발자입니다

필자는 초보자 / 입문 * ix 사용자에게는 일반적으로 시스템의 특성에 대해 더 많이 배울 때까지 파티션이 가장 적을 수 있다고 생각합니다. 그러나 여러 가지 이유로 단순히 하나의 패리티 션을 가질 수 없으며 귀하의 경우에는 아닙니다.

이에 대한 첫 번째이자 실질적인 이유는 대부분의 모든 Linux 시스템에 스왑 파티션이 필요하고 (일반적으로 RAM이 1-2 * 여야 함) 별도의 시스템, 부팅 또는 홈 파티션이 필요하고 UEFI가 Linux 시스템을 부팅하는 경우 EFI 파티션 (500MB 만)

두 번째 이유, 특히 상황에 해당하는 것은 6x 300GB 드라이브를 가져 와서 습격하는 것이 6 가장 좋은 것은 아닙니다. 새로운 기술이지만 Raid 6은 보편적으로 더 나은 시스템으로 환영하지만 스트라이핑 알고리즘이 더 필요하고 정보를 저장하는 데 필요한 공간 (RAID 5와 비교)이 더 큽니다.

말할 것도없이 RAID 6에는 추가 하드웨어가 필요합니다. 제 생각에는 디스크 고장, 다운 타임, 재난 복구 또는 추가 기술 지원 비용을 피하기 위해 더 큰 디스크를 구입하는 데 사용해야합니다. 많은 사람들이 저와 동의하지 않을 것이며, 향후 2 년 동안 디스크의 크기가 커질 때 (마지막 몇 년 동안 가격이 하락했을 때) RAID6가 더 큰 어레이와 대기업은 명백한 선택이 될 것입니다. 그러나이 경우 RAID 6을 사용하지 않는 것이 좋습니다.

두 번째 (비 RAID 기반) 문제의 경우, 미러 될 때 하나의 거대한 파티션을 작성하면 효과가있을 수 있지만, 효율성을 극대화하려면 더 큰 드라이브와 여러 파티션을 사용하십시오. 이렇게하면 이중 디스크 오류가 발생하면 / dev + / dir에 따라 특정 마운트 지점에서 다운 타임이 발생하지 않습니다.

어떤 이유로 든 커널이 부팅하지 않기로 결정한 경우 복구 커널, 원격 부팅 또는 PXE, 디스크 부팅 등 커널을 사용하고 회사가 d- 복구 프로세스가 진행되는 동안 정보에 대한 광범위한 액세스.

귀하의 회사는 시스템이 작동하는 한 이러한 악센트에 신경 쓰지 않을 수도 있지만 사람들이 왜 일을하는지 이유를 설명하려고합니다. 나는 또한이 주장에 반대하여 다른 사람들의 의견을 듣고 다른 요점들을 제기하고 싶습니다. 동의하지 않으면 이유를 알려주십시오. 포스터-나는 당신에게 몇 가지 링크도 PM합니다.

Linux 커뮤니티 스펜서 라이저에 대한 사랑

PS 특히 네트워크 서버 나 일반인이 사용할 수있는 시스템에서는 자격 증명을 통해 파티션을 분리하는 것이 가장 좋습니다. 다른 사람들은 여기에 더 많은 것을 입력 할 수 있습니다. 더 많은 커피가 필요합니다.