Databasement DB 백업 관리자 2026, 셀프호스팅 복구·보안·운영 기준

Databasement DB 백업 관리자 셀프호스팅 백업과 복구 검증을 보여주는 보안 운영실 — Databasement는 백업 스케줄보다 복구 테스트, 권한, 저장소 설계까지 같이 봐야 운영 가치가 생긴다.

Databasement DB 백업 관리자를 검토하는 팀은 보통 작은 운영 공백에서 출발한다.

PostgreSQL, MySQL, MongoDB, Redis 같은 데이터 저장소가 늘었지만 백업 스크립트는 서버마다 흩어져 있고, 복구 테스트는 담당자 기억에 기대는 상태다.

결론부터 말하면 Databasement는 범용 데이터 플랫폼이라기보다 웹 UI가 있는 셀프호스팅 DB 백업·복구 운영 콘솔에 가깝다.

그래서 도입 판단은 “설치가 쉬운가”보다 “복구 목표, 권한, 저장소, 실패 알림, 감사 증거를 통제할 수 있는가”로 봐야 한다.

이 글은 GitHub 저장소와 Databasement 공식 문서 기준으로 Docker 배포, 지원 DB, API 토큰, 복구 검증, 비용·보안 운영 기준을 분리해 정리한다.

핵심 요약

Databasement는 MySQL, PostgreSQL, MariaDB, SQL Server, MongoDB, SQLite, Firebird, Redis, Valkey 백업을 한 UI에서 관리하는 셀프호스팅 도구다.
공식 Docker 경로는 포트 2226, SQLite 또는 외부 애플리케이션 DB, 백업 작업용 queue worker를 전제로 한다.
오픈소스라 라이선스 비용보다 저장소, 알림, 권한, 복구 테스트, 운영 담당자 시간이 실제 예산을 만든다.
운영 전에는 “백업 성공”이 아니라 “다른 서버에 복구했고 서비스 owner가 확인했다”를 통과 기준으로 잡아야 한다.

이 글이 필요한 사람

여러 DB 백업 스크립트가 서버마다 흩어져 있어 웹 UI 기반 운영 콘솔을 찾는 플랫폼 담당자
셀프호스팅 도구를 쓰고 싶지만 백업 저장소, 권한, 복구 테스트 기준을 먼저 정해야 하는 DevOps 팀
상용 백업 솔루션 견적 전에 오픈소스 DB 백업 관리자의 실제 운영 부담을 비교하려는 CTO
랜섬웨어와 실수 삭제 대비로 RPO, RTO, 복구 리허설 증거를 남겨야 하는 보안팀
PostgreSQL, MySQL, MongoDB, Redis, SQLite가 섞인 소규모 SaaS 또는 내부 시스템 운영자

Databasement를 데이터 플랫폼이 아니라 DB 백업 운영 콘솔로 본다

GitHub README 기준 Databasement는 MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, MongoDB, SQLite, Firebird,

Redis와 Valkey를 단일 인터페이스에서 관리하는 self-hosted database backup manager다.

주요 기능은 자동 백업, 교차 서버 복원, 예약 복원, SSH 터널, 원격 에이전트, S3 호환 저장소, Azure Blob, Samba, SFTP, FTP, 실패 알림, REST 연동이다.

여기서 핵심은 “모든 데이터를 한곳에 모으는 플랫폼”이 아니라 “백업 작업과 복구 작업을 누가, 언제, 어떤 권한으로 실행했는가”를 관리하는 운영 표면이다.

이미 백업 솔루션을 쓰고 있는 대기업이라면 Databasement가 중복일 수 있다.

반대로 스크립트와 cron, 운영자 개인 문서에 백업 책임이 흩어진 팀이라면 작은 콘솔 하나가 사고 대응 시간을 줄일 수 있다.

