[Linux] mariadb-backup 활용 가이드

 

안녕하세요. 주식회사 서버몬 입니다.

 

기존 MariaDB 환경에서는 Percona의 XtraBackup을 활용해 물리적 온라인 백업을 수행하는 경우가 많았습니다.
그러나 MariaDB 10.x부터는 XtraBackup 기반 기능이 공식 도구인 mariadb-backup으로 통합되어 제공됩니다.

이에 따라 현재 MariaDB 10.11 이상 버전에서는 별도 외부 도구가 아닌, MariaDB 공식 패키지로 제공되는 mariadb-backup을 사용하는 것이 권장됩니다.

본 문서에서는 mariadb-backup의 개념, 지원 기능, 백업 유형, 사전 준비사항 및 실무 적용 관점에서의 특징을 정리합니다.

 

mariadb-backup 이란?

mariadb-backup은 MariaDB에서 공식 제공하는 오픈소스 물리적(Physical) 온라인 백업 도구입니다.

논리적 백업 도구인 mysqldump와 달리, 데이터 파일(.ibd, ibdata, redo log 등)을 직접 복사하는 방식으로 동작합니다.

주요 특징
- Hot Backup 지원 (서비스 중단 없이 수행 가능)
- InnoDB 기반 트랜잭션 일관성 보장
- 대용량 데이터 환경에서 빠른 처리 속도
- 복구 시 파일 단위 restore 방식으로 빠른 복원 가능

mariadb-backup은 XtraBackup의 기능을 기반으로 발전된 도구입니다.
기존 XtraBackup 사용 경험이 있다면 거의 동일한 방식으로 운영이 가능합니다.

추가적으로 다음 기능들이 공식적으로 지원됩니다.
- 데이터 암호화(Encryption) 환경 백업 및 복원
- InnoDB 페이지 압축(Page Compression) 백업 지원
- Galera Cluster 환경에서 SST(State Snapshot Transfer) 방식 지원
- Windows 플랫폼 지원
- MyRocks 스토리지 엔진 백업 지원

 

더욱 자세한 내용은 공식에서 제공되는 게시글을 참조해주세요

https://mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup

 

mysqldump VS mariadb-backup

mariadb-backup은 물리적 백업, mysqldump는 논리적 백업입니다.

구분	mysqldump	mariadb-backup
백업 방식	논리적 백업(SQL 생성)	물리적 백업(데이터 파일 복사)
백업 결과물	SQL 파일 생성	데이터 및 로그파일
복구 방식	SQL 파일 재실행	파일 복원
속도	대용량 복원시 느림	용량 상관없이 빠른 속도
적합 환경	소규모 DB	대용량 DB

대규모 서비스 환경, 특히 수십 GB 이상 데이터베이스에서는 물리적 백업 방식이 훨씬 효율적입니다.

 

mariadb-backup 사전 준비사항

mariadb-backup을 사용하기 위해서는 다음 조건이 충족되어야 합니다.

패키지 설치

[ yum/dnf 설치 ]
yum install MariaDB-backup

[ apt-get 설치 ]
apt-get install mariadb-backup

백업 전용 계정 생성 및 권한 부여
물리적 백업 수행을 위해서는 최소 다음 권한이 필요합니다.

MariaDB [mysql]> CREATE USER 'mariadb-backup'@'localhost' IDENTIFIED BY '비밀번호';
D, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'mariadb-backup'@'localhost';Query OK, 0 rows affected (0.002 sec)

MariaDB [mysql]> GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'mariadb-backup'@'localhost';
Query OK, 0 rows affected (0.001 sec)

 

전체백업

[ 백업 생성 ]
[root@test ~]# mariadb-backup --backup --target-dir=/mnt/d/xtraback/full/ --user=mariadb-backup --password=
[00] 2026-02-05 12:49:35 Backup created in directory '/root/xtraback/full/'
[00] 2026-02-05 12:49:35 Writing backup-my.cnf
[00] 2026-02-05 12:49:35         ...done
[00] 2026-02-05 12:49:35 Writing xtrabackup_info
[00] 2026-02-05 12:49:35         ...done
[00] 2026-02-05 12:49:35 Redo log (from LSN 114229949760 to 114249901932) was copied.
[00] 2026-02-05 12:49:35 completed OK!

