머리말
백업이라고하는 것 : 원본 데이터가 손상되거나 손실되거나 기타 문제가 발생하는 경우 데이터를 다른 위치로 복사합니다. 데이터 손실로 인해 작업이 완전히 불가능한 것을 방지하기 위해 중요한 데이터를 복원 할 수 있습니다.
저장 매체에는 모바일 하드 드라이브, CD 및 웹 드라이브가 포함됩니다. 백업 습관을 개발하려면 회사는 오프 사이트로 백업해야합니다.
1. Linux 시스템에서 백업해야하는 데이터
/ root / directory
/ home / directory
/ var / spool / mail / directory
/ etc / directory
기타 디렉토리
자세한 설명 :
/ root /의 많은 중요한 데이터는 / root /의 홈 디렉토리에 저장되어 있으며 시스템이 충돌하면 내부 데이터가 필요합니다.
/ home / 일반 사용자의 홈 디렉토리, 파일 서버 설정과 같은 많은 작업, 파일 서버 업로드 위치는 일반적으로 일반 사용자의 홈 디렉토리이며,이 디렉토리도 이때 백업해야합니다.
/ var / spool / mail / 메일 서버, 메일은 기본적으로 여기에 저장됩니다. 이번에는 메일 디렉토리를 백업해야합니다.
/ etc / 중요한 구성 파일의 저장 위치. 따라서이 디렉토리도 백업해야합니다.
bin 디렉토리는이 디렉토리가 시스템 시작에 매우 중요하지만 존재하지 않으면 시스템 시작 문제가 발생하지만 새 시스템을 다시 설치할 때이 / bin / 디렉토리의 내용은 동일합니다. 일반적으로 수정할 필요가 없으며 백업 할 필요도 없습니다.
로그 디렉토리도 고려한다면 로그를 백업 할 수 있습니다. 중요한 데이터 만 백업하십시오. 전체 디스크를 백업해도 괜찮지 만 너무 많은 하드 디스크 공간을 차지합니다. 리소스가 있으면 원래 컴퓨터와 똑같은 서버를 준비하여 첫 번째 서버가 다운되면 두 번째 서버를 즉시 교체 할 수 있습니다. 일부 중요한 네트워크 토폴로지 다이어그램에서는 실제로 일부 중요한 노드에 대해 실시간 백업을 수행해야합니다. Heartbeat 모니터링이 필요하며, 메인 서버가 다운되면 슬레이브 서버가 교체 할 수 있습니다.
1.1 설치 서비스 데이터
아파치는 데이터를 백업해야합니다
(1) 구성 파일
(2) 홈 페이지 디렉토리
(3) 로그 파일
자세한 설명 :
(1) 구성 파일 : 여기에 일부 기능 변경 사항을 저장합니다. 다시 구성하지 않으려면 저장해야합니다.
(2) 홈 페이지 디렉토리 : 전체 웹 사이트가이 디렉토리에 있으며 모든 웹 디렉토리를 백업해야합니다. 서버가 다운되면 웹 사이트는 적어도 다운되지 않습니다. 아파치를 구축하는 한이 웹 페이지를 다시 가져 와서 사용할 수 있습니다.
(3) 로그 파일 : 아파치의 경우 로그 파일이 여전히 더 중요합니다.
1.2 MySQL은 데이터를 백업해야합니다
소스 패키지로 설치된 mysql /usr/local/mysql/data/
: RPM 패키지로 설치된 mysql :/var/lib/mysql/
mysql에 문제가 발생하면 정확히 동일한 버전의 MySQL 환경을 설치하고이 디렉토리를 다시 복사하면 모든 데이터가 복원됩니다.
메일 서비스가 구축 된 경우 각 사서함의 정보와 각 사서함 사용자의 메일은 백업에서 중요한 위치입니다.
2. 백업 전략
전체 백업 : 전체 백업은 백업해야하는 모든 데이터를 백업하는 것을 의미합니다. 물론 전체 백업은 전체 하드 디스크, 전체 파티션 또는 특정 디렉터리를 백업 할 수 있습니다.
증분 백업 : 첫날 전체 데이터를 백업하고 그 후 매일 새로 추가 된 데이터 만 백업합니다.
차등 백업 : 첫 번째 날에는 전체 데이터를 백업하고 두 번째 날에는 새 데이터를 백업합니다. 세 번째 날에는 두 번째와 세 번째 날에 데이터를 백업합니다. 네 번째 날에는 두 번째 날을 넷째 날의 데이터. 등등
세 가지 백업의 장단점을 설명하십시오.
-
전체 백업 : 전체 백업은 완전한 데이터를 보장하며 가장 빠르고 편리하게 복원 할 수 있지만 전체 백업은 더 많은 하드 디스크 공간이 필요하고 더 오래 걸립니다. 따라서 전체 백업을 수행 할 가치가 있는지 고려하십시오. 중요한 서버라면 별도의 서버를 준비 할 수 있습니다. 서버가 중단 될 때까지 기다릴 수 없으며 복사본이 수동으로 복원됩니다. 대신 자동으로 감지되고 백업 서버가 직접 진행되므로 전체 백업보다 더 엄격합니다. 하트 비트 모니터링입니다. 전체 백업은 매번 완전히 백업되는 경우 더 많은 시스템 리소스를 사용합니다. 서버 부담이 커지고 기타 문제가 발생할 수 있으므로 이것이 기본적인 백업 전략입니다. 일반적으로 전체 백업은 하루 또는 일주일에 한 번 수행됩니다.
-
증분 백업 : 첫 번째 날에 원본 데이터가있는 경우 전체 백업을 수행해야하지만 두 번째 날이 백업되면 원본 데이터를 백업하지 않고 두 번째 날에만 새 데이터를 백업하면됩니다. 3 일째에 백업하면 처음 2 일의 데이터가 저장되고 3 일째의 새 데이터 만 백업하면됩니다. 이전과 비교하여 새로 생성 된 데이터를 백업하십시오. 백업 후 압축해야합니다. 이전 백업과 비교하여 각 백업에는 새 데이터가 있습니다.
이론상 증분 백업은 새 데이터가 분할 될 때마다 원본 데이터가 한 번만 백업되고 하드 디스크 공간을 가장 적게 차지하기 때문에 이론상 가장 좋습니다. 그러나 이러한 유형의 복구는 더 까다 롭습니다. 이점 : 백업 데이터의 양이 가장 적고 저장 공간이 가장 적습니다. 단점 : 복구가 더 번거 롭습니다. -
차등 백업 : 전체 백업과 증분 백업 간의 절충안으로 백업 할 때마다 첫 번째 전체 백업과 비교됩니다. 전체 백업에 비해 백업 일수가 늘어날수록 처음으로 백업 할 데이터의 양이 적어 (즉, 전체 백업이 적어) 증분 백업보다 복원이 편리합니다. 이 시점에서 타협 전략. 혜택은 제한적입니다.
실제로는 전체 백업과 증분 백업이 가장 많이 사용됩니다.
3. 요약
전체 백업
장점 : 전체 백업은 복원이 가장 빠르고 편리한 완전한 데이터를 보장합니다.
단점 : 너무 많은 하드 디스크 공간을 차지합니다.
증분 백업
장점 : 백업 할 데이터 양이 적고 저장 공간이 가장
적다 단점 : 복원이 번거 롭다
차등 백업
장점 : 전체 백업보다 저장 공간을 덜 차지하고 증분 백업보다 복원하기 쉽습니다. 이것은 그러한 방법 중 하나입니다.