오픈 소스 백업 도구 유지 관리: 통찰력 등-Golang-php.cn

백업 전략은 해결된 문제처럼 보일 수 있지만 시스템 관리자는 데이터를 올바르게 백업하는 방법, 저장할 위치, 다양한 소프트웨어 환경에서 백업 프로세스를 표준화하는 방법에 대한 질문으로 어려움을 겪는 경우가 많습니다. 2011년에 우리는 고객의 웹 프로젝트에 대한 백업을 효율적으로 처리하는 사용자 정의 백업 스크립트를 개발했습니다. 이 스크립트는 필요에 따라 스토리지와 외부 저장소 모두에 백업을 저장하여 수년 동안 우리에게 도움이 되었습니다. 그러나 소프트웨어 생태계가 성장하고 다양해짐에 따라 Redis 및 MySQL/PostgreSQL과 같은 새로운 기술에 대한 지원이 부족하여 스크립트가 부족했습니다. 이메일 알림 외에는 모니터링 시스템이 없어 스크립트도 번거로워졌습니다.

한때 간결했던 스크립트는 복잡하고 관리하기 어려운 시스템으로 발전했습니다. 특히 맞춤형 버전을 사용하는 경우 다양한 고객을 위해 이러한 스크립트를 업데이트하는 것이 어려워졌습니다. 작년 초에 우리는 보다 현대적인 솔루션이 필요하다는 것을 깨달았습니다.

이 기사에서는 nxs-backup을 개발하면서 겪었던 모든 어려움을 설명하고 경험과 어려움을 공유하겠습니다. 또한 프로젝트에서 도구를 테스트하고 경험을 공유할 수도 있습니다. 우리는 귀하의 의견을 매우 환영합니다. 이제 시작해 보겠습니다!

새 시스템에 대한 요구 사항을 나열했습니다.

가장 일반적으로 사용되는 소프트웨어의 백업 데이터: (파일: 개별 및 증분, MySQL, PostgreSQL, MongoDB, Redis)
인기 있는 저장소에 백업 저장: (FTP; SSH; SMB; NFS; WebDAV; S3);
백업 과정에서 문제가 발생할 경우 알림을 받습니다.
백업을 중앙에서 관리할 수 있는 통합 구성 파일이 있습니다.
외부 모듈을 연결하여 새로운 소프트웨어에 대한 지원을 추가합니다.
덤프 수집을 위한 추가 옵션 지정
표준 도구를 사용하여 백업을 복원할 수 있습니다.
초기 구성이 용이합니다. 이러한 모든 요구 사항은 약 5년 전 우리의 요구 사항을 기반으로 나열되었습니다. 아쉽게도 모두 공개되지는 않았습니다.

nxs-backup의 첫 번째 버전을 만들기 전에도 이미 존재했던 오픈 소스 솔루션을 살펴보았습니다. 하지만 그들에게는 모두 결점이 있었습니다. 예를 들어, Bacula는 우리에게 불필요한 기능으로 과부하가 걸리고, 초기 구성은 많은 수작업으로 인해 오히려 힘든 작업(예: 데이터베이스 백업의 스크립트 작성/검색)이며, 복사본을 복구하려면 특수 유틸리티를 사용해야 합니다. 등

도구를 다시 작성하려고 하는 동안 동일한 문제에 직면했다는 것은 놀라운 일이 아닙니다. 4년 만에 뭔가가 바뀌고 온라인에서 새로운 도구가 등장할 가능성은 그다지 높지 않았지만 그래도 여전히 높았습니다.

이전에는 고려되지 않았던 몇 가지 새로운 도구를 연구했습니다. 그러나 앞서 논의한 것처럼 이러한 것 역시 우리에게 적합하지 않았습니다. 우리의 요구 사항을 완전히 충족하지 못했기 때문입니다.

우리는 마침내 두 가지 중요한 결론에 도달했습니다.

기존 솔루션 중 어느 것도 우리에게 완벽하게 적합하지 않았습니다.
처음으로 솔루션을 작성할 만큼 충분한 경험과 열정을 갖고 있었던 것 같습니다. 그리고 우리는 기본적으로 다시 그렇게 할 수 있습니다. 그래서 우리는 그렇게 했습니다.

새 버전을 살펴보기 전에 이전 버전이 무엇이고 왜 충분하지 않았는지 살펴보겠습니다.

이전 버전은 MySQL, PostgreSQL, Redis, MongoDB, 개별 및 증분 파일 복사, 다중 원격 저장소(S3; SMB; NFS; FTP; SSH; WebDAV)와 같은 DB를 지원했으며 백업 순환, 로깅과 같은 기능이 있었습니다. , 이메일 알림 및 외부 모듈.

이제 우리가 우려했던 내용을 자세히 살펴보겠습니다.