[root@test full]# pwd
/root/xtraback/full
[root@test full]# ll
total 95744
-rw-r----- 1 root root   417792 Feb  5 12:49 aria_log.00000001
-rw-r----- 1 root root       52 Feb  5 12:45 aria_log_control
-rw-r----- 1 root root      285 Feb  5 12:49 backup-my.cnf
-rw-r----- 1 root root 77594624 Feb  5 12:49 ibdata1
-rw-r----- 1 root root 19964460 Feb  5 12:45 ib_logfile0
drwx------ 2 root root     4096 Feb  5 12:49 mysql
drwx------ 2 root root     4096 Feb  5 12:49 performance_schema
drwx------ 2 root root    12288 Feb  5 12:49 sys
drwx------ 2 root root     4096 Feb  5 12:49 test
-rw-r----- 1 root root      111 Feb  5 12:49 xtrabackup_checkpoints
-rw-r----- 1 root root      478 Feb  5 12:49 xtrabackup_info
drwx------ 2 root root    20480 Feb  5 12:49 zabbix

[ 백업 준비 ]
[root@test full]# systemctl stop mysql
[root@test mysql]# mv /var/lib/mysql/ /mnt/d/dbbackup/
[root@test mysql]# mariadb-backup --prepare --target-dir=/mnt/d/xtraback/full/
[00] 2026-02-05 13:06:49 Last binlog file , position 0
[00] 2026-02-05 13:06:49 completed OK!

[ 백업 복원 ]
[root@test mysql]# mariadb-backup --copy-back --target-dir=/mnt/d/xtraback/full/
mariadb-backup based on MariaDB server 10.11.15-MariaDB Linux (x86_64)
[00] 2026-02-05 13:07:27 Original data directory /var/lib/mysql is not empty!

[ 디렉토리 권한 조정 ]
[root@test mysql]# chown -R mysql:mysql /var/lib/mysql/

[ DB 검증 ]
[root@test full]# mysqlcheck -uroot -p zabbix
zabbix.acknowledges                                OK
zabbix.actions                                     OK
zabbix.alerts                                      OK
zabbix.auditlog                                    OK

 

[ 백업 생성 ]
데이터 파일을 물리적으로 백업한다. 이 단계에서는 InnoDB 파일과 메타데이터가 그대로 복사된다.

[ 백업 준비 ]
redo 로그를 적용하고 트랜잭션을 정리하여 데이터 파일을 일관성 있는 상태로 만든다.
이 단계가 완료되면 실질적인 복구는 끝난 상태다.

[ 백업 복원 ]
prepare가 완료된 데이터 파일을 MariaDB 데이터 디렉터리(/var/lib/mysql)로 복사한다.

[ DB 검증 ]
복구된 데이터베이스의 테이블 무결성을 확인한다.

## 권한 관련 주의 사항 ##
mariadb-backup은 백업 시점의 파일 및 디렉터리 권한을 유지합니다.
하지만 실제 디스크에 파일을 기록하는 시점에는 복원을 수행한 사용자 및 그룹의 권한으로 저장됩니다.

따라서 copy-back 이후에는 반드시 데이터 디렉터리의 소유자를 MariaDB 서버 계정과 일치하도록 변경해야 합니다.

 

증분백업

