MariaDB / 데이터 저장 위치 변경하는 방법
MariaDB의 데이터 저장 위치는 서버를 정상 종료한 뒤 데이터 디렉터리 전체를 새 위치로 복사하고, 서버 설정의 datadir와 접근 권한을 바꾸어 변경합니다. 설정값만 바꾸거나 실행 중인 파일을 일반 복사하면 기존 데이터가 보이지 않거나 일관성이 깨질 수 있으므로, 독립된 백업과 작업 중 쓰기 중단이 먼저 필요합니다.
변경 전에 확인할 범위와 준비 사항
데이터 디렉터리는 MariaDB가 데이터베이스와 엔진 관리 파일을 보관하는 폴더이며, 현재 위치는 datadir 서버 변수로 확인합니다. 이 글은 같은 컴퓨터와 같은 MariaDB 버전에서 단일 인스턴스의 경로만 바꾸는 작업을 다룹니다. 버전 업그레이드, 다른 운영체제로의 이전, 복제·Galera 클러스터, 컨테이너 볼륨 변경은 별도 계획이 필요합니다.
관리 권한이 있는 계정으로 MariaDB 클라이언트에 접속하여 다음 SQL을 실행하고 결과를 저장합니다. Ubuntu에서는 일반적인 소켓 인증 설치라면 sudo mariadb로 접속할 수 있으며, Windows에서는 설치 폴더의 bin\mariadb.exe -u root -p를 사용합니다. 인증 방식이 다르면 해당 서버의 관리 계정으로 접속합니다.
SELECT VERSION(), @@datadir, @@port;
SHOW VARIABLES WHERE Variable_name IN (
'log_error', 'log_bin_basename', 'innodb_data_home_dir',
'innodb_log_group_home_dir', 'aria_log_dir_path'
);- 독립된 백업: 복구 가능한 백업을 다른 위치에 확보합니다. 원본 디렉터리를 남기는 것만으로 별도 백업을 대신하지 않으며, 운영 데이터는 복원 가능성도 확인합니다. MariaDB 백업 개요에서 논리 백업과 물리 백업의 적용 범위를 확인할 수 있습니다.
- 경로와 용량: SQL로 확인한 원본 경로와 충분한 여유 공간이 있는 새 경로를 기록합니다. 아래 Ubuntu 예제의
/var/lib/mysql/와 Windows 예제의MariaDB 11.4는 예시이므로 실제 설치에 맞게 바꿉니다. - 외부 파일: 절대 경로로 지정한 바이너리 로그, 외부 테이블스페이스, 암호화 키, 심볼릭 링크나 Windows 재분석 지점은
datadir변경만으로 모두 이전되지 않습니다. 해당 구성이 있으면 각각의 경로와 권한을 따로 계획합니다. - 중단 시간: 애플리케이션, 배치와 모니터링의 자동 쓰기·자동 재시작을 멈춥니다. 작업과 검증이 끝나기 전에는 외부 쓰기를 다시 허용하지 않습니다.
기존 서버의 디렉터리를 옮길 때 새 위치에 mariadb-install-db를 실행하지 않습니다. 초기화 도구는 새 인스턴스를 만드는 용도이며, 기존 데이터 전체를 복사하는 작업과 다릅니다.
Ubuntu에서 데이터 디렉터리 옮기기
실제 설정 파일과 마운트 확인
Ubuntu 24.04의 일반적인 패키지 설치에서는 서버 설정이 /etc/mysql/mariadb.conf.d/50-server.cnf에 있지만 설치 방식에 따라 다를 수 있습니다. systemctl cat으로 서비스의 실행 옵션과 추가 설정을 보고, mariadbd --print-defaults 결과에서 기존 datadir와 중복 설정을 확인합니다. 출력에 민감한 옵션이 있을 수 있으므로 그대로 공개하지 않습니다.
sudo systemctl cat mariadb
sudo mariadbd --print-defaults
sudo du -sh /var/lib/mysql
df -h /data
findmnt -T /data/data가 없으면 먼저 대상 디스크를 준비하고 마운트합니다. df와 findmnt 결과가 의도한 디스크인지 확인한 뒤 진행합니다. MariaDB 옵션 파일 설명처럼 나중에 읽은 설정이나 실행 인수가 값을 덮어쓸 수 있으므로, 실제 서비스가 읽는 설정 파일을 백업한 뒤 수정해야 합니다.
정상 종료 후 전체 데이터 복사
다음 예제는 서비스 이름이 mariadb, 서비스 계정이 mysql, 새 위치가 /data/mariadb/인 경우입니다. rsync가 없다면 중단 전에 설치합니다. 서비스를 중지한 뒤 상태가 inactive이고 서버 프로세스가 종료되었는지 확인합니다. is-active는 비활성 상태에서 0이 아닌 종료 코드를 반환할 수 있습니다. 종료 실패나 다른 인스턴스가 같은 디렉터리를 사용하는 상황에서는 복사하지 않습니다.
sudo systemctl stop mariadb
sudo systemctl is-active mariadb
sudo systemctl status mariadb --no-pager새 대상은 비어 있어야 합니다. 다른 인스턴스의 파일이 있으면 덮어쓰지 말고 다른 빈 디렉터리를 선택합니다. 아래 명령은 디렉터리를 만든 뒤 권한과 소유자를 지정하고, 원본의 숨김 파일과 엔진 파일을 포함해 복사합니다. -a는 소유자·권한 등을 보존하며, cp -a도 속성 보존이 가능합니다. 일반 cp 사용만으로 항상 같은 결과가 보장되는 것은 아닙니다.
sudo mkdir -p /data/mariadb
sudo chown mysql:mysql /data/mariadb
sudo chmod 750 /data/mariadb
sudo rsync -aHAX --numeric-ids /var/lib/mysql/ /data/mariadb/
sudo rsync -aHAXnci --numeric-ids /var/lib/mysql/ /data/mariadb/첫 번째 rsync는 실제 복사이고 두 번째는 체크섬으로 비교하는 모의 실행입니다. 두 명령 모두 종료 코드가 0인지 확인하고, 두 번째 명령에 파일 변경 내역이 나오면 원인을 해결합니다. 원본 경로 끝의 /는 폴더 자체가 아닌 내용물을 복사한다는 뜻입니다. 새 파일시스템이 ACL(접근 제어 목록)이나 확장 속성을 지원하지 않아 오류가 나면 무시하지 말고 대상 파일시스템과 옵션을 검토합니다.
datadir와 보안 정책 변경
실제로 읽히는 서버 옵션 그룹 안의 datadir를 다음처럼 바꿉니다. 기존 그룹이 있으면 그 안의 해당 항목을 수정하며, 같은 파일 곳곳에 중복 추가하지 않습니다.
[mysqld]
datadir=/data/mariadb폴더 소유자만 맞아도 서비스의 보안 정책이 새 경로를 막을 수 있습니다. AppArmor는 프로그램의 파일 접근을 제한하는 Linux 보안 기능입니다. 활성 프로필과 커널 로그에서 DENIED 및 MariaDB 실행 파일 경로를 확인합니다.
sudo aa-status
sudo journalctl -k -b --no-pager실제 MariaDB 프로필이 기존 경로만 허용한다면 해당 프로필의 로컬 규칙 또는 별칭을 조정합니다. MariaDB 시작 실패 문서는 /etc/apparmor.d/tunables/alias에 다음 별칭을 추가하는 방법을 안내합니다. 이 파일을 사용하는 프로필인지 먼저 확인하고 백업한 뒤 적용하며, sudo systemctl reload apparmor의 성공 여부를 확인합니다. 프로필 구성은 배포판·패키지별로 다르므로 별칭 한 줄을 모든 설치의 필수 작업으로 취급하지 않습니다.
alias /var/lib/mysql/ -> /data/mariadb/,systemctl cat mariadb에서 ReadWritePaths, ProtectSystem 등의 제한도 확인합니다. 별도 디스크라면 sudo systemctl edit mariadb로 다음 설정을 추가해 해당 경로의 마운트가 먼저 준비되도록 할 수 있습니다. 이는 디스크를 포맷하거나 /etc/fstab의 영구 마운트 설정을 대신하지 않습니다. systemd의 RequiresMountsFor 설명을 참고합니다.
[Unit]
RequiresMountsFor=/data/mariadb/home·/root 아래는 기본 서비스 정책으로 차단될 수 있으므로 이 예제에서는 사용하지 않습니다. 추가 쓰기 허용이 필요하면 필요한 경로만 허용하고 보안 기능 전체를 끄지 않습니다. 서비스 제한은 MariaDB systemd 문서에서 확인할 수 있습니다.
서비스 시작과 적용 결과 확인
서비스 단위 설정을 수정했다면 재로딩하고 MariaDB를 시작합니다. SQL 결과가 /data/mariadb/인지 확인합니다. 경로를 바꾸어도 클라이언트 접속에 쓰는 소켓 경로까지 바꿀 필요는 없으며, 의도하지 않은 다른 옵션 변경은 피합니다.
sudo systemctl daemon-reload
sudo systemctl start mariadb
sudo systemctl status mariadb --no-pager
sudo mariadb -e "SELECT @@datadir;"서비스가 시작되지 않거나 이전 경로가 나오면 애플리케이션을 연결하지 말고 아래의 문제 해결 절차로 넘어갑니다.
Windows에서 데이터 디렉터리 옮기기
서비스 이름·계정·my.ini 위치 확인
관리자 PowerShell에서 다음 명령으로 MariaDB 서비스의 실제 이름, 로그온 계정과 실행 경로를 확인합니다. 예제의 서비스 이름 MariaDB와 설치 버전 11.4는 자신의 값으로 바꿉니다. Windows MSI 설치 문서의 기본 이름과 실제 등록된 서비스 이름은 다를 수 있습니다.
Get-CimInstance Win32_Service |
Where-Object { $_.PathName -match 'mariadbd|mysqld' } |
Select-Object Name, State, StartName, PathName
sc.exe qc MariaDB실행 경로의 --defaults-file가 지정한 my.ini를 우선 확인합니다. 지정이 없으면 해당 실행 파일의 --help --verbose에 나오는 설정 검색 경로와 실제 파일을 확인합니다. 파일 탐색기의 보기 → 표시 → 파일 확장명을 켜서 my.ini.txt로 잘못 저장하지 않도록 합니다. 현재 SQL의 @@datadir 결과도 함께 기록하고 실제로 쓰는 설정 파일을 다른 위치에 백업합니다.
서비스 중지와 파일 복사
아래는 C:\Program Files\MariaDB 11.4\data에서 비어 있는 새 폴더 C:\MariaDB로 옮기는 예입니다. 서비스 상태가 Stopped인지 확인하고 진행합니다. 폴더가 이미 존재하면 내용을 먼저 확인하며, 다른 데이터와 병합하지 않습니다.
Stop-Service -Name 'MariaDB'
Get-Service -Name 'MariaDB'New-Item -ItemType Directory -Path 'C:\MariaDB'
robocopy "C:\Program Files\MariaDB 11.4\data" "C:\MariaDB" /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ /XF my.ini
$copyExit = $LASTEXITCODE
if ($copyExit -ge 8) { throw "Robocopy failed: $copyExit" }이 명령은 하위 폴더를 복사하되 my.ini는 기존 위치에서 계속 사용하도록 제외합니다. /COPY:DAT는 데이터·속성·시간을 복사하며, 새 폴더의 접근 권한은 다음 단계에서 따로 설정합니다. /XJ는 정션을 제외하므로 원본에 정션이나 외부 파일이 있으면 별도로 처리해야 합니다. Microsoft Robocopy 문서에 따라 종료 코드 8 이상은 복사 실패입니다. 0~7도 무조건 완료로 간주하지 말고 요약의 실패·불일치와 예상 밖의 추가 파일을 검토합니다.
서비스 계정에 권한 부여하고 datadir 수정
services.msc에서 대상 서비스의 속성 → 로그온을 확인하고, 새 폴더의 속성 → 보안 → 편집 → 추가에서 실제 실행 계정에 수정 권한을 줍니다. SQL 로그인 root와 Windows 서비스 실행 계정은 서로 다릅니다. Everyone에 전체 권한을 줄 필요는 없습니다.
해당 서비스의 가상 계정이 NT SERVICE\MariaDB임을 확인한 경우에만 다음 명령을 사용할 수 있습니다. 이름이 다르거나 별도 사용자·도메인 계정으로 실행되면 그 계정에 맞게 바꿉니다. (OI)(CI)M은 하위 파일·폴더에 상속되는 수정 권한입니다. Microsoft icacls 문서에서 권한 표기를 확인할 수 있습니다.
icacls "C:\MariaDB" /grant "NT SERVICE\MariaDB:(OI)(CI)M"
icacls "C:\MariaDB"기존 my.ini의 서버 옵션 그룹에서 다음 항목을 수정하고 같은 위치에 저장합니다. 슬래시를 사용하면 역슬래시 이스케이프 문제를 줄일 수 있습니다. --defaults-file가 여전히 원래 파일을 가리키도록 두며, 설정 파일까지 옮기는 작업을 함께 하지 않습니다.
[mysqld]
datadir=C:/MariaDB서비스 시작 후 SQL로 확인
서비스를 시작한 다음 클라이언트에서 접속합니다. 비밀번호는 -p 뒤에 직접 쓰지 않고 프롬프트에서 입력합니다.
Start-Service -Name 'MariaDB'
Get-Service -Name 'MariaDB'
& 'C:\Program Files\MariaDB 11.4\bin\mariadb.exe' -u root -p접속 후 SELECT @@datadir; 결과가 C:\MariaDB\ 또는 동등한 슬래시 표기의 새 경로인지 확인합니다. Running 상태만으로 올바른 데이터가 열렸다고 판단하지 않습니다.
기존 데이터와 새 쓰기가 유지되는지 검증
기존 데이터베이스 목록과 대표 테이블의 행 수·알려진 값을 변경 전 기록과 비교합니다. 그런 다음 관리 권한이 있는 연결에서 아래 검증용 이름이 아직 없는지 확인하고 실행합니다. 이미 존재하면 다른 고유한 이름으로 모든 문장을 함께 바꾸며, 실제 업무 데이터베이스에 테스트 테이블을 만들지 않습니다.
SELECT @@datadir;
CREATE DATABASE datadir_move_check_13862;
CREATE TABLE datadir_move_check_13862.probe (id INT PRIMARY KEY);
INSERT INTO datadir_move_check_13862.probe VALUES (1);
SELECT * FROM datadir_move_check_13862.probe;마지막 조회에서 id가 1인 행이 나와야 합니다. 외부 쓰기를 계속 막은 상태에서 서비스를 한 번 더 정상 재시작한 뒤, 다시 접속하여 다음을 확인합니다.
SELECT @@datadir;
SELECT * FROM datadir_move_check_13862.probe;새 경로가 그대로이고 행 1이 다시 조회되면 새 위치에서 쓰기와 재시작 후 읽기가 동작한 것입니다. 시험용 데이터베이스만 다음 문장으로 제거한 뒤, 애플리케이션의 실제 연결과 읽기·쓰기를 점검하고 서비스를 재개합니다. 폴더 하나가 생성되었다는 사실만으로 InnoDB 데이터 전체의 정상 이전을 판단하지 않습니다.
DROP DATABASE datadir_move_check_13862;원본 디렉터리는 검증·백업 보존 기간이 끝날 때까지 삭제하지 않습니다. 새 경로가 백업 작업과 모니터링 대상에도 포함되는지 확인합니다.
시작 실패나 이전 경로가 나올 때 확인할 점
- 이전 datadir가 표시됨: 다른
my.ini·my.cnf를 수정했거나, 뒤에 읽히는 설정·서비스 실행 인수가 덮어쓰는지 확인합니다. 다른 포트·소켓의 인스턴스에 접속한 것은 아닌지도 확인합니다. - Permission denied 또는 테스트 파일 생성 실패: 서비스 계정과 상위 폴더의 통과 권한, 새 폴더의 쓰기 권한을 확인합니다. Ubuntu에서는 AppArmor와 systemd 거부 로그를 함께 보고, Windows에서는 실제 서비스 계정의 ACL을 확인합니다.
- 시스템 테이블 없음 또는 데이터베이스 누락: 데이터 내용 대신 상위 폴더가 한 단계 더 들어갔거나 복사가 누락되었는지 확인합니다. 새 디렉터리를 초기화하거나
ibdata1·로그 파일을 임의 삭제하지 않습니다. - 디스크 재부팅 후 실패: 대상 볼륨이 영구 마운트되었는지, 서비스보다 먼저 준비되는지, 드라이브 문자가 바뀌지 않았는지 확인합니다.
Ubuntu의 확인 명령은 다음과 같습니다. 로그의 오류 시각과 경로를 먼저 확인하며, namei로 상위 디렉터리마다 서비스 계정이 접근할 수 있는지도 살펴봅니다.
sudo journalctl -u mariadb -b -n 100 --no-pager
sudo journalctl -k -b --no-pager
namei -l /data/mariadb
sudo systemctl cat mariadbWindows에서는 설정의 log_error 위치, 새·기존 데이터 폴더의 .err 파일과 이벤트 뷰어의 관련 오류를 확인합니다. 서비스 오류 1067 같은 일반 메시지만 보고 원인을 단정하지 않습니다. MariaDB 시작 실패 진단에 오류별 확인 사항이 정리되어 있습니다.
원래 경로로 되돌리는 기준과 방법
새 위치에서 외부 쓰기를 아직 허용하지 않았다면 MariaDB를 중지하고 완전 종료를 확인한 뒤, 백업한 설정 파일 또는 원래 datadir 값을 복구합니다. 이 작업에서 추가한 AppArmor 별칭·systemd drop-in만 되돌리고 다른 기존 설정은 유지합니다. systemd 설정을 바꿨다면 daemon-reload 후 서비스를 시작하여 원래 경로와 기존 데이터를 확인합니다.
새 위치에 이미 실제 쓰기가 있었다면 남아 있는 원본은 최신 데이터가 아닙니다. 원래 경로를 가리키기만 하면 그 이후의 변경을 잃을 수 있으므로, 쓰기를 다시 차단하고 최신 데이터를 백업한 뒤 정지 상태의 역이전 또는 복구 계획을 세웁니다. 두 데이터 디렉터리의 파일을 섞거나 양쪽 서버를 동시에 실행해서는 안 됩니다.