Linux에서 소스 파일을 다시 시작하지 않고 바이너리 파일 실행

시간이 지남에 따라 우리가 사용하는 시스템 목록이 상당히 늘어났습니다. 이제 우리는 Arch, Suse, Alt 등과 같은 표준 deb 및 rpm 호환 배포판 이외의 것을 사용하는 프로젝트를 제공합니다.

최근 시스템에서는 deb 및 rpm 패키지만 수집하고 제한된 시스템 버전 목록을 지원했기 때문에 nxs-backup을 실행하는 데 어려움이 있었습니다. 전체 패키지를 다시 뽑은 곳, 바이너리만 있는 곳, 소스 코드만 실행해야 하는 곳 등이 있습니다.

이전 버전으로 작업하는 것은 소스 작업이 필요하기 때문에 엔지니어에게 매우 불편했습니다. 이러한 모드에서는 설치 및 업데이트에 더 많은 시간이 걸린다는 점은 말할 것도 없습니다. 시간당 10개의 서버를 설정하는 대신 서버 1대에 1시간만 투자하면 됩니다.

우리는 시스템 종속성이 없는 바이너리가 있으면 모든 배포판에서 실행할 수 있고 다양한 버전의 라이브러리와 시스템의 아키텍처 차이로 인해 문제가 발생하지 않는 것이 훨씬 더 좋다는 것을 오랫동안 알고 있었습니다. 우리는 이 도구도 동일하길 원했습니다.

nxs-backup으로 Docker 이미지를 최소화하고 구성 파일에서 ENV를 지원합니다

최근 컨테이너화된 환경에서 작업하는 프로젝트가 너무 많습니다. 이러한 프로젝트에는 백업도 필요하며 컨테이너에서 nxs-backup을 실행합니다. 컨테이너화된 환경에서는 이미지 크기를 최소화하고 환경 변수를 사용하여 작업할 수 있는 것이 매우 중요합니다.

이전 버전에서는 환경 변수를 사용할 수 있는 기회가 제공되지 않았습니다. 가장 큰 문제는 비밀번호를 구성에 직접 저장해야 한다는 것이었습니다. 이 때문에 비밀번호만 포함하는 변수 세트 대신 전체 구성을 변수에 넣어야 합니다. 대규모 환경 변수를 편집하려면 엔지니어의 집중력이 더 필요하며 문제 해결이 좀 더 어려워집니다.

또한 이전 버전으로 작업할 때 이미 큰 Debian 이미지를 사용해야 했고 올바른 백업을 위해 여러 라이브러리와 애플리케이션을 추가해야 했습니다.

슬림 버전의 이미지를 사용하더라도 ~250Mb의 최소 크기를 얻었는데, 이는 하나의 작은 유틸리티에 비해 상당히 많은 양입니다. 어떤 경우에는 이미지가 노드에 끌어온 시간 때문에 컬렉션 시작 프로세스에 영향을 미쳤습니다. 50MB 이하의 이미지를 얻고 싶었습니다.

퓨즈 없이 원격 저장소로 작업

컨테이너 환경의 또 다른 문제는 퓨즈를 사용하여 원격 스토리지를 마운트하는 것입니다.

호스트에서 백업을 실행하는 동안에도 여전히 허용됩니다. 올바른 패키지를 설치하고 커널에서 퓨즈를 활성화했으며 이제 작동합니다.

컨테이너에 퓨즈가 필요하면 상황이 더욱 흥미로워집니다. 호스트 시스템의 핵심에 직접 접근하여 권한을 업그레이드하지 않으면 문제가 해결되지 않으며 이는 보안 수준이 크게 저하됩니다.

모든 고객이 보안 정책을 약화시키는 데 동의하는 것은 아니므로 조정이 필요합니다. 그렇기 때문에 우리는 기억하고 싶지도 않은 엄청난 양의 해결 방법을 만들어야 했습니다. 또한 추가 계층은 실패 가능성을 높이고 마운트된 리소스의 상태에 대한 추가 모니터링이 필요합니다. API를 직접 사용하여 원격 저장소로 작업하는 것이 더 안전하고 안정적입니다.

상태 모니터링 및 이메일뿐만 아니라 알림 전송

오늘날 팀에서는 일상 업무에서 이메일을 점점 더 적게 사용하고 있습니다. 그룹 채팅이나 그룹 통화로 문제를 논의하는 것이 훨씬 빠르기 때문에 이해할 수 있습니다. Telegram, Slack, Mattermost, MS Teams 및 기타 유사한 제품이 널리 배포됩니다.

또한 다양한 알림을 보내고 이를 알려주는 봇도 있습니다. 그리고 물론 우리는 수백 개의 다른 이메일 중에서 이메일이 아닌 Telegram과 같은 작업 공간에서 백업이 중단된다는 보고를 보고 싶습니다. 그런데 일부 고객은 Slack이나 다른 메신저에서 장애에 대한 정보를 보고 싶어하기도 합니다.

