Gbak 백업-복원 빠른 가이드

gbak이란 무엇인가?

Gbak은 표준 Firebird 명령줄 도구입니다(공식 문서는 여기에서 확인). 1) 데이터베이스의 전체 백업: 데이터베이스의 모든 레코드를 읽어 백업 파일에 저장, 2) 백업을 새 데이터베이스로 복원하는 작업을 수행하도록 설계되었습니다.

다른 RDBMS 경험이 있는 개발자와 관리자에게 “백업"이라는 용어는 다소 혼동될 수 있습니다. gbak은 데이터베이스의 정확한 복사본이 아니라 데이터만 포함된 비데이터베이스 형식의 파일(인덱스는 선언으로 저장됨)을 생성하기 때문입니다.

gbak 백업 파일에서 데이터베이스를 생성하려면 gbak으로 복원 프로세스를 수행해야 합니다.

1. Gbak으로 백업 마스터하기

1.0. 준비

C:\data 폴더를 만들고 그 안에 데이터베이스를 넣어 보겠습니다. Firebird OLTP-EMUL 테스트의 5Gb 데이터베이스를 사용하겠지만, 물론 자신의 데이터베이스를 사용해도 됩니다.

Linux 사용자의 경우 - /db 폴더를 만들고 소유자를 “firebird"로 변경한 다음 데이터베이스를 복사하세요(소유자도 firebird인지 확인).

Code

mkdir /db
chown firebird -R /db

1.1 gbak 명령으로 가장 간단한 Firebird 백업

Windows

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

이 예제에서 gbak 도구는 로컬 또는 임베디드 액세스를 사용하여 데이터베이스 파일에 접근합니다.

Firebird 3.0: Firebird 3.0의 기본 구성(ServerMode = SuperServer의 firebird.conf 매개변수)에서 임베디드 액세스는 데이터베이스에 배타적 잠금을 시도하므로 다른 연결은 데이터베이스에 액세스할 수 없게 됩니다(또는 활성 연결로 인해 gbak 시도가 실패할 수 있습니다).

Firebird 2.5: Windows에서 Firebird 2.5를 사용하면 XNET 프로토콜을 통해 명령이 정상적으로 작동합니다(물론 Firebird 인스턴스가 하나만 실행 중인 경우). Linux에서 Firebird는 임베디드 액세스를 시도하고, 접근할 수 없으면 자동으로(그리고 암시적으로) TCP/IP를 통해 연결을 시도합니다. (XNET, INET 등의 의미를 모르는 경우 Firebird 연결 문자열 치트 시트를 참조하세요).

참고 1: 이 명령은 OS 사용자(즉, 사용자 본인) 계정으로 실행되며, 해당 권한을 사용하여 백업 및 데이터베이스 파일에 액세스합니다.

일반적으로 Windows의 Firebird 서비스는 LocalSystem 계정으로 실행되고, Linux에서는 “firebird” 사용자로 실행되지만, 콘솔은 일반적으로 사용자 본인의 계정으로 실행됩니다.

