또 다른 백업 - 스크립트 이상, 시스템보다 간단함

많은 백업 시스템이 있지만, 서비스를 제공하는 서버가 여러 지역과 클라이언트에 분산되어 있고 운영 체제를 관리해야 하는 경우 어떻게 해야 할까요?

좋은 일, 하브르!
내 이름은 나탈리아입니다. 저는 NPO Krista의 애플리케이션 관리자 그룹의 팀 리더입니다. 우리는 회사 프로젝트 그룹의 Ops입니다. 우리는 다소 독특한 상황에 처해 있습니다. 우리는 회사 서버와 클라이언트 사이트에 있는 서버 모두에 소프트웨어를 설치하고 유지 관리합니다. 이 경우 전체 서버를 백업할 필요는 없습니다. "필수 데이터"(DBMS 및 개별 파일 시스템 디렉터리)만 중요합니다. 물론 클라이언트에는 자체 백업 규정이 있거나 없으며 백업을 저장할 수 있는 일종의 외부 저장소를 제공하는 경우가 많습니다. 이 경우 백업을 생성한 후 외부 저장소로 전송을 보장합니다.

한동안 백업 목적으로 bash 스크립트를 사용했지만 구성 옵션이 늘어남에 따라 이 스크립트의 복잡성도 그에 비례하여 커졌습니다. 어느 시점에서 우리는 "이 스크립트를 완전히 파괴한 다음 ...”.

기성 솔루션은 백업 분산 필요성, 클라이언트에 백업을 로컬로 저장해야 하는 요구 사항, 설정의 복잡성, 가져오기 대체, 액세스 제한 등 다양한 이유로 적합하지 않았습니다.

우리 자신의 것을 쓰는 것이 더 쉬운 것 같았습니다. 동시에 나는 향후 N년 동안 우리 상황에 충분하면서도 잠재적으로 범위를 확장할 수 있는 가능성을 갖고 싶었습니다.

임무의 조건은 다음과 같았습니다.

1. 기본 백업 인스턴스는 자율적이며 로컬로 실행됩니다.
2. 백업 및 로그 저장은 항상 클라이언트 네트워크 내에 있습니다.
3. 인스턴스는 일종의 "생성자"인 모듈로 구성됩니다.
4. 오래된 Linux 배포판을 포함하여 현재 Linux 배포판과의 호환성이 필요하며 잠재적인 크로스 플랫폼이 바람직합니다.
5. 인스턴스 작업을 위해서는 SSH를 통한 액세스로 충분하며 추가 포트를 열 필요가 없습니다.
6. 설정 및 작동의 최대 용이성
7. 서로 다른 서버의 백업 상태를 중앙에서 볼 수 있는 별도의 인스턴스를 갖는 것이 가능합니다(필수는 아님).

여기서 우리가 생각해낸 것을 볼 수 있습니다: github.com/javister/krista-backup
소프트웨어는 python3으로 작성되었습니다. Debian, Ubuntu, CentOS, AstraLinux 1.6에서 작동합니다.

문서는 저장소의 docs 디렉토리에 게시됩니다.

시스템이 작동하는 기본 개념:
작업 – 하나의 원자적 작업(데이터베이스 백업, 디렉터리 백업, 디렉터리 A에서 디렉터리 B로 전송 등)을 구현하는 작업입니다. 기존 작업은 core/actions 디렉터리에 있습니다.
작업 – 작업, 하나의 논리적 "백업 작업"을 설명하는 일련의 작업
일정 – 일정, 작업 실행 시간을 선택적으로 표시하는 작업 집합

백업 구성은 yaml 파일에 저장됩니다. 일반 구성 구조:

• 일반 설정
• 작업 섹션: 이 서버에서 사용되는 작업에 대한 설명
• 일정 섹션: 모든 작업(작업 세트)에 대한 설명 및 실행이 필요한 경우 cron에 의한 실행 일정

예시 구성은 여기에서 찾을 수 있습니다.

현재 애플리케이션이 수행할 수 있는 작업은 다음과 같습니다.

• 주요 작업이 지원됩니다: pg_dump를 통한 PostgreSQL 백업, tar를 통한 파일 시스템 디렉터리 백업; 외부 저장소를 사용한 작업; 디렉토리 간 재동기화; 백업 순환(오래된 복사본 삭제)
• 외부 스크립트 호출
• 별도의 작업을 수동으로 실행

  /opt/KristaBackup/KristaBackup.py run make_full_dump

• crontab에 단일 작업이나 전체 일정을 추가(또는 제거)할 수 있습니다.

  /opt/KristaBackup/KristaBackup.py enable all

• 백업 결과를 기반으로 트리거 파일을 생성합니다. 이 기능은 Zabbix와 함께 백업 모니터링에 유용합니다.
• webapi 또는 웹 모드로 백그라운드에서 작업 가능

  /opt/KristaBackup/KristaBackup.py web start [--api]

모드 간의 차이점: webapi에는 웹 인터페이스 자체가 없지만 애플리케이션은 다른 인스턴스의 요청에 응답합니다. 웹 모드의 경우 플라스크와 여러 추가 패키지를 설치해야 하며 이는 인증된 AstraLinux SE와 같이 모든 곳에서 허용되지 않습니다.

웹 인터페이스를 통해 연결된 서버의 백업 상태와 로그를 볼 수 있습니다. "웹 인스턴스"는 API를 통해 "백업 인스턴스"로부터 데이터를 요청합니다. 웹에 액세스하려면 승인이 필요하지만 webapi에 액세스하려면 승인이 필요하지 않습니다.

잘못된 백업 로그는 경고 – 노란색, 오류 – 빨간색으로 표시됩니다.

관리자가 매개변수에 대한 치트 시트가 필요하지 않고 서버 운영 체제가 동종인 경우 파일을 컴파일하여 기성 패키지를 배포할 수 있습니다.

우리는 이 유틸리티를 주로 Ansible을 통해 배포하고, 가장 중요도가 가장 낮은 일부 서버에 먼저 롤아웃하고 나머지 모든 서버에 대해 테스트한 후 배포합니다.

그 결과, 자동화가 가능하고 경험이 없는 관리자도 사용할 수 있는 컴팩트한 독립형 복사 유틸리티를 얻게 되었습니다. 그것은 우리에게 편리합니다. 어쩌면 당신에게도 유용할까요?

출처 : habr.com