또한 실시간으로 작업 상태를 추적하고 작업 세부정보를 확인할 수 있기를 오랫동안 원하셨습니다. 이렇게 하려면 애플리케이션의 형식을 변경하여 악마로 바꿔야 합니다.

실적 부족

또 다른 급성 통증은 특정 시나리오에서 성능이 부족하다는 것입니다.

클라이언트 중 한 곳은 거의 테라바이트에 달하는 거대한 파일 덤프를 가지고 있으며 모두 텍스트, 그림 등의 작은 파일입니다. 우리는 이 항목의 증분 복사본을 수집하고 있으며 다음과 같은 문제가 있습니다. 3일. 네, 글쎄요, 이전 버전은 하루 안에 그 볼륨을 소화하지 못합니다.

상황을 고려할 때 실제로 특정 날짜의 데이터를 복구할 수 없으며 이는 전혀 마음에 들지 않습니다.

처음에는 단순성과 유연성 때문에 Python으로 백업 솔루션을 구현했습니다. 그러나 수요가 증가함에 따라 Python 기반 솔루션은 부적절해졌습니다. 철저한 논의 끝에 우리는 다음과 같은 몇 가지 이유로 시스템을 Go로 다시 작성하기로 결정했습니다.

컴파일 및 종속성: Go의 AOT 컴파일러는 종속성이 없는 범용 바이너리를 생성하여 다양한 시스템에 걸쳐 배포를 단순화합니다.
성능: Go의 고유한 멀티스레딩 기능은 더 나은 성능을 약속합니다.
팀 전문성: Python보다 Go에 대한 경험이 풍부한 개발자가 더 많았습니다.

해결책 찾기

위의 모든 문제는 어느 정도 IT 부서에 상당한 고통을 안겨주어 확실히 중요한 일에 귀중한 시간을 소비하게 만들었지만 이러한 비용은 피할 수 있었습니다. 또한 특정 상황에서는 비즈니스 소유자에게 특정 위험이 발생했습니다. 특정 날짜에 데이터가 없을 확률은 극히 낮지만 0은 아닙니다. 우리는 상황을 받아들이기를 거부했습니다.

Nxs-backup 3.0

우리 작업의 결과는 최근 v3.8.0으로 업데이트된 nxs-backup v 3.0의 새 버전이었습니다
새 버전의 주요 기능:

모든 저장 시설과 모든 유형의 백업에 해당하는 인터페이스를 구현합니다. 작업 및 스토리지는 작업이 실행되는 동안이 아닌 시작 시 초기화됩니다.
API를 통해 원격 저장소로 작업하세요. 이를 위해 다양한 라이브러리를 사용합니다.
우리 프로젝트에서 사용하는 go-nxs-appctx 미니 애플리케이션 프레임워크 덕분에 구성에서 환경 변수를 사용합니다.
후크를 통해 로그 이벤트를 보냅니다. 다양한 레벨을 구성하여 원하는 레벨의 오류나 이벤트만 받아볼 수 있습니다.
백업 기간뿐만 아니라 특정 백업 횟수도 지정하세요.
이제 Linux 2.6 커널부터 백업이 간단하게 실행됩니다. 이를 통해 비표준 시스템으로 작업하는 것이 훨씬 쉬워지고 Docker 이미지를 더 빠르게 구축할 수 있게 되었습니다. 이미지 자체는 23MB로 줄었습니다(추가 MySQL 및 SQL 클라이언트 포함).
Prometheus 호환 형식으로 다양한 측정항목을 수집, 내보내기 및 저장하는 기능.
로컬 디스크 속도 및 원격 스토리지에 대한 리소스 소비를 제한합니다.

대부분의 구성과 애플리케이션 로직을 유지하려고 노력했지만 일부 변경 사항이 있습니다. 모두 이전 버전의 최적화 및 결함 수정과 관련된 내용입니다.

예를 들어 원격 저장소에 대한 연결 매개 변수를 기본 구성에 넣어 매번 다른 유형의 백업에 대해 규정하지 않습니다.

아래는 백업을 위한 기본 구성 예시입니다. 알림 채널, 원격 저장소, 로깅, 작업 목록 등의 일반 설정이 포함되어 있습니다. 이는 메일 알림이 포함된 기본 기본 구성이므로 이메일 알림을 기본 방법으로 사용하는 것이 좋습니다. 더 많은 기능이 필요한 경우 설명서에서 참조를 확인하세요.

server_name: wp-server
project_name: My Best Project

loglevel: info

notifications:
  mail:
    enabled: true
    smtp_server: smtp.gmail.com
    smtp_port: 465
    smtp_user: j.doe@gmail.com
    smtp_password: some5Tr0n9P@s5worD
    recipients:
      - j.doe@gmail.com
      - a.smith@mail.io
  webhooks: []