[ 전체 백업 ] 
[root@test backtest]# mariadb-backup --backup --target-dir=/mnt/d/xtraback/test2/ --user=mariadb-backup --password=
[root@test backtest]# ls -al test2
total 101344
drwxr-xr-x 8 root root     4096 Feb  4 13:50 .
drwxr-xr-x 3 root root     4096 Feb  4 13:41 ..
-rw-r----- 1 root root   417792 Feb  4 13:50 aria_log.00000001
-rw-r----- 1 root root       52 Feb  4 13:50 aria_log_control
-rw-r----- 1 root root      285 Feb  4 13:50 backup-my.cnf
drwx------ 2 root root    20480 Feb  4 13:50 estsoft
drwx------ 2 root root   270336 Feb  4 13:50 estsoft_log
-rw-r----- 1 root root 79691776 Feb  4 13:50 ibdata1
-rw-r----- 1 root root 23319650 Feb  4 13:50 ib_logfile0
drwx------ 2 root root     4096 Feb  4 13:50 mysql
drwx------ 2 root root     4096 Feb  4 13:50 performance_schema
drwx------ 2 root root    12288 Feb  4 13:50 sys
drwx------ 2 root root     4096 Feb  4 13:50 test
-rw-r----- 1 root root      109 Feb  4 13:50 xtrabackup_checkpoints
-rw-r----- 1 root root      478 Feb  4 13:50 xtrabackup_info
[root@test test2]# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 26389632470
last_lsn = 26412939832
recover_binlog_info = 0

[ 증분 백업 ]
[root@test backtest]# mariadb-backup --backup --target-dir=/mnt/d/xtraback/test2-1 --incremental-basedir=/mnt/d/xtraback/test2/ --user=mariadb-backup --password=

[ 전체 백업 + 증분 백업 결합 ]
[root@test backtest]# systemctl stop mysql
cd /var/lib
cp -a mysql mysql_bak
rm -rf* /var/lib/mysql/
[root@test backtest]# mariadb-backup --prepare --target-dir=/mnt/d/xtraback/test2
[root@test backtest]# mariadb-backup --prepare --target-dir=/mnt/d/xtraback/test2 --incremental-dir=/mnt/d/xtraback/test2-1

[ 백업 복원 ]
[root@test mysql]# mariadb-backup --copy-back --target-dir=/mnt/d/xtraback/test2
[root@test mysql]# ll
total 78668
-rw-r----- 1 root root   417792 Feb  4 14:54 aria_log.00000001
-rw-r----- 1 root root       52 Feb  4 14:54 aria_log_control
drwx------ 2 root root    20480 Feb  4 14:55 estsoft
drwx------ 2 root root   368640 Feb  4 14:55 estsoft_log
-rw-r----- 1 root root 79691776 Feb  4 14:54 ibdata1
-rw-r----- 1 root root    12304 Feb  4 14:54 ib_logfile0
drwx------ 2 root root     4096 Feb  4 14:56 mysql
drwx------ 2 root root     4096 Feb  4 14:55 performance_schema
drwx------ 2 root root    12288 Feb  4 14:56 sys
drwx------ 2 root root     4096 Feb  4 14:56 test
-rw-r----- 1 root root        3 Feb  4 14:54 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root      533 Feb  4 14:56 xtrabackup_info

[ 디렉토리 권한 조정 ]
[root@test mysql]# chown -R mysql:mysql /var/lib/mysql/

[ DB 검증 ]
[root@test full]# mysqlcheck -uroot -p zabbix
zabbix.acknowledges                                OK
zabbix.actions                                     OK
zabbix.alerts                                      OK
zabbix.auditlog                                    OK
zabbix.autoreg_host                                OK

 

[ 전체 백업 ]
백업 기준 시점 확보한다.

[ 증분 백업 ]
기준 시점 이후 변경분만 저장한다.

[ 전체 + 증분 결합(prepare) ]
Full + Incremental 병합해 최종 백업본을 생성한다.

[ 백업 복원 ]
prepare가 완료된 데이터 파일을 MariaDB 데이터 디렉터리(/var/lib/mydsql)로 복사한다.

[ DB 검증 ]
복구된 데이터베이스의 테이블 무결성을 확인한다.

핵심은 prepare 단계에서 증분 병합과 crash recovery가 완료된다는 점입니다.
물리적 백업은 단순한 파일 복사처럼 보이지만, 실제로는 InnoDB 내부 복구 과정을 오프라인에서 미리 수행하는 구조입니다.