검토 관점	Databasement가 맞는 조건	보류할 조건	실무 질문
DB 종류	오픈소스 DB와 일부 상용 DB가 섞여 있다	전사 표준 백업 제품이 이미 모든 DB를 관리한다	지원 버전과 restore 여부가 공식 표와 맞는가
네트워크	SSH 터널이나 원격 에이전트로 사설망 백업이 필요하다	운영망 정책상 외부 UI와 agent 설치가 금지된다	인바운드 포트 없이 아웃바운드 연결만 허용할 수 있는가
저장소	S3 호환 스토리지나 SFTP에 백업을 모으고 싶다	백업 파일을 중앙 저장소에 둘 보안 기준이 없다	암호화, 보존, 접근 로그를 어디에서 확인하는가
복구	스테이징 복원과 예약 복원으로 검증하고 싶다	복구 테스트를 운영 시간에만 수동으로 한다	최신 완료 스냅샷을 어느 대상에 재생할 것인가
팀 운영	RBAC, OAuth 또는 OIDC, 2단계 인증을 붙일 계획이 있다	관리자 1명 계정으로 모두 접속한다	백업 실행 권한과 데이터 조회 권한을 분리했는가

이 조건이면 먼저 파일럿을 검토한다.

운영 DB가 5개 이상이고, 복구 테스트가 분기마다 한 번도 안 닫히며, 백업 실패 알림이 이메일 하나에 묻히는 경우다.

이 경우는 보류가 맞다.

백업 대상 DB 계정 권한, 저장소 암호화, 사내 네트워크 정책, 복구 책임자가 아직 정해지지 않은 상태다.

공식 문서 기준 빠른 배포 흐름

Databasement Docker 문서는 단일 컨테이너 배포가 가장 단순한 방법이라고 설명한다.

SQLite quick start는 프로젝트 디렉터리 생성, APP_KEY 생성, .env 작성, 포트 2226 컨테이너 실행, 관리자 계정 생성 흐름으로 시작한다.

Docker Compose 문서는 app과 worker를 나누고, worker가 backups와 default queue를 처리하는 구성을 제시한다.

운영 파일럿은 단일 컨테이너로 UI를 확인한 뒤 Docker Compose로 worker 분리, 외부 애플리케이션 DB, 저장소 권한, health endpoint를 붙이는 순서가 안정적이다.

단계	공식 문서에서 확인한 숫자	비용/운영 의미	실패하면 볼 것
컨테이너 포트	2226	리버스 프록시와 방화벽 정책을 이 포트 기준으로 맞춘다	프록시가 다른 base image 포트로 라우팅하지 않는지 확인
queue worker	tries 3회, timeout 3600초, max jobs 1000개	장시간 백업 작업과 worker 재시작 정책을 분리한다	worker 로그와 queue 상태를 먼저 본다
healthcheck	interval 10초, timeout 5초, retries 5회	compose 배포에서 app 준비 상태를 worker 시작 조건과 연결한다	curl /health 실패와 DB migration 로그 확인
기본 사용자	PUID/PGID 1000	볼륨 권한 오류가 운영 장애가 될 수 있다	호스트 uid/gid와 /data 소유권 확인
압축/암호화	zstd 20–40%, AES-256	저장소 비용과 민감 데이터 보호 기준을 같이 본다	압축률보다 복구 시간과 CPU 사용량도 테스트

소프트웨어 라이선스 비용만 보면 오픈소스 도구는 싸게 보인다.

하지만 운영 예산은 0원으로 끝나지 않는다.

백업 저장소 GB, 복구 테스트 환경, 알림 채널, SSO, 운영자 시간, 보안 검토, Docker host 패치가 모두 실제 비용이다.

REST API는 과금형 API가 아니라 Bearer token 인증으로 서버, 백업, 스냅샷, 저장소를 관리하는 기능이다.

공식 API 문서는 Settings → API Tokens에서 토큰을 만들고 Authorization 헤더에 넣는 방식을 설명하며, 입력 토큰·출력 토큰·USD 청구 모델을 제시하지 않는다.

지원 DB와 restore 범위를 먼저 확인한다

Database Servers 문서는 Databasement가 표준 CLI 도구로 백업과 복구를 수행한다고 설명한다.

이 표가 중요한 이유는 “연결된다”와 “복구된다”가 다르기 때문이다.

엔진	공식 지원 버전	사용 CLI	Restore
MySQL	5.6, 5.7, 8.x, 9.x	mariadb-dump	Yes
MariaDB	10.x, 11.x, 12.x	mariadb-dump	Yes
PostgreSQL	12, 13, 14, 15, 16, 17, 18	pg_dump v18	Yes
SQL Server	2017, 2019, 2022, Azure SQL	sqlpackage .dacpac	Yes
MongoDB	4.2, 4.4, 5.0, 6.0, 7.0, 8.0	mongodump / mongorestore	Yes
Redis/Valkey	Redis 2.8+, Valkey 7.2+	redis-cli --rdb	No