storage_connects: []
jobs: []
include_jobs_configs: [ "conf.d/*.conf" ]

로그인 후 복사

함정에 대한 몇 마디

우리는 특정한 어려움에 직면할 것으로 예상했습니다. 다르게 생각하는 것은 어리석은 일입니다. 하지만 두 가지 문제가 가장 큰 타격을 입혔습니다.

Image description

메모리 누수 또는 최적이 아닌 알고리즘

nxs-backup의 이전 버전에서도 우리는 자체적인 파일 보관 구현을 사용했습니다. 이 솔루션의 논리는 백업을 생성하기 위해 외부 도구를 사용하지 않으려는 것이었고, 파일 작업은 가능한 가장 쉬운 단계였습니다.

테스트에서 알 수 있듯이 실제로 많은 수의 파일에 특별히 효과적이지는 않았지만 솔루션은 실행 가능한 것으로 입증되었습니다. 그 당시 우리는 Python의 세부 사항에 대해 작성했고 Go로 전환하면 상당한 차이를 볼 수 있기를 바랐습니다.

드디어 새 버전의 로드 테스트를 실시했을 때 실망스러운 결과를 얻었습니다. 성능 향상은 없었고 메모리 소비도 이전보다 훨씬 높아졌습니다. 우리는 해결책을 찾고 있었습니다. 이 주제에 대한 많은 기사와 연구를 읽었지만 모두 "filepath.Walk" 및 "filepath.WalkDir"을 사용하는 것이 최선의 선택이라고 말했습니다. 이러한 방법의 성능은 새 버전의 언어가 출시될 때만 향상됩니다.

메모리 소비를 최적화하기 위해 증분 복사본을 만드는 실수도 했습니다. 그건 그렇고, 깨진 옵션이 실제로 더 효과적이었습니다. 당연한 이유로 우리는 사용하지 않았습니다.

결국 처리할 파일 수에 갇혀버렸습니다. 우리는 천만을 테스트했습니다. 가비지 컬렉터로는 이 정도 생성된 변수를 클리어할 수 없는 것 같습니다.

결국 여기에 너무 많은 시간을 투자할 수 있다는 사실을 깨닫고 우리는 오랜 시간 테스트를 거쳐 진정으로 효과적인 솔루션인 GNU tar를 선호하여 구현을 포기하기로 결정했습니다.

나중에 수천만 개의 파일을 처리할 수 있는 보다 효율적인 솔루션이 나오면 자체 구현 아이디어로 다시 돌아올 수도 있습니다.

이렇게 다른 FTP

ftp로 작업할 때 또 다른 문제가 발생했습니다. 동일한 요청에 대해 서로 다른 서버가 다르게 동작하는 것으로 나타났습니다.

그리고 동일한 요청에 대해 정상적인 답변을 받거나, 요청과 관련이 없어 보이는 오류가 발생하거나, 예상한 대로 버그가 발생하지 않는 것은 정말 심각한 문제입니다. .

그래서 우리는 더 단순한 "jlaffaye/ftp"를 선호하여 "prasad83/goftp" 라이브러리 사용을 포기해야 했습니다. 첫 번째 라이브러리는 Selectel 서버에서 제대로 작동하지 않았기 때문입니다. 오류는 연결 시 첫 번째 작업 디렉터리에서 파일 목록을 가져오려고 시도했는데 상위 디렉터리에 대한 액세스 권한 오류가 발생했다는 것입니다. "jlaffaye/ftp"를 사용하면 더 간단하고 서버에 요청을 보내지 않기 때문에 이러한 문제가 존재하지 않습니다.

다음 문제는 요청이 없을 때 연결이 끊어지는 문제였습니다. 모든 서버가 이런 방식으로 작동하는 것은 아니지만 일부 서버는 그렇습니다. 그래서 매번 요청하기 전에 커넥터가 떨어졌다가 다시 연결되었는지 확인해야 했습니다.

가장 중요한 문제는 서버에서 파일을 가져오는 문제, 즉 존재하지 않는 파일을 가져오려는 시도였습니다. 일부 서버는 이러한 파일에 액세스하려고 할 때 오류를 표시하고, 다른 서버는 읽을 수도 있는 유효한 io.Reader 인터페이스 객체를 반환하지만 빈 바이트만 얻습니다.

이러한 상황은 모두 경험적으로 발견된 것이므로 스스로 처리해야 합니다.

결론

가장 중요한 점은 엔지니어의 작업에 영향을 미치고 비즈니스에 특정 위험을 초래하는 이전 버전의 문제를 해결했다는 것입니다.

다음과 같이 지난 버전에서 아직 실현되지 않은 '원하는 것'이 있습니다.