따라서 Full + Incremental 방식에서도 최종 데이터는 일관성이 보장된 상태로 복원됩니다.

 

체인파일 필요여부  

mariadb-backup으로 전체 백업과 증분 백업을 수행하면, 데이터 파일 외에도 여러 메타데이터 파일이 함께 생성됩니다.

대표적으로 다음과 같은 파일이 포함됩니다.
- xtrabackup_checkpoints
- xtrabackup_info
- xtrabackup_logfile

이 파일들은 백업 시점의 LSN(Log Sequence Number), 백업 유형(full/incremental), 서버 정보 등 복구에 필요한 메타데이터를 담고 있습니다. 특히 증분 백업에서는 “어디부터 어디까지의 변경분인지”를 판단하는 기준이 됩니다.

이번 테스트의 목적은 다음과 같습니다.
prepare 완료 이후에도 체인 메타 파일이 반드시 필요한지 여부를 검증하는 것

 

[시나리오 1]
prepare 이후 메타 파일 삭제

[root@test xtraback]#  mariadb-backup --backup --target-dir=/mnt/d/xtraback/test2/ --user=mariadb-backup --password=
[00] 14:58:03 Writing xtrabackup_info
[00] 14:58:03         ...done
[00] 14:58:03 Redo log (from LSN 80363557689 to 80363557705) was copied.
[00] 14:58:03 completed OK!

[root@test xtraback]# mariadb-backup --backup --target-dir=/mnt/d/xtraback/test2-1 --incremental-basedir=/mnt/d/xtraback/test2/ --user=mariadb-backup --password=
[00] 14:58:50 Writing xtrabackup_info
[00] 14:58:50         ...done
[00] 14:58:50 Redo log (from LSN 80363557689 to 80363557705) was copied.
[00] 14:58:50 completed OK!

[root@test xtraback]# systemctl stop mysql
[root@test xtraback]# mariadb-backup --prepare --target-dir=/mnt/d/xtraback/test2
[00] 14:59:36 Last binlog file , position 0
[00] 14:59:36 completed OK!

[root@test xtraback]# mariadb-backup --prepare --target-dir=/mnt/d/xtraback/test2 --incremental-dir=/mnt/d/xtraback/test2-1
[00] 14:59:47         ...done
[00] 14:59:47 completed OK!

test2 /test2-1 안에 모든 체인파일 back / back2-1에 넣어 위치 이동
[root@test xtraback]# ll
total 0
drwxrwxrwx 1 user user 4096 Feb 20 15:02 back
drwxrwxrwx 1 user user 4096 Feb 20 15:02 back2-1
drwxrwxrwx 1 user user 4096 Feb 20 15:03 test2
drwxrwxrwx 1 user user 4096 Feb 20 15:03 test2-1

[root@test xtraback]# mariadb-backup --copy-back --target-dir=/mnt/d/xtraback/test2
mariadb-backup based on MariaDB server 10.11.15-MariaDB Linux (x86_64)
[00] 2026-02-20 15:03:56 Original data directory /var/lib/mysql is not empty!

[root@test lib]# chown -R mysql:mysql /var/lib/mysql/
[root@test lib]# systemctl start mariadb

[root@test lib]# mysqlcheck -uroot -p zabbix
zabbix.acknowledges                                OK
zabbix.actions                                     OK
zabbix.alerts                                      OK
zabbix.auditlog                                    OK

prepare 단계에서는 다음 작업이 수행됩니다.
- redo 로그 적용
- 증분 백업 병합
- InnoDB 데이터 파일 정합성 복구
- crash recovery 완료 상태로 데이터 파일 정리

즉, prepare가 완료되면 데이터 파일 자체가 이미 일관성 있는 상태로 완성됩니다.
이후 copy-back은 단순히 해당 파일을 데이터 디렉터리로 복사하는 과정일 뿐입니다.

