질문을 시작하기 전에 저는 시스템 관리자가 아니라 도움을 구하는 평신도라는 점만 말씀드리겠습니다.
저는 Linux 3.10.0-514.26.2.el7.x86_64 및 Amazon Web Services 외부 백업 서비스를 사용하고 있습니다. 이것이 작동하려면 내 서버에 백업 디렉터리가 필요합니다. 여기서 모든 파일은 압축되고 외부 백업 서비스에 의해 복사되고 액세스됩니다.
문제는 - 해당 디렉토리에 별도의 파티션을 마운트해야 합니까?입니다. 백업에는 많은 HD 공간이 필요할 수 있으며, 이러한 목적을 위해 별도의 파티션을 사용하면 이론적으로 사용 가능한 디스크 공간이 부족하여 발생하는 문제로부터 일상적인 서버 작업과 웹 사이트를 보호해야 합니다.
하지만 이것이 올바른 접근 방식일까요? 더 좋은 것이 있나요?
답변1
나는 다른 답변에 정중하게 동의하지 않으며 다양한 방법으로 Linux 서버를 유지 관리하려면 적절한 파티셔닝이 필수적이라고 말합니다(Windows에 대해서는 내 경험이 아니기 때문에 많이 말할 수 없습니다).
저는 항상 백업을 위해 별도의 파티션을 사용하는데, 이는 공간을 적절하게 계획하는 것뿐만 아니라 복구 프로세스에도 매우 도움이 되었습니다. 아래에 간략하게 설명하겠습니다(휴대폰에서 입력할 때 형식이 잘못되었더라도 양해해 주세요).
별도의 파티션을 사용하면 어떤 것이 해당 파티션의 모든 여유 공간을 차지하더라도 나머지 시스템에는 영향을 주지 않는 용량 격리가 가능합니다. 예를 들어 /var/log를 생각해 보세요. 사용자가 의도치 않게 logrotate를 중단하고 로그가 루트의 100%를 사용한 서버를 본 적이 있습니다(또는 예를 들어 트래픽이 갑자기 증가할 때 발생할 수 있음).
AWS의 경우 별도의 디스크에 있는 별도의 파티션을 사용하면 이를 다른 인스턴스에 마운트하고 거기에서 데이터를 복원할 수 있습니다(예: 법의학 조사용).
(백업 관련뿐만 아니라) 별도의 파티션을 사용하면 마운트할 때 noexec 속성을 설정하여 침입 가능성을 최소화할 수 있습니다. (실제로 실행 파일이 있는 파티션을 제외한 시스템의 대부분의 파티션에 대해 이 작업을 수행해야 합니다.)
이제 이것이 AWS 시스템이라고 언급하셨기 때문에 서버에 별도의 EBS 디스크를 마운트하는 대신 S3fs 확장을 활용하고 S3 버킷을 백업용 파티션으로 마운트하는 것이 좋습니다. 이것의 이점은 s3의 데이터 내구성이 뛰어나다는 것입니다.
참고 2가지 사항: 항상 성공적인 백업 실행을 모니터링해야 하며 정기적으로 데이터 복구 가능성을 테스트해야 합니다.예를 들어 Gitlab에 일어났습니다.)
또한 다른 EBS 디스크를 사용하기로 결정한 경우 - LVM을 사용하지 마십시오. 여러 디스크에 걸쳐 LVM 파티션을 조각화하면 쉽게 데이터 손실이 발생할 수 있습니다(불행히도 LVM은 작성자가 원하는 만큼 아직 좋지 않습니다). 2 - 이제 AWS에서 EBS 디스크를 확장할 수 있으므로 LVM 조각화 없이 더 많은 공간을 추가할 수 있습니다.
답변2
아니요. 귀하의 경우 파티션은 장기적으로 삶을 더 힘들게 만들 뿐입니다. 미래에 발생할 수 있는 * 실패 가능성을 곱하면 됩니다 .
디스크 공간 부족 문제 클래스에 대한 솔루션은 두 가지입니다.
- 모니터링(즉각적 반응).
- 용량 계획(장기적으로).
이러한 사항을 구현하고그 다음에당신은 당신이 일부를 찾을 것입니다매우 신비한활동으로 인해 백업 크기가 갑자기 급증할 수 있는 경우 파티셔닝을 도입해야 한다는 (불확실한) 주장이 있을 수 있습니다.
[*] 시스템 관리자로서 당신의 첫 번째 의무(실제로 당신도 그렇습니다)는 사용자보다 훨씬 더 비관적이어야 합니다.