Redis와 Valkey는 백업만 되고 restore는 지원되지 않는다고 공식 문서가 분명히 적는다.

이 항목을 놓치면 “백업 목록에는 있다”는 이유로 복구 계획을 잘못 세울 수 있다.

SQL Server는 .dacpac 추출과 publish 방식이라 로그인, 사용자, 권한, role membership 같은 서버-bound 객체가 제외될 수 있다는 점도 별도 체크가 필요하다.

PostgreSQL은 RDS라면 rds_superuser, Azure라면 azure_pg_admin 같은 환경별 권한 모델을 확인해야 한다.

권한 설계는 백업 계정부터 쪼갠다

DB 백업 도구는 편해질수록 권한이 커진다.

Databasement 문서는 MySQL, PostgreSQL, SQL Server, MongoDB, Redis, SQLite, Firebird별 연결 요구사항과 권한 예시를 제공한다.

운영팀은 이 예시를 그대로 최고권한으로 열기보다 백업 대상과 복구 대상, read-only 백업, cross-server restore 요구를 나눠야 한다.

대상	권한 판단	위험	권장 운영
운영 DB 백업	백업과 schema 읽기에 필요한 최소 권한부터 시작	SUPERUSER나 sysadmin을 상시 저장하면 침해 피해가 커진다	예외 권한은 승인 티켓과 만료일을 둔다
복구 대상 DB	스테이징 또는 격리된 QA에 restore 권한 부여	운영 DB에 잘못 복구하면 데이터 손상	restore target 이름과 네트워크를 분리한다
SQLite 파일	SSH 터널과 SFTP 경로 접근이 필요	파일 경로 오입력과 권한 과다 부여	대상 경로 allowlist와 계정 분리
Adminer browsing	MySQL, PostgreSQL, SQLite 조회 권한을 role-gated로 제한	백업 콘솔이 데이터 조회 콘솔로 커진다	운영 데이터 조회 권한은 별도 승인
API Tokens	Settings에서 만든 Bearer token 관리	자동화 토큰 유출 시 백업·복구 작업 위험	scope, rotation, secret storage, audit log 확인

이 조건이면 권한 설계가 통과에 가깝다.

백업용 계정, 복구용 계정, UI 관리자, API 자동화 토큰이 분리되고, 운영 DB 복구 권한은 기본 차단된 경우다.

이 경우는 보류한다.

Databasement 관리자 계정 하나에 모든 DB의 최고 권한을 넣고, 실패 알림도 개인 이메일 하나만 받는 구조다.

저장소와 암호화는 비용표보다 먼저 확정한다

GitHub README는 로컬, S3 호환 스토리지, AWS S3, MinIO, Azure Blob, Samba, SFTP, FTP 저장소를 언급한다.

저장소 선택은 비용 문제이면서 보안 문제다.

S3 호환 저장소는 확장성과 수명주기 정책이 편하지만 IAM, bucket policy, object lock, egress 비용을 따로 봐야 한다.

로컬 저장소는 빠르고 단순하지만 랜섬웨어나 호스트 장애에 같이 묶일 수 있다.

저장소	비용이 생기는 지점	보안 체크	운영 판단
로컬 볼륨	디스크 증설, snapshot, host 백업	호스트 침해와 같은 장애 영역인지 확인	개발·파일럿에는 가능하지만 운영 단독은 위험
S3 호환	GB 저장량, 요청 수, 수명주기, egress	IAM 최소권한, 암호화, 공개 차단	운영 기본 후보
MinIO	서버 디스크, HA 구성, 운영 인력	root 계정과 bucket policy 관리	사내망 또는 폐쇄망에 적합
SFTP/FTP	서버 유지보수와 전송 실패 대응	FTP 평문 사용 금지, SFTP 키 관리	레거시 연동 때만 제한적으로 검토
Azure Blob	계정 권한, storage tier, 복구 테스트 비용	managed identity와 key rotation 확인	Azure 중심 조직이면 검토