따라서 prepare 완료 이후에는 체인 메타 파일이 없어도 서버 기동 및 데이터 무결성에는 직접적인 영향이 없음을 확인했습니다.

 

[시나리오 2]

prepare 전 메타 파일 삭제

[root@test xtraback]#  mariadb-backup --backup --target-dir=/mnt/d/xtraback/test2/ --user=mariadb-backup --password=
[00] 14:58:03 Writing xtrabackup_info
[00] 14:58:03         ...done
[00] 14:58:03 Redo log (from LSN 80363557689 to 80363557705) was copied.
[00] 14:58:03 completed OK!

[root@test xtraback]# mariadb-backup --backup --target-dir=/mnt/d/xtraback/test2-1 --incremental-basedir=/mnt/d/xtraback/test2/ --user=mariadb-backup --password=
[00] 14:58:50 Writing xtrabackup_info
[00] 14:58:50         ...done
[00] 14:58:50 Redo log (from LSN 80363557689 to 80363557705) was copied.
[00] 14:58:50 completed OK!

[root@DESKTOP-36OPSVG xtraback]# ll
total 0
drwxrwxrwx 1 user user 4096 Feb 20 15:12 back
drwxrwxrwx 1 user user 4096 Feb 20 15:13 back2
drwxrwxrwx 1 user user 4096 Feb 20 15:12 test2
drwxrwxrwx 1 user user 4096 Feb 20 15:13 test2-1

[root@DESKTOP-36OPSVG xtraback]# systemctl stop mysql
[root@DESKTOP-36OPSVG xtraback]# mariadb-backup --prepare --target-dir=/mnt/d/xtraback/test2
[00] 2026-02-20 15:14:01 cd to /mnt/d/xtraback/test2/
[00] 2026-02-20 15:14:01 open files limit requested 0, set to 10240
[00] 2026-02-20 15:14:02 Error: cannot open ./xtrabackup_checkpoints
[00] 2026-02-20 15:14:02 Error: failed to read metadata from './xtrabackup_checkpoints'

xtrabackup_checkpoints 파일을 열 수 없다는 오류와 함께 prepare 단계에서 실패하였습니다.

prepare는 LSN 정보를 기반으로 증분 병합을 수행합니다.
체인 메타 파일이 없으면 병합 기준을 확인할 수 없으므로 정상적인 prepare가 불가능합니다.

이는 설계상 당연한 동작입니다.

체인 메타 파일은 prepare 이전 단계에서 반드시 필요합니다.
prepare 완료 이후에는 운영 DB 기동 및 데이터 무결성에는 직접적인 영향이 없습니다.

다만 제약은 존재합니다.
- 추가 증분 백업을 이어서 적용할 수 없음
- 백업 체인 추적 및 감사 목적 정보 상실
- 장애 분석 시 기준 시점 확인이 어려움

정리하면, prepare 완료 이후 운영 DB의 정상 동작에는 영향이 없었습니다.
하지만 백업 관리 및 이력 추적 관점에서는 메타 파일을 함께 보관하는 것을 권장합니다.

마무리하며 

mariadb-backup은 SQL 덤프 방식이 아닌 물리적 백업 방식입니다.
CREATE나 INSERT 구문을 재실행하는 구조가 아니라, 데이터 파일 자체를 그대로 백업하고 복원합니다.

이 때문에 다음과 같은 장점이 있습니다.

• 대용량 환경에서 백업·복구 속도가 빠름
• 트랜잭션 일관성 유지 가능
• 복구 시 SQL 재실행 과정이 없음

운영 환경에서 백업은 되는데 복구 시간이 오래 걸리는 상황을 한 번이라도 겪어봤다면, 물리적 백업 방식은 충분히 고려해볼 만한 선택지입니다.

 

 

 

 

 