이 사용자 계정이 데이터베이스 경로나 백업 경로에 액세스할 수 없으면 gbak은 “Cannot open backup file” 오류와 함께 실패합니다(부록 A. 오류, #5의 예 참조).

참고 2: gbak -b는 백업 파일을 자동으로 덮어씁니다. 따라서 이미 backup1.fbk가 있으면 덮어쓰게 됩니다.

참고 3: Linux에서 이 gbak 명령은 콘솔 사용자와 동일한 소유자로 백업 파일을 생성합니다.

이 명령의 백업 시간: 120초

1.2. Windows에서 온라인으로 수행할 수 있는 gbak 로컬 백업

이 섹션은 Windows 사용자 전용입니다! 일반적으로 활성 연결이 있는 상태에서 백업을 수행해야 하므로, 임베디드 연결 대신 Firebird 3에서 gbak 자체가 데이터베이스 파일에 배타적 잠금을 걸지 않도록 로컬 프로토콜, 즉 XNET을 명시적으로 지정하는 것이 좋습니다.

Firebird 3.0의 경우:

Code

gbak -b xnet://c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Firebird 2.5의 경우 로컬 연결 문자열을 사용할 수 있으며 XNET도 사용됩니다:

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux에서 Firebird는 Windows의 XNET과 같은 특정 로컬 프로토콜을 지원하지 않으므로 TCP/IP 연결 문자열을 사용해야 합니다(섹션 1.3 참조).

또한 XNET은 단일 Firebird 인스턴스에서만 작동하므로, Windows에서 여러 Firebird 인스턴스를 실행하는 경우 대상 서버 인스턴스를 지정하기 위해 INET 스타일 연결 문자열을 사용하는 것이 더 쉬울 수 있습니다.

백업 시간: 139초

1.3. TCP/IP 연결 문자열을 사용한 gbak 백업

이것은 온라인 백업을 수행하는 가장 보편적인 gbak 명령입니다.

Windows

Code

gbak -b localhost:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

이 경우 데이터베이스 경로 시작 부분에 localhost: 를 지정하면 Firebird의 네트워크 하위 시스템을 통해 연결이 이루어집니다.

로컬 액세스보다 약간 느리지만 연결을 수락하는 실행 중인 서버가 있는 모든 경우에 작동합니다.

Firebird의 비표준 포트

Firebird가 비표준 포트(예: 3050 대신 3051)에서 실행 중인 경우 다음과 같이 백업할 수 있습니다:

Windows

Code

gbak -b localhost/3051:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost/3051:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

백업 시간: 182초

1.4. Service Manager를 사용한 더 빠른 gbak 백업

TCP/IP 연결의 보편성, 비표준 포트 지원, 그리고 빠른 로컬 백업을 어떻게 달성할 수 있을까요? Service Manager를 사용해 봅시다! Service Manager는 간단히 말해 표준 도구를 Firebird 엔진을 통해 실행하는 방법입니다. Service Manager의 경우 데이터베이스 경로에 서버 이름을 지정할 필요가 없으며, -se 매개변수에만 지정하면 된다는 점에 유의하세요.

Windows

Code

gbak -b -se localhost:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

이 명령은 -service 스위치를 사용하여 포트 3050에서 실행 중인 Firebird 인스턴스의 Service Manager를 사용하여 백업을 수행하도록 지정합니다.

이 경우 백업은 Firebird 프로세스 내부에서 직접 수행되며(프로세스에 gbak 코드 사본이 있음), 프로세스 내 통신이 훨씬 빠르기 때문에 백업이 훨씬 빨라집니다.

Firebird가 비표준 포트(예: 3051)에서 실행 중인 경우 명령은 다음과 같을 수 있습니다:

Code

gbak -b -se localhost/3051:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

참고: Firebird 2.5 및 Firebird 3.0.0-3.0.5(3.0.6에서만 제거됨)에는 중요한 제한 사항이 있습니다: 명령줄(데이터베이스 및 백업의 모든 매개변수와 경로)은 256자 미만이어야 합니다.

예를 들어 데이터베이스와 백업의 긴 경로로 인해 이 제한에 도달하면 databases.conf(3.0 이상) 또는 aliases.conf(2.5)에서 데이터베이스에 대한 별칭을 선언할 수 있습니다:

Code

mydb1=c:\Data\test1.fdb #Windows

또는

Code

mydb1=/db/test1.fdb  #linux

그런 다음 명령에서 이를 사용합니다:

Windows

Code

gbak -b -se localhost:service_mgr mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

백업 시간: 115초

1.5. 가비지 컬렉션을 억제한 가장 빠른 gbak 백업

백업을 더 빠르게 만들기 위해 -g 스위치를 추가해 봅시다.

Code

 -G(ARBAGE_COLLECT)    가비지 컬렉션 억제

따라서 백업 명령은 다음과 같습니다:

Windows

Code

gbak -b -se localhost:service_mgr -g mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr -g mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

-g 스위치는 Firebird 엔진이 데이터베이스 파일의 백업 프로세스에 대해 가비지 컬렉션을 비활성화하도록 강제합니다.

이는 가비지 레코드 버전이 백업 파일에 저장된다는 의미가 아니라, 서버가 백업 중에 데이터베이스의 기존 가비지를 정리하려고 시도하지 않으므로 백업이 더 빨라진다는 의미입니다.

이 스위치 사용을 강력히 권장합니다. 가비지 컬렉션 및 관련 정리는 sweep(gfix -sweep 또는 autosweep)에 의해 수행되어야 한다고 생각하기 때문에, gbak을 sweep의 대안으로 간주하지 않는 것이 좋습니다.

백업 시간: 105초

1.6. 네트워크 공유 또는 네트워크 위치로 백업

백업 파일을 네트워크 공유에 저장해야 한다면 어떻게 해야 할까요?

Windows에서

Firebird 초보자들이 자주 혼동하는 점: 명령 프롬프트에서 명령을 실행하는 수동 백업(간단한 gbak -b)은 네트워크 공유로 잘 작동하지만, -se localhost:service_mgr을 사용하는 빠른 버전의 gbak은 작동하지 않습니다.

그 이유는 Windows의 Firebird가 LocalSystem 계정으로 실행되는데, 이 계정은 네트워크 위치에 액세스할 수 없기 때문입니다(네트워크 공유에 “Everyone” 그룹에 대한 액세스가 구성된 경우 제외, 하지만 이는 랜섬웨어 시대에 매우 위험합니다).

해결책은 Windows에서 Firebird 서비스를 네트워크 공유에 액세스할 수 있는 충분한 권한과 동시에 로컬 데이터베이스 파일 및 C:\ProgramData\Firebird의 시스템 파일에 액세스할 수 있는 충분한 권한을 가진 계정으로 실행하는 것입니다. 또한 firebird.conf에서 RestrictAccess 매개변수를 구성하는 것도 좋은 방법입니다.

Linux에서

Linux의 Firebird는 “firebird” 계정으로 실행되므로, 네트워크 공유를 “firebird” 사용자에 매핑하여 마운트하면 Firebird 서비스가 로컬 드라이브와 동일한 방식으로 네트워크 위치에 액세스할 수 있습니다.

1.7. 원격 서버에서 로컬 머신으로의 간단한 백업

원격 서버의 데이터베이스를 로컬 머신으로 백업하는 것이 가능합니다.

아래 예제 명령은 Windows 컴퓨터에서 시작되어 Linux 서버(IP 주소 192.168.0.108, 물론 서버의 호스트 이름도 사용 가능)의 데이터베이스에 액세스하고, 백업 파일은 Windows의 C:\Data 폴더에 저장됩니다:

Code

gbak -b -user SYSDBA -pass masterkey 192.168.0.108:/db/test1.fdb c:\data\remotebackup1.fbk

백업 시간: 568초

이 명령은 일반적으로 로컬 백업보다 훨씬 느립니다. gbak이 원격 서버에서 데이터를 읽고 네트워크를 통해 레코드를 전송하기 때문입니다.

1.8. Service Manager를 사용한 원격 서버에서 로컬로의 더 빠른 백업

아래 명령은 #1.7에서 설명한 원격 서버에서 로컬 머신으로의 기존 백업보다 빠릅니다.

Code

gbak -b -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb stdout > C:\Data\remoteback1.fbk

이 명령은 Service Manager를 사용하여 원격 서버에서 백업을 수행하지만, 출력은 stdout 파이프로 전송된 다음 로컬 파일로 리디렉션됩니다.

이 명령은 일반적으로 #1.7(원격 서버에서 로컬로의 간단한 백업)보다 15%-20% 빠릅니다. 그 이유는 다음과 같습니다:

원격 서버에서 Service Manager를 통해 백업을 수행하므로 모든 읽기 및 압축 작업이 가장 빠른 방식으로 수행됩니다.
네트워크를 통해 전송되는 것은 결과 백업 파일뿐이며, 데이터베이스의 데이터보다 크기가 작습니다.

그러나 이 명령으로는 자세한 출력(verbose mode)을 활성화하고 로그 파일에 저장할 수 없습니다.

백업 시간: 473초

1.9. Service Manager를 사용하여 원격 서버의 Firebird 데이터베이스를 동일한 원격 서버에 백업

Service Manager를 사용하면 원격 서버의 데이터베이스에 대한 gbak 백업을 호출하고 동일한 원격 서버에 저장할 수도 있습니다.

Code

gbak -b -se  192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb /db/back12.fbk

이 명령은 Service Manager를 통해 원격 서버에서 백업을 호출하며, 백업 파일도 동일한 네트워크 서버에 저장하도록 지시합니다.

물론 백업 위치는 Firebird 서비스가 액세스할 수 있어야 합니다(Linux에서는 “firebird” 사용자로, Windows에서는 LocalSystem 계정으로 실행됨).

1.10. Firebird 5(또는 HQbird 2.5/3.0/4.0/5.0)의 멀티스레드 백업으로 Firebird 데이터베이스를 6배 더 빠르게 백업

Firebird gbak의 백업 성능에 여전히 만족하지 못한다면 Firebird 5로 마이그레이션하는 것을 고려해 보세요(또는 다른 버전의 경우 엔터프라이즈 Firebird 배포판: HQbird 사용).

멀티스레드 백업을 지원하여 gbak으로 최대 6배 더 빠른 백업 작업이 가능합니다.

Code

gbak -b -par 8  -se localhost:service_mgr -g C:\Data\testbigdb1.fdb c:\Data\backup1.fbk -user SYSDBA -pass masterkey

보시다시피 새로운 매개변수 -par 8이 있으며, 이는 gbak이 백업 생성에 8개의 스레드를 사용하도록 합니다.

HQbird는 유지 관리 작업(sweep, backup, restore)을 훨씬 빠르게 수행합니다(아래 그림의 결과는 물론 다른 데이터베이스에서 가져온 것입니다):

2. Gbak 도구로 복원

위 명령 중 하나로 생성된 백업 파일 backup1.fbk이 있으며, 이를 빠르고 효율적인 방식으로 복원해야 합니다.

Windows의 경우 파일이 C:\Data\backup1.fbk에 있고, Linux의 경우 /db/backup1.fbk에 있다고 가정해 봅시다.

2.1. 가장 간단한 복원 명령

Windows에서

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux에서

Code

gbak -c /db/backup1.fbk /db/new1.fdb -user SYSDBA -pass masterkey

우선, gbak -c는 데이터베이스 파일을 덮어쓰지 않는다는 점에 유의하세요. C:\data\new1.fdb 또는 /db/new1.fdb 파일이 이미 존재하면 gbak은 데이터베이스가 이미 존재한다는 오류를 반환합니다.

그러면 이 명령은 실제로 2.5/3.0+ 및 Windows/Linux에서 매우 다르게 동작합니다.

Linux에서는 이 명령이 생성된 데이터베이스에 임베디드 액세스를 사용합니다(물론 firebird.conf에서 Firebird 공급자의 순서를 변경하지 않은 경우) - 3.0과 2.5 모두에 해당합니다.

Windows에서는 Firebird 3.0의 기본 공급자 순서로 임베디드 액세스가 사용되고, 2.5에서는 XNET이 사용됩니다.

그런 다음 이 명령은 gbak을 시작한 사용자의 권한으로 파일을 생성합니다. 특히 Linux에서 중요한데, root로 gbak을 실행하면 데이터베이스 파일의 소유자가 root가 되고, “firebird” 사용자로 실행되는 Firebird 프로세스는 복원된 파일에 액세스할 수 없게 됩니다.

Linux 사용자를 위한 참고 사항

많은 사람들이 소유권을 “수정"하기 위해 모든 사용자가 복원된 데이터베이스에 액세스할 수 있도록 권한을 부여합니다(예: “chmod 777 database”). 하지만 이는 매우 안전하지 않습니다. 올바른 방법은 다음 명령으로 데이터베이스의 소유자를 firebird로 변경하는 것입니다.

Code

chown firebird /db/new1.fdb

일반적으로 이 명령은 프로덕션이 아닌 데이터베이스(테스트 또는 개발용)의 단순 복원에 충분히 좋습니다.

복원 시간: 275초

2.2. localhost 연결 문자열로 복원

가장 보편적이지만 가장 빠르지는 않은 복원 옵션은 다음과 같습니다:

Windows

Code

gbak -c C:\Data\backup1.fbk localhost:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

비표준 포트

Firebird가 비표준 포트(예: 3051)에서 실행 중인 경우 복원 명령에서 지정할 수 있습니다:

Windows

Code

gbak -c C:\Data\backup1.fbk localhost/3051:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost/3051:/db/new1.fdb -user SYSDBA -pass masterkey

복원 시간: 1225초

2.3. Windows에서 XNET으로 복원

Windows에서 복원을 조금 더 빠르게 하려면 XNET을 사용할 수 있습니다(Firebird 3.0 이상):

Code

gbak -c C:\Data\backup1.fbk xnet://C:\Data\New2.fdb -user SYSDBA -pass masterkey

Windows의 Firebird 2.5에서는 단순 명령줄로 XNET 액세스가 사용됩니다(Firebird 인스턴스가 하나만 실행 중인 경우):

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

복원 시간: 585초

2.4. Service Manager로 더 빠른 복원

그리고 가장 빠른 복원 방법은 Service Manager를 사용하는 것입니다.

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

-se 스위치를 사용하면 localhost 주소에서 Service Manager를 호출하고 Firebird 엔진 내부에서 복원 코드를 수행하도록 지시합니다.

Service Manager가 복원을 수행하면 생성된 데이터베이스 파일은 실행 중인 Firebird 인스턴스(프로세스)의 계정이 소유하게 됩니다 - Linux에서는 “firebird”, Windows에서는 LocalSystem입니다.

복원 시간: 244초

2.5. 권장하지 않는 스위치

어떤 시점에서 다음 스위치를 사용하고 싶은 유혹이 있을 수 있습니다:

Code

   -R(ECREATE_DATABASE) [O(VERWRITE)] create (or replace if OVERWRITE used)                               database from backup file (restore)

Code

기존 데이터베이스를 새 데이터베이스로 강제로 교체하기 위해 사용합니다.

우리의 경험에 따르면 이 스위치는 프로덕션 데이터베이스를 실수로 덮어쓸 가능성을 크게 높입니다.

데이터베이스를 매번 새 이름으로 복원하고 이름을 변경한 다음, 이전 데이터베이스를 명시적으로 삭제할 것을 강력히 권장합니다.

이 스위치를 사용한 명령의 예는 제공하지 않겠습니다.

2.6. 별칭을 사용하여 데이터베이스 복원

databases.conf(Firebird 2.5에서는 aliases.conf)에 선언된 별칭을 사용하여 데이터베이스를 복원할 수 있습니다.

예를 들어 다음과 같은 선언이 있다고 가정합니다:

Code

restdb=c:\Data\newrest1.fdb  #Windows

restdb=/db/newrest1.fdb  #Linux

그러면 별칭이 지정한 경로로 백업을 복원하기 위해 다음 명령을 실행할 수 있습니다.

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk restdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk restdb -user SYSDBA -pass masterkey

2.7. 로컬 백업을 원격 서버로 복원

로컬 백업 파일을 원격 Firebird 서버로 복원하는 것이 가능합니다.

이 예에서는 Windows에 저장된 백업 파일을 Linux 서버(IP 주소 102.168.0.108)로 복원합니다:

Code

gbak  -c C:\Data\backup1.fbk 192.168.0.108:/db/newdb1.fdb -user SYSDBA -pass masterkey

복원 시간: 7009초

보시다시피 원격 복원 프로세스는 매우 느리게 작동합니다. Service Manager로 속도를 높일 수 있을까요?

2.8. Service Manager로 로컬 백업을 원격 서버에 복원

Service Manager로 원격 서버에 로컬 백업을 복원하려면 stdin 입력 스트림을 사용하는 트릭이 필요합니다:

Code

gbak -c -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey stdin /db/new3.fdb <  C:\Data\backup1.fbk

이 명령은 원격 서버에서 백업 소스로 표준 입력 stdin을 사용하여 복원을 호출하고, 명령의 < C:\Data\backup1.fbk 부분을 사용하여 입력을 공급합니다.

조금 까다로워 보이나요? 하지만 원격 서버로 복원할 때 gbak 성능을 10배 향상시키는 쉬운 방법입니다!

복원 시간: 450초

2.9. 매우 긴 테이블 복원

총 행 수가 20억 개를 초과하는 정말 큰 데이터베이스가 있는 경우, 내부 오버플로를 방지하기 위해 각 테이블을 별도의 트랜잭션으로 복원하도록 -o[ne_at_a_time] 스위치를 지정해야 합니다.

Code

gbak -c -se localhost:service_mgr -one C:\Data\backup1.fbk C:\data\new44.fdb -user SYSDBA -pass masterkey

3. 백업 및 복원 프로세스 튜닝과 로깅

3.1. 상세 출력이 있는 Gbak

기본적으로 gbak은 매우 조용한 도구로, 성공적으로 실행되면 아무것도 반환하지 않습니다. 상세 출력을 원하면 -v[erify] 스위치를 추가할 수 있습니다.

Code

gbak -b -se localhost/3050:service_mgr -g mydb1  c:\Data\backup1.fbk -v -user SYSDBA -pass masterkey

결과적으로 더 많은 세부 정보가 표시됩니다. 콘솔에 출력을 인쇄하면 상세 백업이 무음 버전보다 훨씬 느려질 수 있다는 사소하지만 성가신 문제가 있으므로, -y logfile 스위치로 로그를 파일에 저장하는 것이 좋은 생각입니다:

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1  c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

참고: gbak은 기존 로그 파일을 덮어쓰지 않습니다! 이 예에서 이미 C:\data\backuplog1.txt가 있다면 백업은 오류를 발생시킵니다(부록 A의 #3 참조).

참고 2: 백업 또는 복원 중 처리된 레코드 수를 보고하는 간격을 제어하는 -verbint 옵션이 있습니다.

3.2. 상세 출력에 성능 통계 추가

백업 및 복원에 대한 gbak 상세 출력에서 다음과 같은 메시지를 볼 수 있습니다:

Code

gbak:    writing data for table COUNTRY
gbak:16 records written

모든 테이블 및 기타 데이터베이스 개체에 대해 표시됩니다.

어떤 테이블/개체가 가장 많은 시간을 차지하는지 알아내는 것이 흥미롭지 않나요?

이를 위해 -st(atistics) 스위치를 사용해야 합니다:

Code

 -ST(ATISTICS) TDRW    show statistics:
     T                 time from start
     D                 delta time
     R                 page reads
     W                 page writes

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -st tdrw c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

적용하면 로그에 다음 열이 추가됩니다:

Code

gbak: time   delta  reads  writes

각 줄에 소요된 시간과 IO를 확인할 수 있습니다.

3.3. 백업 및/또는 복원에서 테이블 제외

일부 테이블을 백업에서 제외할 수 있다고 생각되면(좋은 예는 매우 긴 로그 테이블입니다), SK[IP_DATA] 매개변수에 정규식을 매개변수로 지정할 수 있습니다.

아래 예시에서는 백업에서 COUNTRY 및 JOB 테이블의 데이터를 제외합니다:

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -SKIP_D ‘(COUNTRY|JOB)’ c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

그리고 아래 예시에서는 복원에서 CLIENT 테이블을 제외합니다:

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new33.fdb -user SYSDBA -pass masterkey -SKIP_D "CLIENT"

SKIP_DATA 매개변수는 단일 매개변수로 전달되어야 하므로 따옴표로 묶어야 합니다!

Linux에서는 작은따옴표를, Windows에서는 큰따옴표를 사용해야 합니다.

백업 및/또는 복원에서 테이블 제외 시 주의사항

필터 조건을 사용하기 전에 다음 쿼리로 정규식 조건을 확인하는 것을 강력히 권장합니다. 이 쿼리는 필터 조건에 해당하는 테이블 목록을 반환합니다(쿼리에서는 항상 작은따옴표를 사용합니다):

Code

SQL> SELECT RDB$RELATION_NAME FROM RDB$RELATIONS WHERE TRIM(RDB$RELATION_NAME) SIMILAR TO '(COUNTRY|JOB)';

RDB$RELATION_NAME
===============================
COUNTRY
JOB

백업 또는 복원에서 테이블이 제외될 때 기존 제약 조건(외래 키)과 관계없이 제외된다는 점에 유의하세요. 따라서 이러한 제외를 신중하게 계획하지 않았다면 복원 과정에서 “Cannot commit foreign key index” 오류가 발생하기 쉽습니다.

3.4. 파일에서 백업 또는 복원용 비밀번호 가져오기

명령을 보는 모든 사람에게 비밀번호가 노출되는 것이 마음에 들지 않는다면 다음 스위치를 좋아할 것입니다: -fetch passwordfile

C:\Data\passfile.txt에 비밀번호가 있는 파일을 만들고 사용해 보겠습니다(여기서는 매우 간단한 임베디드 변형을 사용합니다. 물론 이 스위치는 Service Manager에서도 작동합니다):

Code

gbak -b c:\Data\test1.fdb c:\Data\backup5.fbk -user SYSDBA -fetch C:\Data\passfile.txt

실용적인 이점이 2가지 있습니다:

비밀번호를 단일 파일에 저장하면 모든 명령 파일이 항상 실제 비밀번호를 사용하도록 보장할 수 있습니다.
모든 명령 파일에 비밀번호를 노출하지 않습니다.

4. 원스텝 백업-복원

백업의 목적이 즉시 복원을 수행하는 것인 경우가 많습니다. 예를 들어 데이터베이스에 새 페이지 크기를 적용하거나 기존 데이터베이스를 2.5에서 3.0으로 마이그레이션하기 위해 새 데이터베이스를 얻는 경우입니다.

이 경우 표준 입력과 출력을 해당 명령의 소스로 사용하여 단일 명령으로 백업-복원을 수행할 수 있습니다. 이를 통해 중간 백업 파일 생성을 건너뛰고, 여유 공간 요구 사항을 줄이며, 프로세스 속도를 높일 수 있습니다.

명령은 다음과 같습니다:

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout | gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

본질적으로 여기서는 | 기호로 연결된 2개의 명령을 수행합니다.

첫 번째는 stdout으로의 백업입니다:

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout

두 번째는 stdin에서의 복원입니다:

Code

gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

이 명령은 동일한 Firebird 인스턴스에서 백업-복원을 수행하는 가장 빠른 방법입니다.

참고: 원스텝 백업-복원으로 2.5에서 3.0으로 데이터베이스를 변환하려면 2개의 Firebird 인스턴스를 사용해야 합니다. 자세한 내용은 여기에서 확인하세요.

5. 성능 요약

다음 그림에는 테스트 데이터베이스의 로컬 백업에 대한 다양한 백업 명령의 속도 정보가 포함되어 있습니다:

보시다시피 로컬 백업을 수행하는 가장 빠른 방법은 Service Manager(스위치 -se[rvice])를 사용하고 가비지 컬렉션을 억제하는 것(스위치 -ig)입니다.

원격 서버에서 로컬 머신으로의 백업의 경우에도 Service Manager가 가장 좋은 옵션입니다:

복원 성능의 상황도 유사합니다: Service Manager가 복원하는 가장 빠른 방법입니다.

드문 경우인 로컬 백업에서 원격 서버로 복원할 때는 stdin 트릭과 함께 Service Manager를 사용하는 것이 유일한 실행 가능한 선택입니다:

VM 및 Firebird 백업에 대한 매우 자주 묻는 질문

모든 것을 백업하겠다고 약속하는 인기 있는 백업 도구가 있는데 왜 Firebird 백업 도구를 사용해야 합니까?

또는 가상 머신의 전체 이미지를 백업하는데 왜 Firebird 데이터베이스 백업에 신경을 써야 합니까?

답변은 여기에 있습니다.

부록 A. 백업/복원 중 오류

매개변수 없이 gbak을 실행하거나 데이터베이스 소유자가 아닌 사용자/비-SYSDBA로 실행하면 다음 오류가 발생합니다:

Code

gbak: ERROR:Unable to perform operation.  You must be either SYSDBA or owner of the database
gbak:Exiting before completion due to errors

잘못된 비밀번호를 지정하면 다음 오류가 발생합니다:

Code

gbak: ERROR:Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
gbak:Exiting before completion due to errors

기존 파일이 상세 로그 대상으로 지정되면 오류가 발생합니다:

Code

gbak: ERROR:cannot open status and error output file C:\data\backuplog1.txt
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

gbak 복원 명령에서 기존 데이터베이스가 대상으로 지정되면 오류가 발생합니다:

Code

gbak: ERROR:database C:\data\new1.fdb already exists.  To replace it, use the -REP switch
gbak:Exiting before completion due to errors

gbak이 쓰기 권한이 충분하지 않은 위치에 백업을 쓰려고 하면 오류가 발생합니다:

Code

gbak: ERROR:cannot open file  /db/test1.fbk
gbak:Exiting before completion due to errors

gbak이 권한 없이 파일에 접근하려고 할 때 - 예를 들어 Linux에서 파일 소유자가 “firebird” 사용자가 아닌 경우:

Code

gbak: ERROR:no permission for read-write access to database /db/test1.fdb
gbak: ERROR:    IProvider::attachDatabase failed when loading mapping cache
gbak:Exiting before completion due to errors

상세 출력을 사용하려는 시도:

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -user SYSDBA -pass masterkey /db/test1.fdb stdout  >
 c:\data\rembackup2.fbk
gbak: ERROR:standard output is not supported when using split operation or in verbose mode
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

상세 모드와 로그 파일 저장을 활성화한 상태에서 원격 서버에서 Service Manager로 백업을 시도:

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -y lg1.txt  -user SYSDBA -pass masterkey /db/test1.f
db stdout  > c:\data\rembackup2.fbk
gbak: ERROR:Invalid clumplet buffer structure: string length doesn't match with clumplet
gbak:Exiting before completion due to errors

어떤 이유로 백업이 실패할 때 원스텝 백업-복원에서 오류 발생:

Code

gbak: ERROR:No request from user for stdin data
gbak:Exiting before completion due to errors

gbak에 백업 파일이 아닌 파일을 전달하려는 경우:

Code

gbak: ERROR:unavailable database
gbak:Exiting before completion due to errors
gbak: ERROR:expected backup description record
gbak:Exiting before completion due to errors

잘못된 페이지가 있는 손상된 데이터베이스 파일의 백업은 다음 오류를 보고합니다(숫자와 데이터베이스 파일은 물론 다를 수 있습니다):

Code

gbak: ERROR:database file appears corrupt (E:\DATABASE1.FDB)
gbak: ERROR:    wrong page type
gbak: ERROR:    page 9294588 is of wrong type (expected 8, found 0)
gbak: ERROR:gds_$get_segment failed
gbak:Exiting before completion due to errors
gbak: ERROR:Unexpected I/O error while reading from backup file

gbak:오류로 인해 완료 전에 종료합니다

Code


## 연락처

질문이 있거나 오류나 오타를 보고하려면 언제든지 저희에게 연락해 주세요: [email protected]