비용 판단은 “어디가 제일 싸다”가 아니다.

백업 파일이 공격자와 같은 권한 영역에 있으면 저장 비용을 아껴도 복구 가능성이 사라진다.

따라서 파일럿부터 별도 계정, 별도 bucket, 별도 접근 권한, 실패 알림을 같이 구성해야 한다.

복구 테스트가 없는 백업 성공은 통과가 아니다

Databasement는 cross-server restore와 scheduled restore를 기능으로 내세운다.

프로덕션 스냅샷을 스테이징 같은 호환 서버로 복원하거나, 최신 완료 스냅샷을 정기적으로 재생해 대상 DB를 갱신하는 방식이다.

이 기능은 UI 편의보다 운영 통제 관점에서 더 중요하다.

백업 성공률은 높아도 복구가 느리거나 권한이 빠져 있으면 사고 때 쓸 수 없다.

테스트 항목	통과 기준	실패 예시	조치 owner
스냅샷 최신성	RPO 기준 안의 최신 완료 백업 존재	최근 백업이 48시간 이상 전	서비스 owner와 플랫폼팀
격리 복구	운영과 분리된 대상 DB에 restore 성공	운영 DB와 같은 네트워크에서 덮어쓰기 위험	DBA 또는 SRE
앱 검증	핵심 쿼리와 smoke test 통과	테이블은 복구됐지만 app migration mismatch	개발팀
알림	실패 시 Email, Slack, Discord, Telegram, Webhook 등 지정 채널 수신	알림이 개인 계정에만 도착	보안팀과 플랫폼팀
증거	작업 로그, 복구 시간, 담당자 확인 기록 보관	감사 때 성공 화면 캡처만 남음	컴플라이언스 담당자

실무 시나리오 하나를 보자.

소규모 SaaS 팀이 PostgreSQL 운영 DB와 MySQL 리포팅 DB를 갖고 있고, 백업은 각 서버 cron으로 흩어져 있다.

이 팀은 Databasement를 먼저 중앙 UI로 쓰기보다 스테이징 restore와 실패 알림을 통과 목표로 둔다.

첫 달 성공 기준은 “매일 백업”이 아니라 “주 1회 최신 스냅샷을 staging에 복원하고 smoke test 결과를 티켓으로 남김”이다.

원격 에이전트와 SSH 터널은 네트워크 정책과 함께 본다

GitHub README는 Databasement가 SSH 터널과 원격 에이전트를 지원한다고 설명한다.

SSH 터널은 bastion이나 jump server를 통해 사설망 DB에 접근할 때 유용하다.

원격 에이전트는 방화벽이나 격리 네트워크에서 인바운드 포트 없이 HTTPS 아웃바운드 연결로 로컬 덤프 후 저장소에 업로드하는 구조로 소개된다.

이 장점은 동시에 보안 검토 대상이다.

어느 쪽이든 DB 접근 자격증명, agent binary 신뢰, 네트워크 egress, 저장소 접근권한이 한 묶음으로 움직인다.

접근 방식	맞는 조건	주의할 조건	검증 질문
직접 연결	Databasement와 DB가 같은 내부망에 있다	방화벽 개방 범위가 넓어진다	DB port 접근 source를 최소화했는가
SSH 터널	bastion으로 DB 접근을 통제한다	키 관리와 jump server 권한이 집중된다	key rotation과 접속 로그가 남는가
원격 에이전트	인바운드 포트를 열 수 없는 격리망이다	agent update와 outbound 대상 통제가 필요하다	HTTPS 목적지와 저장소 권한이 allowlist인가
SFTP 파일 백업	SQLite 같은 파일 기반 DB를 원격에서 가져온다	경로 오입력과 파일 lock 상태를 봐야 한다	절대 경로와 lock 처리 기준을 테스트했는가

이 조건이면 원격 에이전트를 검토한다.

DB가 지점망이나 격리망에 있고, 중앙 서버에서 직접 접속하는 것보다 아웃바운드 HTTPS가 보안 정책상 안전한 경우다.

이 경우는 보류한다.

agent가 어떤 권한으로 실행되는지, 어떤 저장소로 업로드하는지, 실패 로그가 어디에 남는지 설명할 수 없는 경우다.