1U서버 / 2U서버 / AI서버 / alyac / APC / APC UPS / backup / carepack / centos / chakramax / cuda / DAS / DB / DB서버 / defog / DEFOG랙 / dell5820 / dell5820t / dell7920 / dellpoweredge / dellr240 / dellr340 / dellr350 / dellr450 / dellr540 / dellr630 / dellr640 / dellr740 / dellr750 / dellserver / dellt40 / dellt440 / dellt5820 / dell서버 / DELL서버CPU / DELL서버RAID컨트롤러 / DELL서버SAS하드디스크 / DELL서버가격비교 / DELL서버가격비교견적 / DELL서버견적 / DELL서버구매 / DELL서버디스크교체 / DELL서버메모리 / dell서버서버몬 / DELL서버펌웨어 / DELL서버하드디스크구매 / dell옵션 / dell워크스테이션 / dl20 / dl20gen10 / dl20gen11 / dl360 / dl360gen10 / dl360gen11 / dl380 / dl380g10 / dl380gen10 / dl380gen11 / ECC메모리 / EDFOG랙가격 / embedded / est security / ESTSOFT / FIRMWARE / GPU / gpu서버 / gpu타워형서버 / greenlake / HA솔루션 / HP GPU / hp hdd / hpdl20 / HPDL20Gen10 / hpdl360 / hpdl360gen10 / hpdl380 / hpdl380g10 / HPDL380Gen10 / HPE / HPE GPU / hpe hdd / hpe rok / HPE Service Pack for Proliant / HPE SPP / hpe ssa / hpedl20 / hpedl20gen10 / hpedl360gen10 / hpe서버 / HPE서버CPU / HPE서버RAID컨트롤러 / HPE서버SAS하드디스크 / HPE서버가격비교 / HPE서버가격비교견적 / HPE서버견적 / HPE서버구매 / HPE서버드라이버설치 / HPE서버디스크교체 / HPE서버메모리 / HPE서버비용 / hpe서버소음 / HPE서버펌웨어 / HPE서버하드디스크구매 / hpe옵션 / hpe정품 / hpgen10 / hpml30 / hpserver / hpz2 / hpz4 / hpz4g4 / hpz6g4 / hpz8g4 / hp마이크로서버 / hp서버 / hp서버cto / hp서버pc / HP서버메모리 / hp서버소음 / hp서버컴퓨터 / HP서버파워 / HP서버펌웨어 / HP서버하드디스크 / hp옵션 / hp워크스테이션 / hp정품 / hp프로라이언트 / HYPER BACKUP / ibm서버 / ilo / Intelligent Provisioning / internetdisk / KVM / KVM 기술지원비(비용) / KVM 설치비 / L2스위치 / L3스위치 / LENONO서버SAS하드디스크 / lenovop620 / lenovor650 / LENOVO서버 / LENOVO서버CPU / LENOVO서버RAID컨트롤러 / LENOVO서버가격비교 / LENOVO서버가격비교견적 / LENOVO서버견적 / LENOVO서버구매 / LENOVO서버디스크교체 / LENOVO서버메모리 / LENOVO서버하드디스크구매 / LENOVO펌웨어업데이트 / Linux / ML30 / ml30gen10 / ml30gen11 / ML350GEN10 / ml350gen11 / ML360 / MS CSP / MSSQL / MSSQL 기술지원비(비용) / MSSQL 설치비 / MYSQL / MySQL 기술지원비(비용) / MySQL 설치비 / NAS / NVIDIA / Office 365 / oneview / orange / OS설치 / PA-410 / PA-440 / paloalto / poweredger740 / poweredger750 / precision5820 / QUADRO / r240 / r250 / r340 / r360 / r440 / r550 / r650 / r660 / r740 / r750xs / r760 / r760xs / RAID / redhat / RHEL설치 / RMS랙 / rocky / s100i / securedisk / server / serverpc / smart storage administrator / SPP / sql server / sr250 / sr650 / SYNOLOGY / SYNOLOGY나스 / t150 / t360 / UPS / UPS기술지원 / UPS납품 / UPS설치 / V3 / veeam / vroc / windows server / Windows서버설치 / XEON서버 / z8g4 / 가상서버 / 가성비서버 / 기술지원비(비용) / 나스기술지원 / 나스설치지원 / 네트워크스위치 / 네트워크장비 / 더블테이크 / 데이터베이스 / 델5820 / 델서버 / 델서버비용 / 델서버펌웨어업데이트 / 델옵션 / 델워크스테이션 / 델컴퓨터워크스테이션 / 디포그 / 디포그랙 / 디포그랙가격 / 딥러닝 / 딥러닝pc / 딥러닝서버 / 랙 / 랙(RACK) 기술지원비(비용) / 랙(RACK) 설치비 / 랙납품설치 / 랙설치 / 레노버p620 / 레노버서버 / 레노버워크스테이션 / 레노보서버 / 레노보서버펌웨어 / 레드헷설치 / 레이드 / 레이드구성 / 록키리눅스 / 리눅스 / 리눅스 기술지원비(비용) / 리눅스 설치비 / 리눅스서버 / 리눅스서버설치 / 리눅스서버트러블슈팅 / 리눅스트러블슈팅 / 문서보안 / 문서중앙화 / 미니서버 / 미니서버랙 / 미니서버렉 / 미디어서버 / 방화벽 / 방화벽 기술지원비(비용) / 방화벽 설치비 / 방화벽엔지니어 / 백업 / 백업 기술지원비(비용) / 백업 서버 / 백업서비스 / 백업솔루션 / 보안솔루션 / 보안솔루션구매 / 보안솔루션설치 / 보안툴 / 빔백업 / 샤크라맥스 / 서버 / 서버 기술지원비(비용) / 서 버 랙마운트비용 / 서버 설치비 / 서버 장애조치비용 / 서버CPU / 서버MEMORY / 서버OS설치 / 서버pc / 서버가격 / 서버가속기 / 서버견적 / 서버교체 / 서버구매 / 서버구입 / 서버구축 / 서버기술지원 / 서버납품 / 서버디스크장애처리 / 서버랙 / 서버렉 / 서버렉마운트 / 서버메모리 / 서버 몬 / 서버몬기술지원 / 서버백업 / 서버보안 / 서버부품 / 서버엔지니어 / 서버옵션 / 서버용GPU / 서버용PC / 서버용그래픽카드 / 서버용메모리 / 서버 / 컴퓨터 / 서버용하드디스크 / 서버재고 / 서버컴 / 서버컴퓨터 / 서버트러블슈팅 / 서버판매 / 서버하드 / 서버호스팅 / 스위치 / 스위치 기술지원비(비용) / 스위치 설치비 / 스토리지 / 스토리지 기술지원비(비용) / 스토리지 랙마운트비용 / 스토리지 설치비 / 스토리지 장애조치비용 / 스토리지납품설치 / 스토리지서버 / 시놀로지DS918 / 시놀로지HyperBackup / 시놀로지나스 / 시놀로지나스백업 / 시놀로지하이퍼백업 / 시큐어디스크 / 안랩 / 알약 / 앱서버 / 오피스 365 / 우분투설치 / 워크스테이션 / 워크스테이션pc / 워크스테이션컴퓨터 / 윈도우서버 / 윈도우서버2016 / 윈도우서버2019 / 윈도우서버2022 / 윈도우서버설치 / 윈도우서버컴퓨터 / 윈도우서버트러블슈팅 / 윈도우즈 기술지원비(비용) / 윈도우즈 설치비 / 이스트소프트 / 이스트 시큐리티 / 이중화솔루션 / 이중화솔루션구매 / 이중화솔루션설치 / 인터넷디스크 / 임베디드 / 저가서버 / 저렴한서버 / 정품서버 / 정품서버옵션 / 제온서버 / 젠서버 / 중고서버 / 중고워크스테이션 / 카보나이트 / 카스퍼스키 / 컴퓨터서버 / 케어팩 / 타워서버 / 타워형서버 / 팔로알토 / 페도라설치 / 프로라이언트