운영 비용 모델은 라이선스가 아니라 사람과 복구 시간에서 나온다

Databasement 자체는 MIT 라이선스 공개 저장소로 제공된다.

그렇다고 운영 비용이 없다고 쓰면 틀린 판단이다.

오픈소스 도구는 벤더 라이선스보다 인프라, 저장소, 업그레이드, 취약점 대응, 테스트 환경, 장애 대응 시간을 직접 부담한다.

비용/예산 항목	공식 근거로 확인한 숫자 또는 조건	직접 산정할 값	놓치면 생기는 문제
소프트웨어	MIT license, 공개 가격표 없음	상용 지원이 필요하면 별도 계약 여부 확인	무료 도구로 보고 운영 책임을 과소평가
컨테이너 운영	포트 2226, app/worker 분리 가능	Docker host, 모니터링, 백업 콘솔 자체 백업	백업 도구 장애를 아무도 모름
작업 처리	tries 3회, timeout 3600초, max jobs 1000개 예시	DB 크기별 작업 시간과 worker 수	대형 DB에서 queue가 밀림
저장 효율	zstd 20–40% 향상, AES-256 암호화 언급	CPU 사용량과 복구 시간 비교	압축률만 보고 복구 시간이 늘어남
복구 훈련	scheduled restore 기능 제공	월 1회 이상 staging 복구 리허설 시간	사고 때 백업 파일만 있고 절차가 없음

실무 시나리오 둘째는 제조사 내부 시스템이다.

현장 서버에 MySQL과 SQLite 파일이 있고, 중앙 IT팀은 VPN이 열리는 시간에만 접근한다.

이 조직은 라이선스 비용보다 네트워크 승인, 현장 agent 권한, SFTP 경로, 복구 테스트 창구가 병목이다.

Databasement를 쓰더라도 첫 분기 목표는 모든 DB 자동 백업이 아니라 “가장 중요한 2개 DB의 격리 복구와 실패 알림”이어야 한다.

배포 스켈레톤: 운영 전 체크 YAML

아래 YAML은 설치 명령 복사본이 아니라 운영 도입 전에 owner, queue, 저장소, 복구 테스트를 고정하는 템플릿이다.

# databasement-backup-rollout.yaml
# 목적: Databasement를 단일 컨테이너 실험에서 운영 백업 관리자로 올리기 전 확인한다.
# 실제 설정값은 공식 문서, 사내 보안 기준, 백업 대상 DB 버전, 저장소 정책에 맞게 바꾼다.

service:
  name: databasement
  app_url: https://backup-console.example.internal
  exposed_port: 2226
  deployment_mode: docker_compose
  app_database:
    engine: postgresql
    backup_policy: daily_local_dump_plus_object_storage

jobs:
  worker:
    queue: backups,default
    tries: 3
    timeout_seconds: 3600
    max_jobs_before_restart: 1000
  schedules:
    production_postgres:
      frequency: daily
      retention_policy: gfs
      restore_test_target: staging-postgres
    analytics_mysql:
      frequency: weekly
      retention_policy: days
      restore_test_target: isolated-qa

security:
  admin_mfa_required: true
  sso_provider: oidc
  api_tokens:
    owner: platform-backup-bot
    rotation_days: 90
  storage:
    primary: s3_compatible
    encryption_required: true
    public_bucket_allowed: false
  database_credentials:
    least_privilege_review: required
    production_superuser_allowed: exception_only

acceptance_tests:
  - backup_job_succeeds
  - latest_snapshot_restore_succeeds
  - alert_sent_on_failed_job
  - restore_target_not_production
  - audit_log_exported

파일럿 단계에서는 항목을 줄여도 된다.

다만 restore target, alert channel, storage encryption, API token rotation은 처음부터 빼지 않는 편이 낫다.

Docker Compose 시작점과 검증 순서

아래 compose 조각은 공식 문서의 app과 worker 분리 구조를 운영 검토용으로 줄인 예시다.

services:
  app:
    image: davidcrty/databasement:1
    container_name: databasement
    restart: unless-stopped
    ports:
      - "2226:2226"
    env_file: .env
    volumes:
      - ./data:/data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:2226/health"]
      interval: 10s
      timeout: 5s
      retries: 5
  worker:
    image: davidcrty/databasement:1
    restart: unless-stopped
    command: sh -c "php artisan db:wait --check-migrations && php artisan queue:work --queue=backups,default --tries=3 --timeout=3600 --sleep=3 --max-jobs=1000"
    env_file: .env
    volumes:
      - ./data:/data

실행보다 검증 순서가 중요하다.

APP_KEY를 생성하고 .env 파일 권한을 600 수준으로 제한한다.
DB_CONNECTION과 DB_DATABASE 또는 외부 DB_HOST 값을 공식 문서 기준으로 작성한다.
docker compose up -d 후 docker compose ps로 app과 worker health를 확인한다.
curl http://localhost:2226/health로 health endpoint 응답을 확인한다.
관리자 계정을 만들고 MFA, SSO 또는 OIDC 적용 여부를 결정한다.
테스트 DB 1개만 등록해 백업과 staging restore를 먼저 통과시킨다.
실패 알림을 일부러 발생시켜 지정 채널로 들어오는지 확인한다.

이 순서에서 운영 DB를 바로 넣지 않는다.

첫날에는 test database, 작은 dataset, 격리된 저장소로 백업과 복구 흐름만 닫는다.

복구 게이트 스크립트 예시

아래 Python 예시는 Databasement API를 바로 호출하는 코드가 아니라 운영 게이트 기준을 설명하는 검사용 스켈레톤이다.

#!/usr/bin/env python3
# databasement_restore_gate.py
# 목적: Databasement 백업이 "성공"이라고 표시되어도 복구 검증이 없으면 운영 통과로 보지 않는다.
# 실제 API 엔드포인트와 응답 구조는 각 설치 환경의 /docs/api에서 확인한 뒤 연결한다.

from dataclasses import dataclass

@dataclass
class BackupJob:
    name: str
    snapshot_age_hours: int
    restore_test_passed: bool
    storage_encrypted: bool
    alert_channel_checked: bool

jobs = [
    BackupJob("prod-postgres", 18, True, True, True),
    BackupJob("analytics-mysql", 190, False, True, True),
]

for job in jobs:
    problems = []
    if job.snapshot_age_hours > 48:
        problems.append("최근 48시간 안의 스냅샷 없음")
    if not job.restore_test_passed:
        problems.append("복구 테스트 미통과")
    if not job.storage_encrypted:
        problems.append("저장소 암호화 확인 필요")
    if not job.alert_channel_checked:
        problems.append("실패 알림 채널 미검증")
    print(job.name, "PASS" if not problems else "BLOCK", problems)

실제 자동화는 각 설치 환경의 /docs/api에서 엔드포인트와 응답 구조를 확인한 뒤 연결해야 한다.

API 토큰은 Settings에서 만들고 Bearer token으로 보내는 방식이므로, 토큰 저장소와 rotation 정책을 먼저 정한다.

상용 백업 솔루션과 Databasement 비교 기준

Databasement는 모든 상용 백업 솔루션의 대체재가 아니다.

특히 엔터프라이즈 백업 제품의 immutability, 장기 보관, 규제 리포트, 벤더 지원, 복잡한 복구 오케스트레이션은 별도 비교가 필요하다.

다만 작은 팀이 cron 스크립트와 개인 운영 문서에서 벗어나는 첫 단계로는 현실적인 후보가 된다.

비교 항목	Databasement	상용 백업 솔루션	선택 기준
초기 도입	Docker 기반으로 빠르게 확인 가능	벤더 데모, PoC, 계약 절차 필요	작은 범위 파일럿은 Databasement가 빠르다
지원 범위	DB 중심 백업과 복구	파일, VM, SaaS, endpoint까지 넓을 수 있음	전사 백업이면 상용 제품 검토
운영 책임	셀프호스팅 팀이 패치와 장애 대응 책임	벤더 지원과 SLA를 계약으로 확보 가능	내부 운영 역량이 약하면 주의
보안 통제	직접 네트워크와 저장소를 설계	제품별 보안 기능과 감사 리포트 제공	감사 요구 수준에 맞춰 선택
비용 구조	라이선스보다 인프라·저장소·사람 비용 중심	라이선스·지원·사용량 비용이 견적서에 표시	총소유비용으로 비교