diff --git a/README.md b/README.md index 2992a82493c..7a2a0bdda05 100644 --- a/README.md +++ b/README.md @@ -28,13 +28,13 @@ We recommend using MacOS to work with the EDB Docs application. 1. Install Python 3 with `brew install python3`, if it's not already installed. (Use `python3 -V` to check that you have version 3.6 or higher.) Python is not needed for the core Gatsby system, but is required by several source scripts. -1. Install Yarn with `npm i -g yarn`. Yarn is the package manager we're using for this project, instead of NPM. +1. Install Yarn with `npm i -g yarn`. Yarn is the package manager we're using for this project, instead of NPM. NPM may fail with a permissions related issue. To fix that, ensure that your user account owns the required directory: `sudo chown -R $(whoami) /usr/local/lib/node_modules` 1. Install Gatsby with `npm i -g gatsby-cli`. Gatsby is the software that powers the EDB Docs site. 1. Install all required packages by running `yarn`. -1. Pull the shared icon files down with `git submodule update --init`. +1. Pull the shared icon files down with `git submodule update --init`. This needs to be run inside of the project folder, if you have cloned the repo using GitHub Desktop, ensure that you have `cd` into the project. 1. And finally, you can start up the site locally with `yarn develop`, which should make it live at `http://localhost:8000/`. Huzzah! diff --git a/README_DOCKER_VSCODE.md b/README_DOCKER_VSCODE.md index ff4a6813bda..6fa6f0b3d56 100644 --- a/README_DOCKER_VSCODE.md +++ b/README_DOCKER_VSCODE.md @@ -7,6 +7,7 @@ If you cannot or do not wish to install the prerequisite versions of Python, Nod 1. [Docker](https://docs.docker.com/get-docker/) (for MacOS or Windows, that'll be Docker Desktop) 2. [Visual Studio Code](https://code.visualstudio.com/docs/setup/setup-overview) 3. The [Remote Development Extension Pack](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack) for VSCode +4. [Git](https://git-scm.com/download) If you intend to edit using VSCode, I also recommend installing the [MDX extension](https://marketplace.visualstudio.com/items?itemName=silvenon.mdx) - this is not required, but it is handy! @@ -14,7 +15,7 @@ If you intend to edit using VSCode, I also recommend installing the [MDX extensi 1. In VSCode, from the command pallet select the `Remote-Containers: Clone Repository in Container Volume...` command 2. Paste in the URL of this repository, or a GitHub branch URL, or a GitHub PR URL -3. Choose "isolated volume" (in most cases this will be what you want) +3. Choose "unique volume" (in most cases this will be what you want) 4. Wait for VSCode to build the container, then open a terminal 8. Run the site locally with `yarn develop`. VSCode will remap port 8000 used within the container to a free port on your machine, which you can view from the Remote Explorer panel in the left sidebar - or ctrl+click the URL that Gatsby prints in the terminal to open directly. diff --git a/product_docs/docs/bart/2.4/index.mdx b/product_docs/docs/bart/2.4/index.mdx deleted file mode 100644 index 2d2cd428e4c..00000000000 --- a/product_docs/docs/bart/2.4/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Backup and Recovery Tool -productStub: true -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.4 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.4" ---- - - diff --git a/product_docs/docs/bart/2.5.1/index.mdx b/product_docs/docs/bart/2.5.1/index.mdx deleted file mode 100644 index 20e2e3f9be3..00000000000 --- a/product_docs/docs/bart/2.5.1/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Backup and Recovery Tool -productStub: true -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5.1 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.5.1" ---- - - diff --git a/product_docs/docs/bart/2.5.2/index.mdx b/product_docs/docs/bart/2.5.2/index.mdx deleted file mode 100644 index 10def0c9765..00000000000 --- a/product_docs/docs/bart/2.5.2/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Backup and Recovery Tool -productStub: true -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5.2 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.5.2" ---- - - diff --git a/product_docs/docs/bart/2.5.3/index.mdx b/product_docs/docs/bart/2.5.3/index.mdx deleted file mode 100644 index cfb4eda4619..00000000000 --- a/product_docs/docs/bart/2.5.3/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Backup and Recovery Tool -productStub: true -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5.3 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.5.3" ---- - - diff --git a/product_docs/docs/bart/2.5.4/index.mdx b/product_docs/docs/bart/2.5.4/index.mdx deleted file mode 100644 index fbfb7811dea..00000000000 --- a/product_docs/docs/bart/2.5.4/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Backup and Recovery Tool -productStub: true -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5.4 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.5.4" ---- - - diff --git a/product_docs/docs/bart/2.5.5/index.mdx b/product_docs/docs/bart/2.5.5/index.mdx deleted file mode 100644 index 025b8a807ac..00000000000 --- a/product_docs/docs/bart/2.5.5/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Backup and Recovery Tool -productStub: true -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5.5 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.5.5" ---- - - diff --git a/product_docs/docs/bart/2.5.7/index.mdx b/product_docs/docs/bart/2.5.7/index.mdx deleted file mode 100644 index c7628a2a3ec..00000000000 --- a/product_docs/docs/bart/2.5.7/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Backup and Recovery Tool -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5.7 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." -productStub: true - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.5.7" ---- - - diff --git a/product_docs/docs/bart/2.5.9/bart_inst/02_installing_bart.mdx b/product_docs/docs/bart/2.5.9/bart_inst/02_installing_bart.mdx deleted file mode 100644 index f4e2ef84cbd..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/02_installing_bart.mdx +++ /dev/null @@ -1,433 +0,0 @@ ---- -title: 'Installing BART' - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/installing_bart.html" ---- - -This section will walk you through performing a fresh installation of BART on a host. Installation instructions are organized into the following platform/installer specific sections: - -- [Installing BART on a CentOS Host](#installing-bart-on-a-centos-host) -- [Installing BART on a RHEL Host](#installing-bart-on-a-rhel-host) -- [Installing BART on a RHEL/CentOS 7 PPCLE Host](#installing-bart-on-a-rhelcentos-7-ppcle-host) -- [Installing BART on a Debian or Ubuntu Host](#installing-bart-on-a-debian-or-ubuntu-host) -- [Installing BART on an SLES 12 Host](#installing-bart-on-an-sles-12-host) - -!!! Note - If you are using the pdf version of this document, using the cut/paste command to copy may result in extra spaces or carriage returns in the pasted command. If a command fails, check the command carefully for additional characters. - -## Installing BART on a CentOS Host - -The following section demonstrates installing BART on a CentOS host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. To install the repository configuration, assume superuser privileges and invoke one of the following platform-specific commands: - - On CentOS 7: - - ```text - yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - - On CentOS 8: - - ```text - dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Replace the `USERNAME:PASSWORD` in the following command with the username and password of a registered EnterpriseDB user: - - ```text - sed -i "s@:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -3. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - On CentOS 7: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - - On CentOS 8: - - ```text - dnf -y install epel-release - ``` - -4. For CentOS 8, enable the PowerTools repository to satisfy EPEL package dependencies: - - ```text - dnf config-manager --set-enabled PowerTools - ``` - -5. For CentOS 8, disable the built-in PostgreSQL module: - - ```text - dnf -qy module disable postgresql - ``` - -6. Optionally, install the `pg_basebackup` utility program using the server client package. If you do not already have the `pg_basebackup` program installed on the BART host, you can install a limited number of files that include the `pg_basebackup` program by invoking the following command: - - On CentOS 7: - - ```text - yum install edb-as-server-client - ``` - - On CentOS 8: - - ```text - dnf install edb-as-server-client - ``` - - In the above command, replace `` with the required Advanced Server version. The `pg_basebackup` version must be the same or more recent than the database server to be backed up. For example, `pg_basebackup` version 10 can be used to back up database server version 10, but cannot be used to back up database server version 11. - -7. Use the following command to install BART: - - On CentOS 7: - - ```text - yum -y install edb-bart-2.5.9 - ``` - - On CentOS 8: - - ```text - dnf -y install edb-bart-2.5.9 - ``` - - Repeat the installation process described in this section to install BART on each remote host on which an incremental backup is to be restored. - - To verify the BART installation, navigate to the `/usr/edb/bart/bin` directory and execute the following command: - - ```text - bart --version - ``` - - The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - - - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - Upon successful installation, BART is installed in the `BART_HOME` directory: - - `/usr/edb/bart` - - The installation includes the following files: - -| File Name | Location | Description | -| ------------------- | ----------------- | ------------------------------------- | -| bart | ``/bin | BART command line, executable program | -| bart-scanner | ``/bin | BART WAL scanner program | -| bart.cfg.sample | ``/etc | Sample BART configuration file | -| xlogreader_ident.so | ``/lib | Libraries supporting WAL versions | -| bart_license.txt | `` | License agreement | - -After BART is installed successfully, you need to [configure the installation](03_configuring_bart/#configuration). - -## Installing BART on a RHEL Host - -The following section demonstrates installing BART on a RHEL host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. To install the repository configuration, assume superuser privileges and invoke one of the following platform-specific commands: - - On RHEL 7: - - ```text - yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - - On RHEL 8: - - ```text - dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Replace the `USERNAME:PASSWORD` in the following command with the username and password of a registered EnterpriseDB user: - - ```text - sed -i "s@:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -3. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - On RHEL 7: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - - On RHEL 8: - - ```text - dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - ``` - -4. Enable the repository: - - On RHEL 7, enable the `optional, extras`, and `HA` repositories to satisfy EPEL package dependencies: - - ```text - subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms" - ``` - - On RHEL 8, enable the `codeready-builder-for-rhel-8-*-rpms` repository to satisfy EPEL packages dependency: - - ```text - ARCH=$( /bin/arch ) - - subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms" - ``` - -5. For RHEL 8, disable the built-in PostgreSQL module: - - ```text - dnf -qy module disable postgresql - ``` - -6. Optionally, install the `pg_basebackup` utility program using the server client package. If you do not already have the `pg_basebackup` program installed on the BART host, you can install a limited number of files that include the `pg_basebackup` program by invoking the following command: - - On RHEL 7: - - ```text - yum install edb-as-server-client - ``` - - On RHEL 8: - - ```text - dnf install edb-as-server-client - ``` - - In the above command, replace `` with the required Advanced Server version. The `pg_basebackup` version must be the same or more recent than the database server to be backed up. For example, `pg_basebackup` version 10 can be used to back up database server version 10, but cannot be used to back up database server version 11. - -7. Use the following command to install the BART: - - On RHEL 7: - - ```text - yum -y install edb-bart-2.5.9 - ``` - - On RHEL 8: - - ```text - dnf -y install edb-bart-2.5.9 - ``` - - Repeat the installation process described in this section to install BART on each remote host on which an incremental backup is to be restored. - - To verify the BART installation, navigate to the `/usr/edb/bart/bin` directory and execute the following command: - - ```text - bart --version - ``` - - The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - - - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - Upon successful installation, BART is installed in the `BART_HOME` directory: - - `/usr/edb/bart` - - The installation includes the following files: - -| File Name | Location | Description | -| ------------------- | ----------------- | ------------------------------------- | -| bart | ``/bin | BART command line, executable program | -| bart-scanner | ``/bin | BART WAL scanner program | -| bart.cfg.sample | ``/etc | Sample BART configuration file | -| xlogreader_ident.so | ``/lib | Libraries supporting WAL versions | -| bart_license.txt | `` | License agreement | - -After BART is installed successfully, you need to [configure the installation](03_configuring_bart/#configuration). - - - -## Installing BART on a RHEL/CentOS 7 PPCLE Host - -The following section demonstrates installing BART on a RHEL host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. Install Advance Toolchain: - - ```text - rpm --import https://public.dhe.ibm.com/software/server/POWER/Linux/toolchain/at/redhat/RHEL7/gpg-pubkey-6976a827-5164221b - - cat > /etc/yum.repos.d/advance-toolchain.repo <:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -4. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - -5. On RHEL 7, enable the `optional, extras`, and `HA` repositories to satisfy EPEL package dependencies: - - ```text - subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms" - ``` - -6. Invoke the following command to install BART: - - ```text - yum -y install edb-bart-2.5.9 - ``` - - - -## Installing BART on a Debian or Ubuntu Host - -Perform the following steps to install a Debian package using the EnterpriseDB apt repository. - -To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/repository-access-request). - -1. Assume the superuser privileges. - - ```text - sudo su - - ``` - -2. To configure the EnterpriseDB repository on Debian 9 and Ubuntu 18: - - ```text - sh -c 'echo "deb https://username:password@apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' - ``` - - On Debian 10: - - a. Set up the EnterpriseDB repository: - - ```text - sh -c 'echo "deb [arch=amd64] https://apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' - ``` - - b. Substitute your EnterpriseDB credentials for the `username` and `password` placeholders in the following command: - - ```text - sh -c 'echo "machine apt.enterprisedb.com login password " > /etc/apt/auth.conf.d/edb.conf' - ``` - -3. Add support to your system for secure APT repositories. - - ```text - apt-get install apt-transport-https - ``` - -4. Add the EDB signing key; When invoking the command, replace the `username` and `password` with the credentials provided by EnterpriseDB. - - ```text - wget -q -O - https://apt.enterprisedb.com/edb-deb.gpg.key | apt-key add – - ``` - -5. Update the repository metadata. - - ```text - apt-get update - ``` - -6. Install the Debian package: - - a. Contact [EDB Support](https://support.enterprisedb.com) for information about how to install the BART 2.5.9 package. - - b. Navigate to the download directory and execute the following command: - - ```text - apt-get install ./edb-bart_2.5.9-1-deb10_amd64.deb - ``` - - - -## Installing BART on an SLES 12 Host - -This section provides instructions for installing BART on an SLES 12 SP4 host using the zypper package manager. BART is supported on SLES SP4 and SP5 versions. - -1. Assume superuser privileges. - - ```text - sudo su - - ``` - -2. Use the following command to add the EDB repository to your SLES host: - - ```text - zypper addrepo https://zypp.enterprisedb.com/suse/edb-sles.repo - ``` - -3. Invoke the following command to refresh the metadata: - - ```text - zypper refresh - ``` - -4. Install `SUSEConnect` to register the host with SUSE to allow access to SUSE repositories: - - ```text - zypper install SUSEConnect - ``` - -5. Register the host with SUSE to allow access to SUSE repositories and replace `'REGISTRATION_CODE'` and `'EMAIL'` with your SUSE registration information: - - ```text - SUSEConnect -r 'REGISTRATION_CODE' -e 'EMAIL' - ``` - - ```text - SUSEConnect -p PackageHub/12.4/x86_64 - ``` - - ```text - SUSEConnect -p sle-sdk/12.4/x86_64 - ``` - -6. Install the following repository for PEM dependencies: - - ```text - zypper addrepo https://download.opensuse.org/repositories/Apache:/Modules/SLE_12_SP4/Apache:Modules.repo - ``` - -7. Refresh the metadata: - - ```text - zypper refresh - ``` - -8. Then, use the zypper utility to install BART: - - ```text - zypper install edb-bart-2.5.9 - ``` diff --git a/product_docs/docs/bart/2.5.9/bart_inst/03_configuring_bart.mdx b/product_docs/docs/bart/2.5.9/bart_inst/03_configuring_bart.mdx deleted file mode 100644 index 0201f230692..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/03_configuring_bart.mdx +++ /dev/null @@ -1,643 +0,0 @@ ---- -title: "Configuring BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/configuring_bart.html" ---- - - - -To configure BART, you must establish the BART user account, [configure the BART host](#configuring-the-bart-host), and [configure the database server](#configuring_database_server) that will be backed up. - - - -## Establishing the BART User Account - -The BART user account is an operating system user that will run the BART command line program. The BART user account must: - -- own the BART backup catalog. -- be able to run the `bart` program and the `bart-scanner` program. -- be able to establish a SSH/SCP connection to and from each database server managed by BART. - -You can optionally use the `enterprisedb` database user as the BART user account for an Advanced Server database and `postgres` database user as the BART user account for a PostgreSQL server. If you do not wish to use an existing database user as the BART user account, you must create an operating system user to assume the role. - - - -## Configuring BART and Database Server - -As stated earlier, to configure BART, you must [configure the BART host](#configuring-the-bart-host) as well as the [database server](#configuring_database_server). The following table acts as a configuration parameter reference listing the mandatory and optional parameters with default values for `[SERVER]` as well as `[BART]` sections. - -- Parameters set in the `[BART]` section are applicable to all BART managed database servers. -- Parameters set in the `Server` section are applicable only to the specific server; the `Server` parameter setting overrides the `[BART]` section setting. - -For information about configuring BART host parameters, see the [BART Host Parameter Reference](#bart) and for information about configuring the database server parameters, see the [Database Server Parameter Reference](#server). - -| **Parameter** | **Type** | **Default** | **\[SERVER]** | **\[BART]** | -| -------------------------- | --------- | ------------------------------------------------------------ | ------------- | ----------- | -| `[BART]` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `retention_policy` | Optional | `BACKUPS` | Yes | Yes | -| `wal_compression` | Optional | `Disabled` | Yes | Yes | -| `copy_wals_during_restore` | Optional | `Disabled` | Yes | Yes | -| `xlog_method` | Optional | `fetch` | Yes | Yes | -| `logfile` | Optional | `/tmp/bart.log` | N/A | Yes | -| `scanner_logfile` | Optional | `/tmp/bart_scanner.log` | N/A | Yes | -| `` | Optional | `/tmp` | N/A | Yes | -| `` | Optional | `` | N/A | Yes | -| `` | Optional | `1` | Yes | Yes | -| `` | Optional | `49152` | Yes | Yes | -| `` | Optional | `0` | Yes | Yes | -| `` | Optional | `20 seconds` | Yes | Yes | -| `` | Optional | `1` | Yes | Yes | -| `[Server Name]` | Mandatory | N/A | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `host` | Mandatory | N/A | Yes | N/A | -| `port` | Mandatory | `5444` for EPAS; `5432` for Postgres | Yes | N/A | -| `user` | Mandatory | N/A | Yes | N/A | -| `` | Optional | `BART backup catalog` | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `` | Mandatory | `enterprisedb` for EPAS

`postgres` for PostgreSQL | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `allow_incremental_backup` | Optional | `Disabled` | Yes | N/A | -| `description` | Optional | N/A | Yes | N/A | - - - -### Configuring the BART Host - -To configure the BART host, perform the following steps on the BART host as a root user: - -**Step 1.** Navigate to the `usr/edb/bart/etc` directory and make a copy of the `bart.cfg.sample` file to create the `bart.cfg` file that will contain the parameter settings. - -**Step 2.** Confirm that the Postgres `pg_basebackup` utility program is installed on the BART host. The `pg_basebackup` utility resides in the `bin` directory under your Postgres installation. - - - -**Step 3.** Ensure the `LD_LIBRARY_PATH` environment variable includes the location of the `libpq` library. If your `libpq` library does not reside in the default location (`POSTGRES_INSTALL_HOME/lib`), you must add the library path to the `LD_LIBRARY_PATH` environment variable in the BART user account’s profile (`bash_profile`) located in `/home/`: - -```text -# .bash_profile -# Get the aliases and functions -if [ -f ~/.bashrc ]; then -. ~/.bashrc -fi -# User specific environment and startup programs -export LD_LIBRARY_PATH=/usr/edb/as11/lib:$LD_LIBRARY_PATH -``` - -**Step 4.** Create the BART backup catalog and ensure the BART user account holds privileges on the BART backup catalog. In the following example, the BART configuration file specifies `/opt/backup` as the parent directory for the BART backup catalog in the `` parameter: - -```text -[BART] - -bart_host = bartuser@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -``` - -In the following example, `bartuser` is the BART user account. The example creates and sets the ownership and permissions on the BART backup catalog: - -```text -su root -mkdir /opt/backup -chown bartuser /opt/backup -chgrp bartuser /opt/backup -chmod 700 /opt/backup -``` - -If the subdirectory does not exist, BART creates a subdirectory for each database server listed in the configuration file when you invoke the `bart` command line program. - -**Step 5.** Use your choice of editor to open the BART configuration file (located in the `usr/edb/bart/etc` directory) and edit the configuration as required. You must add the mandatory parameters to the `[BART]` section. Default values may be used for optional parameters. - -The following table describes the `[BART]` host parameters. - - - -| **Parameters/Placeholder** | **Type** | **Description** | -| -------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `[BART}` | Mandatory | Identifies the global section of the configuration file. It must be named BART. | -| `bart_host` | Mandatory | Specify the bart user name and the IP address of the bart host on which the BART utility resides. You must specify it in the form of <bart_user>@<bart_host_address>. | -| `backup_path` | Mandatory | Specify the path to the file system parent directory where all BART backups are stored. | -| `pg_basebackup_path` | Mandatory | Specify the path to the `pg_basebackup` program that you installed on the BART host. For information about `pg_basebackup` version-specific restrictions, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `wal_compression` | Optional | Set this parameter to `enabled` to compress the archived WAL files in gzip format in the BART backup catalog when the `MANAGE` subcommand is invoked. By default it is set to `disabled`. The gzip compression program must be in the BART user account’s `PATH` and the WAL compression setting must not be enabled for those database servers where you need to take incremental backups. | -| `copy_wals_during_restore` | Optional | Set this parameter to `enabled` to copy the archived WAL files from the BART backup catalog to the `restore_path/archived_wals` directory prior to the database server archive recovery. Enabling this option helps you save time during the restore operation. Set this parameter to `disabled` (default) to retrieve the archived WAL files directly from the BART backup catalog during the database server archive recovery. During the restore operation, recovery settings will be saved in the `postgresql.auto.conf` file. The `restore_command` in the `postgresql.auto.conf` file will be determined by the value specified in the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked with the `-c` option, the archived WAL files are copied from the BART backup catalog to the `restore_path/archived_wals` directory, thus overriding any setting of the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked without the `-c` option, the value specified by the `copy_wals_during_restore` parameter is used. | -| `xlog_method` | Optional | Specify how the transaction log is collected during the execution of `pg_basebackup` through the `BACKUP` subcommand. Set `xlog_method` to `fetch` (default) to collect the transaction log files after the backup is completed. Set to `stream` to stream the transaction log in parallel with the full backup creation. | -| `retention_policy` | Optional | Set this parameter to determine when an active backup should be marked as `obsolete` when the `MANAGE` subcommand is used. You can specify the retention policy either in terms of number of backups or duration (days, weeks, or months). ` BACKUPS` (default), ` DAYS`, ` WEEKS`, or ` MONTHS` where `` is a positive integer. For information about managing backups using a retention policy, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `logfile` | Optional | Use this parameter to specify the path to the BART log file. The default log file location is `/tmp/bart.log`. The log file will be created the first time you invoke the `bart` command line program using the sample configuration file value. To change the default setting, you must delete the `bart.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a log file. | -| `scanner_logfile` | Optional | Use this parameter to specify the path to the XLOG/WAL scanner log file. The default location is `/tmp/bart_scanner.log`. The scanner log file will be created the first time you invoke the `bart_scanner` program using the sample configuration file value. To change the default setting, you must delete the `bart_scanner.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a WAL scanner log file. | -| `` | Optional | Specify the socket directory path where all BART sockets will be stored. The default directory is `/tmp`. While specifying the `bart_socket_directory` path, you must ensure that the directory exists and the BART user has the required access permissions to the directory. | -| `` | Optional | Specify a user-friendly BART socket file name. Using this option overrides the default BART socket name generated using MD5 checksum. You must shut down the bart-scanner before setting this option. You can view the `` in the `sockPath` field after starting the bart-scanner in the debug mode. This option helps in preventing the use of MD5 during the bart-scanner startup, thus making BART more compliant in FIPS mode. | -| `` | Optional | Specify the number of worker threads for copying blocks (for incremental backups) or data files (for full backup) from the database server to the `archive_path` when the `BACKUP` subcommand is invoked. The default value is `1`. The same set of worker threads are used for the compression operation when taking full backups in order to provide parallel, compressed backups when the `BACKUP` subcommand is specified with the `-z` or `-c` options. The compression operation does not apply to incremental backups. See [thread count](#thread_count) for more information. | -| `` | Optional | Specify the number of blocks of memory used for copying modified blocks from the database server to the `archive_path` when the `BACKUP` subcommand is invoked for incremental backups. The default value is 49152 blocks; each block is 8192 bytes. The maximum permitted value is 131072 blocks and the minimum permitted value is 1 block. Reduce the `` setting if the server runs out of memory while executing the `pg_read_binary_file()`. | -| `` | Optional | Specify the number of seconds after which the WAL scanner should initiate force scanning of the new WAL files. The default value is 0, which means no brute-force scanning will be started. After upgrading to the latest version of BART, users who have set this parameter to a non-default value may see increased CPU consumption on the part of bart-scanner. If this is an issue, consider increasing the configured value of `scan_interval` parameter, or removing the setting if it is not required. | -| `` | Optional | Specify the number of seconds to wait for MBM files before timing out; this parameter is applicable only for incremental backup. You must set the `scan_interval` to a value significantly less than the MBM scan timeout. The default value is 20 seconds. The `mbm_scan_timeout` parameter value must be greater than 0. If the value is 0 or negative, then an error will be displayed during an incremental backup. | -| `` | Optional | Specify the number of parallel worker processes required to stream the modified blocks of an incremental backup to the restore host. The default value is 1. | - - - -**Thread Count** - -If the `BACKUP` subcommand is invoked with the `--thread-count` option, then the number of worker threads specified by this option overrides any setting of the `thread_count` parameter in the BART configuration file. If the `BACKUP` subcommand is invoked without the `--thread-count` option, then the following determines the number of worker threads used: - -- The setting of the `thread_count` parameter in the server section of the BART configuration file overrides the setting of `thread_count` in the global section for that particular database server. -- If omitted in the server section, the setting of `thread_count` in the global section is used. -- If the `thread_count` parameter is not specified in either section, the default is 1. -- When taking a full backup, if the `thread count` in effect is only 1, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. - -`` will not be effective if the backup is taken on a standby server. - -If parallel backup is run with `N` number of worker threads, then it will initiate `N + 1` concurrent connections with the server. - -**Step 6** Invoke the `CHECK-CONFIG` subcommand, omitting the `-s` option to check the parameter settings in the BART configuration file. It should return the current BART version. - -```text -bart CHECK-CONFIG -``` - -The `CHECK-CONFIG` subcommand displays an error message if the required configuration is not properly set. You need to check the logfile to fix this. - - - -### Configuring the Database Server - -To configure the database server, you must: - -1. [Authorize SSH/SCP access without a password prompt](#authorizing_ssh_scp_access). -2. [Create and configure a replication database user](#setting_up_a_replication_database_user). -3. [Adding the database server to the configuration file (server section)](#adding_a_database_server). -4. [Enable WAL archiving of the server](#enabling_wal_archiving). -5. [Verify the server configuration settings](#verifying_configuration_settings). - -The following section will walk you through the configuration process. - -!!! Note - You must authorize SSH/SCP access and set up a replication database user before restarting the database server with WAL archiving enabled. - - - -**Authorizing SSH/SCP Access** - -BART uses the Secure Shell (`ssh`) and Secure Copy (`scp`) Linux utility programs to copy the backup and WAL files from the BART managed database servers to the BART host as well as to restore backups. - -- The client/server `ssh` and `scp` commands must not prompt for a password when establishing a connection with the target server (the server to which a passwordless connection is being made). -- A passwordless connection uses *authorized public keys* (public key of a client user account) to authenticate with the target server. -- You must add the public key of each client user account to the target user account’s authorized public keys list on the target server. - -For BART usage, there are two scenarios that require a passwordless SSH/SCP connection: - -- When connecting from each BART managed database server (SSH/SCP client) to the BART host (target SSH/SCP server) to support WAL archiving as implemented by the `archive_command` parameter. - - In this case, the database server user account should generate the public key file (`id_rsa.pub`) with the `ssh-keygen –t rsa` command on the database server host. - - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the BART host. The `authorized_keys` file is in the BART user account’s home directory. -- When connecting from the BART host (SSH/SCP client) to each BART managed database server (target SSH/SCP server) for taking incremental backups and for supporting restoration of the full backup, the archived WAL files, and the modified blocks, which occurs when the BART `RESTORE` subcommand is given. - - In this case, the BART user account should generate the public key file (`id_rsa.pub`) with the `ssh-keygen –t rsa` command on the BART host. - - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the database server host. The `authorized_keys` file is in the home directory of the user account that owns the directory where the database backup is to be restored. -- If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -See the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/) to view examples of creating a passwordless connection. - -**Enabling Public Key Authentication** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. - -1. In the SSH server daemon configuration file (`sshd_config`) located in the `/etc/ssh`, set the `PubkeyAuthentication` parameter to `yes`. -2. Reload the configuration file: - -```text -service sshd reload -``` - -If you get any SSH or SCP errors, examine the `/var/log/secure` log file. - -**Creating a Passwordless Connection** - -The following general instructions will walk you through generating a client’s public key file, creating the target server’s authorized public keys file, and creating a passwordless connection. - -**Step 1.** On the client system, log in as the user account that will be initiating the SSH or SCP connection. - -**Step 2.** Navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one and assign the required privileges to the user. - -**Step 3.** Generate the public key file with the following command. Accept all prompted defaults and do not specify a passphrase when prompted for one. - -```text -ssh-keygen –t rsa -``` - -The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -**Step 4.** While logged into the client where you just generated the public key file, use `SCP` to make a temporary copy of it on the target server: - -```text -scp ~/.ssh/id_rsa.pub @:tmp.pub -``` - -**Step 5.** Navigate into the target user account’s home directory and check for an existing `.ssh` subdirectory. If it does not exist, create one and assign the required privileges to the user. - -**Step 6.** Append the temporary, client’s public key file, `tmp.pub`, to the `authorized_keys` file. If an `authorized keys` file does not exist, create a new file, but do not completely replace any existing `authorized keys` file. - -```text -cat tmp.pub >> ~/.ssh/authorized_keys -``` - -Make sure the `authorized_keys` file is only accessible by the file owner and not by groups or other users. If the `authorized_keys` file does not have the required permission setting or it was newly created, change the file permissions as follows: - -```text -chmod 600 ~/.ssh/authorized_keys -``` - -**Step 7.** Delete the temporary public key file: - -```text -rm tmp.pub -``` - -Now, when logged into the client system as `user` there should be no prompt for a password when commands such as the following is given: - -```text -ssh target_user@host_address -``` - - - -**Setting up a Replication Database User** - -For each database server that is to be managed by BART, a database user must be chosen to serve as the *replication database user*. The replication database user sets the Postgres `archive_command` configuration parameter when the `INIT` subcommand in invoked and creates backups when the `BACKUP` subcommand is invoked. The replication database user must be a `superuser`. - -When executed with the PSQL client, the following PostgreSQL command creates a superuser to be the replication database user: - -`CREATE ROLE repuser WITH LOGIN SUPERUSER PASSWORD 'password';` - -The `pg_hba.conf` file must minimally permit the replication database user to have access to the database. - -In the following example, the `pg_hba.conf` file permits the `repuser` (replication database user) to have access to the `template1` database. The IP address from which `repuser` has access to `template1` database is the location of the BART host: - -**For pg_basebackup only:** If `pg_basebackup` is to be used for taking any backups (such as for standby servers), the replication database user must also be included in the `pg_hba.conf` file as a `replication` database connection as shown by the last entry in the following example. - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 repuser 192.168.2.22/32 md5 -host all enterprisedb 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -host replication repuser 192.168.2.22/32 md5 -``` - -The replication database user must be specified for the `user` parameter in the BART configuration file for the database server as shown in the following example: - -```text -[ACCTG] -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -description = "Accounting" -``` - -There must be no password prompt when connecting to the database server with the replication database user. There are several ways to permit this; one recommended method is to use a `.pgpass` file located in the BART user account’s home directory. - -For example, if `bartuser` is the BART user account, then the `.pgpass` file located in the `/home/bartuser` directory must contain the following entry: - -`192.168.2.24:5444::repuser:password` - -When `bartuser` invokes a BART backup, the password for the replication database user, `repuser`, is obtained from the `.pgpass` file of `bartuser` to connect to the database server running at `192.168.2.24` on `port 5444`. - -The `.pgpass` file must contain an entry for each BART managed database server and its corresponding replication database user and password. - - - -**Adding a Database Server to the BART Configuration File** - -To manage the backup and recovery of a database server, you must add entries to the `[SERVER]` section of the BART configuration file, which is located in `/etc` directory. - - - -*Database Server Parameter Reference* - -Set the following parameters in the \[`SERVER`] section of the BART configuration file. The parameter setting in the \[`SERVER`] section overrides the setting in the global \[`BART`] section for that particular database server. If omitted, the default value will be used. - -For each cluster serviced by BART, the following parameters are mandatory: - -```text -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -``` - -!!! Note - The port parameter setting is required only if the database server listens on a port other than the default (for example if Postgres listens on a port other than 5432). - -The following table describes the database server parameters. - - - - - - - - - -| **Parameters/Placeholder** | Type | **Description** | -| --------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `[ServerName]` | Mandatory | Specify the server name that you want to backup using BART. It is not case-sensitive when referenced with BART subcommand options. A lowercase conversion of this name is used to create a subdirectory in the BART backup catalog for storing the backups and WAL files for this database server (for eg., epas12). | -| `` | Optional | Specify a [template](#backup_name_template) for user-defined, friendly names that will be assigned to the backups of the database server. The maximum permitted length of backup name is 49 characters. The `` parameter can be overridden by the `--backup-name` option of the `BACKUP` subcommand. If this parameter is omitted from the BART configuration file, and the `--backup-name` option with a user-defined name is not specified with the `BACKUP` subcommand, then the backup can only be referenced in BART subcommands by the BART assigned, integer backup identifier. | -| `host` | Mandatory | Specify the IP address of the database server to be configured for backup. | -| `port` | Mandatory | Specify the port number identifying the database server instance (that is, the relevant database cluster) to be backed up. The default port number for EPAS is `5444` and for Postgres it is `5432`. The port parameter setting is only required if the database server listens on a port other than the default value. | -| `User` | Mandatory | Specify the replication database user name used by BART to establish the connection to the database server for full backups. See [Setting up a Replication Database User](#setting_up_a_replication_database_user) for more information. | -| `` | Optional | Specify the path where archived WAL files will be stored. The default location is the BART backup catalog (`//archived_wals`). | -| `` | Optional | When the `INIT` subcommand is used, the content and variables specified in the BART `` result in the archive command string to be generated into the `Postgres archive_command` parameter in the `postgresql.auto.conf` file. To configure the BART `` parameter, enclose the command string within single quotes ('). If you do not specify the `` parameter in the configuration file, the default setting is taken as `'scp %p %h:%a/%f'`. See [Archive Command Auto Configuration](#archive_command_auto_configuration) for information about variables. The BART `` parameter in the BART configuration file, and the Postgres `` parameter in the `postgresql.conf` file (or the `postgresql.auto.conf` file) refer to two different parameters that are to be set in different manner. | -| `` | Mandatory | Specify the Linux operating system user account that owns the database cluster. This is typically `enterprisedb` for Advanced Server database clusters installed in the Oracle compatible mode, or `postgres` for Advanced Server database clusters installed in the PostgreSQL compatible mode and PostgreSQL database clusters. | -| `` | Optional | Specify the IP address of the remote server to which a backup is to be restored. Specify this parameter in the form of `@`. `` is the user account on the target database server host that accepts a passwordless SSH/SCP login connection and owns the directory where the backup is to be restored. `` is the IP address of the remote host. For restoring a backup to a remote host or for restoring any backup where `` and the BART user account are not the same users, either this parameter must be set or it may be specified with the `-r` option with the BART `RESTORE` subcommand. | -| `` | Optional | Specify path to which tablespaces are to be restored in the format `OID = `; If the backup is to be restored to a remote host specified by the `` parameter, then the tablespace paths must exist on the remote host. | -| `allow_incremental_backups` | Optional | Set this parameter to `enabled` to enable use of the WAL scanner and permit taking incremental backups when the `BACKUP` subcommand is invoked with the `--parent` option. Set it to `disabled` (default) to disallow incremental backups and thus permit only full backups. For information about using the `BACKUP` subcommand and running the WAL scanner, please see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `Description` | Optional | Specify the description that will be used to identify the database server. | - -For information regarding the following parameters, see [configuring the BART host](#configuring-the-bart-host). - -- `retention_policy` -- `xlog_method` -- `wal_compression` -- `copy_wals_during_restore`. -- `thread_count`. -- `batch_size`. -- `scan_interval`. -- `mbm_scan_timeout`. -- `workers` - - - -**Backup Name Template** - -- The template is an alphanumeric string that may include the following variables that will be replaced with the timestamp values when the backup is taken: - - - `%year` to be replaced by 4-digit year - - `%month` to be replaced by 2-digit month - - `%day` to be replaced by 2-digit day - - `%hour` to be replaced by 2-digit hour - - `%minute` to be replaced by 2-digit minute - - `%second` to be replaced by 2-digit second - -- To include a percent sign (`%`) as a character in the backup name, specify `%%` in the template. - -- Do not enclose the template string in quotes even if you want the template to include space characters, otherwise the enclosing quotes are stored as part of the backup name. However, when referenced with the `-i` option by BART subcommands use of space characters in the backup name requires enclosing the backup name in quotes. - -The following example shows the configuration settings of three database servers: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute:%second -archive_command = 'cp %p %a/%f' -allow_incremental_backups = enabled -retention_policy = 8 BACKUPS -description = "Accounting" - -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -description = "Marketing" - -[HR] - -host = 127.0.0.1 -port = 5432 -user = postgres -cluster_owner = postgres -retention_policy = 4 DAYS -description = "Human Resources" -``` - - - -**Enabling WAL Archiving** - -WAL archiving must be enabled for the database server for which BART is to perform backup and recovery management. - -- The WAL Archiving Configuration section describes the manual WAL archiving configuration process. -- The Archive Command Auto Configuration section describes an automated WAL archiving process. - -*WAL Archiving Configuration* - -Set the following configuration parameters in the `postgresql.conf` file to enable WAL archiving - -- Set `wal_level` to `replica` or higher. -- Set `archive_mode` to `on`. -- Set the PostgreSQL `archive_command` parameter to copy the WAL files to the `archive_path`. The `archive_command` configuration parameter mentioned here is located in the `postgresql.conf` file; the PostgreSQL `archive_command` parameter is used in a different manner than the BART [archive_command](#archive_command). -- Set `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (the setting must be a minimum of 2). See [Configuring the BART host](#configuring-the-bart-host) for information about the `xlog_method` parameter. - -For detailed information about WAL archiving, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). - -The `ARCHIVE PATH` field displayed by the BART `SHOW-SERVERS` subcommand displays the full directory path where the WAL files should be copied as specified in the `archive_command` configuration parameter in the `postgresql.conf` file: - -```text --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : none -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -``` - -The parameter settings in the following example will copy the WAL files to a directory named `/opt/backup/acctg/archived_wals` on the BART host located at `192.168.2.22` as the `bartuser` user account. Using the `bartuser` account ensures that the operation will have sufficient permissions to copy to the BART backup catalog owned by `bartuser`. - -```text -archive_mode = on # allows archiving to be done - # (change requires restart) -archive_command = 'scp %p bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f' - # command to use to archive a logfile segment - # placeholders: %p = path of file to archive - # %f = file name only -... - -max_wal_senders = 1 # max number of walsender processes - # (change requires restart) -``` - -The database server must be restarted in order to initiate WAL archiving, but do not do so until you have verified that the full path of the BART backup catalog has been created by a prior BART subcommand or the archive operation will fail. - -Start the WAL scanner by executing the following command: - -```text -./bart-scanner -``` - - - -*Archive Command Auto Configuration* - -To enable WAL archiving: - -- In the `postgresql.conf` file, set the `wal_level` to `replica` or higher, `archive_mode` to `on`, and `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server as determined in the BART configuration file, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (that is, the setting must be a minimum of `2`). See [Configuring the BART host](#configuring-the-bart-host) for information on the `xlog_method` parameter. - -- Configure the Postgres `archive_command` parameter automatically with the `INIT` subcommand and restart the database server when you are ready to initiate WAL archiving. The `INIT` subcommand invokes the Postgres `ALTER SYSTEM` command to set the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME data directory`. For additional information about the `INIT` subcommand, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - - The archive command string that the `INIT` subcommand generates into the `postgresql.auto.conf` file is determined by the parameter setting of the BART `archive_command` parameter in the server section of the BART configuration file. If the BART `archive_command` parameter is not set in the server section for a given database server, the command string that is configured uses the following default format: - - `'scp %p %h:%a/%f'` - - The following table describes these variables: - -| **Variable** | **Description** | -| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `%p` | The path of the file to archive used by the Postgres archiving process. | -| `%h` | Will be replaced by the `@` as specified in the <bart_host> parameter setting. | -| `%a` | Will be replaced by the BART `archived_wals` directory as specified in the [archive path](#archive_path) parameter setting. If the `` is not specified, then the default directory is `//archived_wals`. `` is the lowercase conversion of the database server name. | -| `%f` | The archived file name used by the Postgres archiving process. | - -The placeholders `%h` and `%a` are replaced by the `INIT` subcommand when creating the archive command string. The placeholders `%p` and `%f` are not replaced by the `INIT` subcommand, but are kept as given to be used by the Postgres archiving process. - -For example, to use the default archive command format, the BART configuration file contains the following settings where the BART `archive_command` parameter is omitted from the server section for `ACCTG`: - -```text -[BART] - -bart_host= bartuser@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -description = "Accounting" -``` - -The `INIT` subcommand is invoked by BART user account `bartuser` as follows: - -```text -[bartuser@localhost ~]$ bart INIT -s acctg -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -``` - -If the BART backup catalog directory is not already complete, it will be completed. - -The resulting archive command string in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME/data directory` appears as follows: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f' -``` - -Run the `INIT` subcommand with the `-o` option to override any existing `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file. In addition, the `-o` option must be used to generate the command string if the `archive_mode` is set to off even if there are no existing settings of the `archive_command` in the `postgresql.conf` or `postgresql.auto.conf` files. - -In this example, the following BART configuration file is used with an explicit setting of the BART `archive_command` parameter: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -The `INIT` subcommand is invoked by BART user account `enterprisedb` as follows: - -```text --bash-4.1$ bart INIT -s acctg -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -``` - -The resulting Postgres `archive_command` parameter in the `postgresql.auto.conf` file appears as follows: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup/acctg/archived_wals/%f' -``` - -When the database server has been restarted, the `ARCHIVE COMMAND` field of the `SHOW-SERVERS` subcommand displays the active Postgres archive command as shown by the following example: - -```text --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : none -DISK UTILIZATION : 48.00 MB -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE SCOMMAND : `cp %p /opt/backup/acctg/archived_wals/%f` -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -``` - - - -**Verifying Configuration Settings** - -To verify the parameter settings of the database server specified, execute tthe `CHECK-CONFIG` subcommand with the `–s` option: - -```text -bart CHECK-CONFIG [ –s server_name ] -``` - -The `CHECK-CONFIG` subcommand confirms the following: - -- The `cluster_owner` parameter is set to the user account owning the database cluster directory. -- A passwordless SSH/SCP connection is set between the BART user and the user account specified by the `cluster_owner` parameter. -- The BART `user` parameter specifies a database superuser. -- The BART `user` has access to the backup directory catalog. -- The `pg_hba.conf` file contains a replication entry for the database superuser specified by the BART `user` parameter. -- The `archive_mode` parameter in the `postgresql.conf` file is enabled. -- The `archive_command` parameter in the `postgresql.auto.conf` or the `postgresql.conf` file is set. -- The `allow_incremental_backups` parameter in the BART configuration file is enabled for database servers for which incremental backups are to be taken. -- Archiving of WAL files to the `archive_path` is in process. -- The WAL scanner program is running. - -After configuring the BART host and the database server(s), you can start using BART. For information about using BART, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). diff --git a/product_docs/docs/bart/2.5.9/bart_inst/04_upgrading_bart.mdx b/product_docs/docs/bart/2.5.9/bart_inst/04_upgrading_bart.mdx deleted file mode 100644 index 4ea97b87ab6..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/04_upgrading_bart.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "Upgrading BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/upgrading_bart.html" ---- - - - -This section outlines the process of upgrading BART from an existing version to the latest version. - -**Upgrade Restrictions** - -The following restrictions apply with regard to previous BART versions. - -- You can take incremental backups using the latest version only when the parent backup (full or incremental backup) has also been taken with the latest version. -- Using the latest version, you can restore incremental backups that are taken only with the latest version of BART. However, using the latest version you can restore full backups that were taken with older versions. - - - -## Upgrading from Older Versions of BART - -Perform the following steps to upgrade from older versions of BART to the latest version: - -**Step 1:** Assume the identity of the BART user account and invoke the following command to stop the BART WAL scanner program (`bart-scanner`): - -```text -bart-scanner STOP -``` - -**Step 2:** As the `root` user, upgrade to the latest BART version with the `yum upgrade` command. - -- To upgrade the BART RPM package directly from the *EDB Yum Repository* website, specify only the package name: - - On CentOS 7: - - ```text - yum upgrade edb-bart - ``` - - You can also use a downloaded RPM package file to upgrade. To use a downloaded BART RPM package file to upgrade, use the `yum` command, specifying the complete RPM package file name: - - ```text - yum upgrade edb-bart-x.y.z rhel7.x86_64.rpm - ``` - - Where x denotes the major version of BART, and y and z denotes the minor version. - - On a Debian or Ubuntu Host: - On a Debian or Ubuntu Host: - - ```text - apt-get upgrade edb-bart - ``` - - On a SLES Host: - - ```text - zypper update edb-bart - ``` - -**Step 3:** Repeat the process described in this section to upgrade to the latest BART version on each remote hosts where an incremental backup will be restored. - -For additional information about restoration of incremental backups on remote hosts, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -**Step 4:** If the `bart --version` command returns an error stating the `PATH` is not available after switching from `root` user to another BART user account, adjust the setting of the `PATH` environment variable to include the location of the BART x.y.z executable (the `bin` subdirectory) in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - -- The BART user account on the BART host. -- The remote user account on the remote host to which incremental backups are to be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The `PATH` setting should be the same as set for BART x.y.z since all versions use `/usr/edb/bart/bin`. - -!!! Note - After upgrading to the latest BART version, you must take a new full backup of your system before performing an incremental backup. - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_inst/05_uninstalling_bart.mdx b/product_docs/docs/bart/2.5.9/bart_inst/05_uninstalling_bart.mdx deleted file mode 100644 index 8374221ef88..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/05_uninstalling_bart.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Uninstalling BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/uninstalling_bart.html" ---- - - - -This section walks you through uninstalling BART. - -## Uninstalling BART on a RHEL/CentOS Host - -To uninstall BART on a RHEL/CentOS host, assume the identity of the `root` user and invoke the following command: - -On RHEL/CentOS 7: - -```text -yum remove edb-bart -``` - -On RHEL/CentOS 8: - -```text -dnf remove edb-bart -``` - -Uninstalling BART does not delete the backup files and archived WAL files that reside in the BART backup catalog. To permanently delete the backup files and archived WAL files in the BART backup catalog (`/opt/backup`), use one of the following commands: - -- `rm –rf /opt/backup` -- BART `DELETE` subcommand - -For information about the BART `DELETE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -## Uninstalling BART on an SLES 12 Host - -To uninstall BART on an SLES 12 host, assume the identity of the `root` user and invoke the following command: - -```text -zypper remove edb-bart -``` - -## Uninstalling BART on a Debian/Ubuntu Host - -To uninstall BART on a Debian or Ubuntu host, invoke the following command: - -```text -apt-get remove edb-bart -``` diff --git a/product_docs/docs/bart/2.5.9/bart_inst/images/EDB_logo.png b/product_docs/docs/bart/2.5.9/bart_inst/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.5.9/bart_inst/images/edb.png b/product_docs/docs/bart/2.5.9/bart_inst/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.5.9/bart_inst/images/edb_logo.svg b/product_docs/docs/bart/2.5.9/bart_inst/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_inst/images/edblogo.png b/product_docs/docs/bart/2.5.9/bart_inst/images/edblogo.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/images/edblogo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.5.9/bart_inst/index.mdx b/product_docs/docs/bart/2.5.9/bart_inst/index.mdx deleted file mode 100644 index dd182be18aa..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_inst/index.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -navTitle: Installation Guide -title: "EDB Postgres Backup and Recovery Installation Guide" -legacyRedirects: - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/requirements_overview.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/index.html" ---- - -This guide provides information about how to install and configure the EDB Backup and Recovery Tool (BART) 2.5. - - - -## Requirements Overview - -### Supported Platforms and Database Versions - -- To view a complete list of platforms that EDB supports, visit the [EDB website.](https://www.enterprisedb.com/services-support/edb-supported-products-and-platforms) - -!!! Note - BART 2.5 does not support CentOS/RHEL/OEL 6.x platforms. EDB recommends migrating the EDB products running on these platforms to a supported platform. - -- BART supports the following database versions: - - - Advanced Server versions 9.6, 10, 11, and 12. - - PostgreSQL versions 9.6, 10, 11, and 12. - -### Software Requirements - -You require the following components to install BART. - -- BART Host Components - Use EDB packages to add BART host components; see [Installing BART](02_installing_bart/#installing-bart) for information about how to install these components. - -- Additional Components - In addition to the BART host components, the following components are required: - - - The [Secure Shell (SSH) server daemon and Secure Copy (SCP) client programs](03_configuring_bart/#authorizing_ssh_scp_access) must be enabled and activated on the BART host as well as on the remote database server hosts on which BART will be managing backup and recovery. - - BART uses the `pg_basebackup` utility program when taking full backups. - -### Limitation - -BART supports taking only a full backup of standby servers; it does not support taking incremental or parallel backups of standby servers. diff --git a/product_docs/docs/bart/2.5.9/bart_qs_7/images/EDB_logo.png b/product_docs/docs/bart/2.5.9/bart_qs_7/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_7/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.5.9/bart_qs_7/images/edb.png b/product_docs/docs/bart/2.5.9/bart_qs_7/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_7/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.5.9/bart_qs_7/images/edb_logo.svg b/product_docs/docs/bart/2.5.9/bart_qs_7/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_7/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_qs_7/images/image2.png b/product_docs/docs/bart/2.5.9/bart_qs_7/images/image2.png deleted file mode 100644 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_7/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.5.9/bart_qs_7/index.mdx b/product_docs/docs/bart/2.5.9/bart_qs_7/index.mdx deleted file mode 100644 index 1d54bf90879..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_7/index.mdx +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: "Quick Start Guide for RHEL/CentOS 7" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/index.html" ---- - -This tutorial demonstrates using `yum` to [install](#installing) and [configure](../bart_qs_8/#configuring) Backup and Recovery Tool (BART) 2.5 on a CentOS 7 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - -- BART is tested with the following database versions: - - - Advanced Server - 9.6, 10, 11, and 12. - - PostgreSQL - 9.6, 10, 11, and 12. - - - -**Installing BART** - -The following steps describe installing BART on CentOS 7.x OS using `yum`. - -1. Assume superuser privileges and use `yum` to create the repository configuration file: - - ```text - yum install -y https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Create an EDB user account to request credentials to the EDB repository; for a user account visit the [EnterpriseDB website](https://www.enterprisedb.com/repository-access-request). - -3. Use your choice of editor to open the repository configuration file (named `edb.repo`, located in `/etc/yum.repos.d`), and set the `enabled` parameter value to `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the username and password of a registered EnterpriseDB user. - -4. Update the cache: - - ```text - yum makecache - ``` - -5. Install an Advanced Server or PostgreSQL database server. - - To install Advanced Server, execute the following command: - - ```text - yum -y install edb-as12-server - ``` - - Use sudo to assume the identity of the `enterprisedb` database superuser - - ```text - sudo su - enterprisedb - ``` - - Create an Advanced Server cluster named `acctg` on listener port `5444`: - - ```text - /usr/edb/as12/bin/initdb -D /var/lib/edb/as12/acctg - ``` - - As the `enterprisedb` user, start the cluster: - - ```text - /usr/edb/as12/bin/pg_ctl start -D /var/lib/edb/as12/acctg - ``` - - You can check the status of the cluster with the following command: - - ```text - /usr/edb/as12/bin/pg_ctl status -D /var/lib/edb/as12/acctg - ``` - - !!! Note - The BART host server is not required to have an Advanced Server or PostgreSQL installation, but must include a copy of the Postgres `libpq` library, the `pg_basebackup` utility program, and Boost Libraries 1.53 version for CentOS 7. - -6. If you do not already have the `pg_basebackup` program installed on the BART host, you can use the following command to install a limited number of files that include the `pg_basebackup` program: - - ```text - yum install edb-as-server-client - ``` - - Where <xx> is the Advanced Server version. - -7. As a root user, execute the following command to install BART: - - ```text - yum install edb-bart - ``` - -BART (the bart program and bart-scanner) is installed in the `/usr/edb/bart/bin` directory, referred to as ``. Repeat the installation process described in this section to install BART on all remote hosts where incremental backups are to be restored. - - - -**Configuring BART** - -Before configuring BART, establish the BART user account (the operating system user) that will run the BART command line program. Then, to configure the BART host and each database server that is to be managed by BART, perform the following steps: - -1. Assume superuser privileges, create the directory that will hold the BART backup catalog, and assign its ownership (with restrictive privileges) to the BART user account: - - In this example, `bartuser` is the BART user account and `/opt/backup` is the BART backup catalog. - - ```text - su root - mkdir /opt/backup - chown bartuser /opt/backup - chgrp bartuser /opt/backup - chmod 700 /opt/backup - ``` - -2. Navigate to the `/usr/edb/bart/etc` directory and copy the `bart.cfg.sample` file to create the BART configuration file (`bart.cfg`): - - ```text - cp bart.cfg.sample bart.cfg - ``` - -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - - Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. - - In the following example, only mandatory parameters are set: - - ```text - [BART] - bart_host= bartuser@192.168.169.199 - backup_path = /opt/backup - pg_basebackup_path = /usr/edb/as12/bin/pg_basebackup - - [EPAS12] - host = 127.0.0.1 - user = repuser - cluster_owner = enterprisedb - ``` - -The following table describes only mandatory parameters: - -| **Parameters/Placeholder** | **Section** | **Description** | -| -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bart_host` | `[BART]` | Use this field to specify the BART user and the IP address of the host on which the BART utility is installed. Specify the value in the form of `@`. | -| `backup_path` | `[BART]` | Use this field to specify the path where all BART backups and archived WAL files will be stored. Ensure the BART user account holds privileges to create subdirectories and files within the location specified in the `backup_path` parameter. The default `backup_path` is BART backup catalog (`/opt/backup`). | -| `pg_basebackup_path` | `[BART]` | Use this field to specify the path to the pg_basebackup utility (`/usr/edb/as/bin/pg_basebackup`). | -| `[ServerName]` | `[ServerName]` | Specify the name of the database server to be backed up (for example, \[EPAS12]). | -| `host` | `[ServerName]` | Specify the IP address of the database server to be configured for backup. | -| `user` | `[ServerName]` | Specify the replication database user name used by BART to establish the connection to the database server for full backups. | -| `cluster_owner` | `[ServerName]` | Specify the Linux operating system user account that owns the database cluster. | - -4. As a BART user, navigate to `/usr/edb/bart/bin` and invoke the following subcommand (omitting the `-s` option) to verify the \[BART] section parameter settings: - - ```text - bart CHECK-CONFIG - ``` - -5. Authorize [SSH/SCP access](../bart_qs_8/#passwordless) between the server and the BART host without a password prompt. - -6. Create a [replication database user](../bart_qs_8/#replication) for each database server that BART manages. - -7. To enable continuous WAL archiving for any database server for which BART is to perform a backup, modify the `postgresql.conf` file, setting: - - - `wal_level` to `replica` or higher (for Postgres 9.6 or later) - - `archive_mode` to `on` - - `archive_command` (if it is not set in the `bart.cfg` file) - - `max_wal_senders` to a value high enough to leave at least one session available for the backup. - - After setting the parameters, restart the database server. - -8. To start the WAL scanner, navigate to `/usr/edb/bart/bin` as a BART user and execute the following command: - - ```text - ./bart-scanner - ``` - -9. If you are using the default `archive_command`, then navigate to `/usr/edb/bart/bin` as a BART user, run the `INIT` subcommand without the `-o` option, and restart the database server: - - ```text - bart INIT [ -s { | all } ] - ``` - - Where `` is the name of the database server to be backed up. - - If you have customized the `archive_command` setting in the `bart.cfg` file, run the `INIT` subcommand with the `-o` option to override any existing Postgresql `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file, and restart the database server. - - ```text - bart INIT [ -s { | all } ] [ -o ] - ``` - -10. To verify the database server parameter settings, as a BART user navigate to `/usr/edb/bart/bin` and invoke the `CHECK-CONFIG` subcommand with the -s option: - - ```text - bart CHECK-CONFIG [ -s ] - ``` - - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide*, available at the [EDB website](/bart/latest/bart_user/). - - - -**Creating a Passwordless Connection** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. You must create a passwordless connection between the BART host (SSH/SCP client) and the database server (target SSH/SCP server), as well as a passwordless connection between the database server (SSH/SCP client) and the BART host (target SSH/SCP server). - -1. Log in as the user account on the BART host that will be initiating the SSH or SCP connection and navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one with the required privileges. - -2. As a root user navigate to `/usr/edb/bart`, open the `/etc/ssh/sshd_config` file and set the `PubkeyAuthentication` parameter to `yes`. - -3. Reload the configuration file: - - ```text - service sshd reload - ``` - - If you get any SSH or SCP errors, examine the log file (`/var/log/secure`). - -4. As a BART user, use the following command to generate the public key file; you can accept the default responses: - - ```text - ssh-keygen -t rsa - ``` - - The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -5. Use `SCP` to make a temporary copy of the public key file on the target server: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -6. As a `target_user`, log into the target server using `ssh target_user@host_address` command and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges. - -7. Append the client’s temporary public key file, `tmp.pub`, to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - - If an `authorized_keys` file does not exist, create a new file, but be careful not to completely replace any existing `authorized_keys` file. - -8. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -9. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the BART host as a user, there should be no prompt for a password when you are connecting to the target database server: - - ```text - ssh target_user@database_server_address - ``` - -**Creating a Passwordless Connection Between the Database Server and the BART Host** - -If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). - -Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. - -1. On the database server, navigate into the target user account’s home directory to check for an existing `.ssh` subdirectory. If it does does not exist, create one in the user account’s home directory with the required privileges. - -2. As a database server user, generate the public key file: - - ```text - ssh-keygen -t rsa - ``` - -3. Create a temporary copy of the public key file: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -4. As a target user, log into the BART host and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges: - - ```text - ssh target_user@host_address - ``` - -5. Append the temporary, client’s public key file to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - -If an `authorized_keys` file does not exist, create a new file, but do not completely replace any existing `authorized_keys` file. - -6. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -7. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the database server as a user, there should be no prompt for a password when you are connecting to the BART host: - - ```text - ssh bart_user@bartip_address - ``` - - - -**Creating a Replication Database User** - -1. To create a replication database user (a superuser), connect to the database server with the psql client, and invoke the following PostgreSQL command: - - ```text - CREATE ROLE WITH LOGIN SUPERUSER PASSWORD ''; - ``` - -2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. - -3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. - -4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.5.9/bart_qs_8/images/EDB_logo.png b/product_docs/docs/bart/2.5.9/bart_qs_8/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_8/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.5.9/bart_qs_8/images/edb.png b/product_docs/docs/bart/2.5.9/bart_qs_8/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_8/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.5.9/bart_qs_8/images/edb_logo.svg b/product_docs/docs/bart/2.5.9/bart_qs_8/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_8/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_qs_8/images/image2.png b/product_docs/docs/bart/2.5.9/bart_qs_8/images/image2.png deleted file mode 100644 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_8/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.5.9/bart_qs_8/index.mdx b/product_docs/docs/bart/2.5.9/bart_qs_8/index.mdx deleted file mode 100644 index 7dc447abfb2..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_qs_8/index.mdx +++ /dev/null @@ -1,317 +0,0 @@ ---- -title: "Quick Start Guide for RHEL/CentOS 8" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/index.html" ---- - -This tutorial demonstrates using the `dnf` command to install and configure the EDB Backup and Recovery Tool (BART) 2.5 on a CentOS 8 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures and has administrative privileges on the host. - -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - -- BART is tested with the following database versions: - - - Advanced Server - 9.6, 10, 11, and 12. - - PostgreSQL - 9.6, 10, 11, and 12. - -**Installing BART** - -The following steps describe installing BART on CentOS 8.x OS. - -1. Assume superuser privileges and use `dnf` to create the repository configuration file: - - ```text - dnf install -y https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Create an EDB user account to request credentials to the EDB repository; for a user account visit the [EnterpriseDB website](https://www.enterprisedb.com/repository-access-request). - -3. Use your choice of editor to open the repository configuration file (named `edb.repo`, located in `/etc/yum.repos.d`), set the `enabled` parameter value to `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the username and password of a registered EnterpriseDB user. - -4. Update the cache: - - ```text - dnf makecache - ``` - -5. Install an Advanced Server or PostgreSQL database server. - - To install Advanced Server, execute the following command: - - ```text - dnf -y install edb-as12-server - ``` - - Use sudo to assume the identity of the `enterprisedb` database superuser: - - ```text - sudo su - enterprisedb - ``` - - Create an Advanced Server cluster named `acctg` on listener port `5444`: - - ```text - /usr/edb/as12/bin/initdb -D /var/lib/edb/as12/acctg - ``` - - As the `enterprisedb` user, start the cluster: - - ```text - /usr/edb/as12/bin/pg_ctl start -D /var/lib/edb/as12/acctg - ``` - - You can check the status of the cluster with the following command: - - ```text - /usr/edb/as12/bin/pg_ctl status -D /var/lib/edb/as12/acctg - ``` - - !!! Note - The BART host server is not required to have an Advanced Server or PostgreSQL installation, but must include a copy of the Postgres `libpq` library, the `pg_basebackup` utility program, and Boost Libraries 1.66 version for CentOS 8. - -6. If you do not already have the `pg_basebackup` program installed on the BART host, you can use the following command to install a limited number of files that include the `pg_basebackup` program: - - ```text - dnf install edb-asxx-server-client - ``` - -7. As a root user, use the following command to install the BART RPM package: - - ```text - dnf install edb-bart - ``` - -BART (the `bart` program and `bart-scanner`) is installed in the `/usr/edb/bart/bin` directory, referred to as ``. Repeat the installation process described in this section to install BART on all remote hosts where incremental backups are to be restored. - - - -**Configuring BART** - -Before configuring BART, establish the BART user account (the operating system user) to run the BART command line program. Then, to configure the BART host and each database server that is to be managed by BART, perform the following steps: - -1. Assume superuser privileges, create the directory that will hold the BART backup catalog, and assign its ownership (with restrictive privileges) to the BART user account: - - In this example, `bartuser` is the BART user account and `/opt/backup` is the BART backup catalog. - - ```text - su root - mkdir /opt/backup - chown bartuser /opt/backup - chgrp bartuser /opt/backup - chmod 700 /opt/backup - ``` - -2. Navigate to the `/usr/edb/bart/etc` directory and copy the `bart.cfg.sample` file to create the BART configuration file (`bart.cfg`): - - ```text - cp bart.cfg.sample bart.cfg - ``` - -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - - Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. - - In the following example, only mandatory parameters are set: - - ```text - [BART] - bart_host= bartuser@192.168.169.199 - backup_path = /opt/backup - pg_basebackup_path = /usr/edb/as12/bin/pg_basebackup - - [EPAS12] - host = 127.0.0.1 - user = repuser - cluster_owner = enterprisedb - ``` - -The following table describes only mandatory parameters: - -| **Parameters/Placeholder** | **Section** | **Description** | -| -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bart_host` | `[BART]` | Use this field to specify the BART user and the IP address of the host on which the BART utility is installed. Specify the value in the form of `@`. | -| `backup_path` | `[BART]` | Use this field to specify the path where all BART backups and archived WAL files will be stored. Ensure the BART user account holds privileges to create subdirectories and files within the location specified in the `backup_path` parameter. The default `backup_path` is BART backup catalog (`/opt/backup`). | -| `pg_basebackup_path` | `[BART]` | Use this field to specify the path to the pg_basebackup utility (`/usr/edb/as/bin/pg_basebackup`). | -| `[ServerName]` | `[ServerName]` | Specify the name of the database server to be backed up (for example, \[EPAS12]). | -| `host` | `[ServerName]` | Specify the IP address of the database server to be configured for backup. | -| `user` | `[ServerName]` | Specify the replication database user name used by BART to establish the connection to the database server for full backups. | -| `cluster_owner` | `[ServerName]` | Specify the Linux operating system user account that owns the database cluster. | - -4. As a BART user, navigate to `/usr/edb/bart/bin` and invoke the following subcommand (omitting the `-s` option) to verify the \[BART] section parameter settings: - - ```text - bart CHECK-CONFIG - ``` - -5. Authorize [SSH/SCP access](#passwordless) between the server and the BART host without a password prompt. - -6. Create a [replication database user](#replication) for each database server that BART manages. - -7. To enable continuous WAL archiving for any database server for which BART is to perform a backup, modify the `postgresql.conf` fil and set it to: - - - `wal_level` to `replica` or higher (for Postgres 9.6 or later) - - `archive_mode` to `on` - - `archive_command` (if it is not set in the `bart.cfg` file) - - `max_wal_senders` to a value high enough to leave at least one session available for the backup. - - After setting the parameters, restart the database server. - -8. To start the WAL scanner, navigate to `/usr/edb/bart/bin` as a BART user and execute the following command: - - ```text - ./bart-scanner - ``` - -9. If you are using the default `archive_command`, then navigate to `/usr/edb/bart/bin` as a BART user, run the `INIT` subcommand without the `-o` option, and restart the database server: - - ```text - bart INIT [ -s { | all } ] - ``` - - Where `` is the name of the database server to be backed up. - - If you have customized the `archive_command` setting in the `bart.cfg` file, run the `INIT` subcommand with the `-o` option to override any existing Postgresql `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file, and restart the database server. - - ```text - bart INIT [ -s { | all } ] [ -o ] - ``` - -10. To verify the database server parameter settings, as a BART user navigate to `/usr/edb/bart/bin` and invoke the `CHECK-CONFIG` subcommand with the -s option: - - ```text - bart CHECK-CONFIG [ -s ] - ``` - - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide* available at the [EDB website](/bart/latest/bart_user/). - - - -**Creating a Passwordless Connection** - -The following example enables SSH/SCP access on a CentOS 8.x host; similar (platform-specific) steps will apply to other platforms/versions. You must create a passwordless connection between the BART host (SSH/SCP client) and the database server (target SSH/SCP server), as well as a passwordless connection between the database server (SSH/SCP client) and the BART host (target SSH/SCP server). - -1. Log in as the user account on the BART host that will be initiating the SSH or SCP connection and navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one with the required privileges. - -2. As a root user navigate to `/usr/edb/bart`, open the `/etc/ssh/sshd_config` file and set the `PubkeyAuthentication` parameter to `yes`. - -3. Reload the configuration file: - - ```text - service sshd reload - ``` - - If you get any SSH or SCP errors, examine the log file (`/var/log/secure`). - -4. As a BART user, use the following command to generate the public key file; you can accept the default responses: - - ```text - ssh-keygen -t rsa - ``` - - The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -5. Use `SCP` to make a temporary copy of the public key file on the target server: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -6. As a `target_user`, log into the target server using `ssh target_user@host_address` command and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges. - -7. Append the temporary client’s public key file, `tmp.pub`, to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - - If an `authorized_keys` file does not exist, create a new file, but be careful not to completely replace any existing `authorized_keys` file. - -8. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -9. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the BART host as a user, there should be no prompt for a password when you are connecting to the target database server: - - ```text - ssh target_user@database_server_address - ``` - -**Creating a Passwordless Connection Between the Database Server and the BART Host** - -If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). - -Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. - -1. On the database server, navigate into the target user account’s home directory to check for an existing `.ssh` subdirectory. If it does does not exist, create one in the user account’s home directory with the required privileges. - -2. As a database server user, generate the public key file: - - ```text - ssh-keygen -t rsa - ``` - -3. Create a temporary copy of the public key file: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -4. As a target user, log into the BART host and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges: - - ```text - ssh target_user@host_address - ``` - -5. Append the client’s temporary public key file to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - -If the `authorized_keys file` does not exist, create a new file, but do not completely replace any existing `authorized_keys` file. - -6. Ensure that only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -7. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the database server as a user, there should be no prompt for a password when you are connecting to the BART host: - - ```text - ssh bart_user@bartip_address - ``` - - - -**Creating a Replication Database User** - -1. To create a replication database user (a superuser), connect to the database server with the psql client, and invoke the following PostgreSQL command: - - ```text - CREATE ROLE WITH LOGIN SUPERUSER PASSWORD ''; - ``` - -2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. - -3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. - -4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/01_backup.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/01_backup.mdx deleted file mode 100644 index 2649c676929..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/01_backup.mdx +++ /dev/null @@ -1,218 +0,0 @@ ---- -title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/backup.html" ---- - -Use the `BACKUP` subcommand to create a full or incremental backup. - -**Syntax for a Full Backup:** - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - -[ -z ] [ –c ] - -[ --backup-name ] - -[ --thread-count ] - -[ { --with-pg_basebackup | --no-pg_basebackup } ] -``` - -**Syntax for an Incremental Backup:** - -```text -bart BACKUP –s [-Fp] - -[ --parent { | } ] - -[ --backup-name ] - -[ --thread-count ] - -``` - -Before performing an incremental backup, you must take a full backup. For more details about incremental backup, refer to *Block-Level Incremental Backup* in the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `BACKUP` options: - -| Options | Description | -| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | Use this option to specify the database server to be backed up.
Specify `` to take a backup of the database server (as specified in the BART configuration file).
Specify `all` to take a backup of all servers. | -| `-F { p \| t }`
`--format { p \| t }` | Use this option to specify the backup file format.
Specify `p` option to take backup in plain text format and specify `t` option to take backup in tar format. If the `p` or `t` option is omitted, the default is tar format.
Use `p` option with the `BACKUP` subcommand when streaming is used as a backup method.
An incremental backup can only be taken in plain text format (`p`). | -| `-z`
`(--gzip)` | This option is applicable only for full backup and `tar` format. Use this option to enable gzip compression of tar files using the default compression level (typically 6). | -| `-c `
`--compress-level ` | This is applicable only for full backup and tar format. Use this option to specify the gzip compression level on the tar file output. `` is a digit from 1 through 9, with 9 being the best compression. | -| `--backup-name ` | Use this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
For detailed information about this parameter, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/).
If the option `--backup-name` is not specified and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to specify the number of worker threads to run in parallel to copy blocks for a backup.
For detailed information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | -| `--with-pg_basebackup` | This is applicable only for full backup. Use this option to specify the use of `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the `--with-pg_basebackup` option is specified with the `BACKUP` subcommand. | -| `--no-pg_basebackup` | This is applicable only for full backup. Use this option to specify that `pg_basebackup` is not to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. | -| `--parent { \| }` | Use this option to take an incremental backup. The parent backup is a backup taken prior to the incremental backup; it can be either a full backup or an incremental backup. `` is the backup identifier of a parent backup and `` is the user-defined alphanumeric name of a parent backup. | -| `--check` | This is applicable only for incremental backup. Use this option to verify if the required MBM files are present in the BART backup catalog before taking an incremental backup. However, an actual incremental backup is not taken when the `--check` option is specified.
The `--parent` option must be used along with the `--check` option. | - -**Examples** - -The following code sample demonstrates using variables with the `BACKUP` subcommand: - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year MONTH = -%month DAY = %day" -``` - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year MONTH = -%month DAY = %day %%" -``` - -```text -./bart show-backups -s ppas12 -i "test backup" -``` - -The following code sample displays the result of creating a full backup in the default tar format with gzip compression when the `BACKUP` subcommand was invoked. Note that checksums are generated for the full backup and user-defined tablespaces for the tar format backup: - -```text -[edb@localhost bin]$ ./bart BACKUP -s hr -z -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1567591909098 -INFO: creating 5 harvester threads -NOTICE: all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1567591909098 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/hr/1567591909098 -BACKUP SIZE: 13.91 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: America/New_York -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 3 -Oid Name Location -16387 test1 /home/edb/tbl1 -16388 test2 /home/edb/tbl2 -16389 test3 /home/edb/tbl3 - -START WAL LOCATION: 000000010000000000000025 -STOP WAL LOCATION: 000000010000000000000026 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-09-04 06:11:49 EDT -STOP TIME: 2019-09-04 06:11:53 EDT -TOTAL DURATION: 4 sec(s) -``` - -The following code sample displays information about the directory containing the full backup: - -```text -[edb@localhost bin]$number_of_threads> -[edb@localhost bin]$ ls -l /home/edb/bkup_new/hr/ -total 8 -drwxrwxr-x. 3 edb edb 34 Aug 27 05:57 1566899819709 -drwxrwxr-x. 3 edb edb 58 Aug 27 05:57 1566899827751 -drwxrwxr-x. 3 edb edb 4096 Sep 4 06:11 1567591909098 -drwxrwxr-x. 2 edb edb 4096 Sep 4 06:11 archived_wals -[edb@localhost bin]$ -``` - -The following code sample displays information about the creation of a full backup while streaming the transaction log. Note that the `-Fp` option must be specified with the `BACKUP` subcommand when streaming is used as a backup method. - -```text -[edb@localhost bin]$ ./bart BACKUP -s ACCTG -Fp -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1566898964200 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566898964200 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/acctg/1566898964200 -BACKUP SIZE: 46.03 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000017 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:42:44 EDT -STOP TIME: 2019-08-27 05:42:46 EDT -TOTAL DURATION: 2 sec(s) -``` - -The following code sample displays the assignment of a user-defined backup name with the `--backup-name` option: - -```text -[edb@localhost bin]$ ./bart BACKUP -s acctg --backup-name acctg_%year-%month-%day -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1566899004804 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566899004804 -BACKUP NAME: acctg_2019-08-27 -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/acctg/1566899004804 -BACKUP SIZE: 46.86 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 00000001000000000000001A -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:43:24 EDT -STOP TIME: 2019-08-27 05:43:24 EDT -TOTAL DURATION: 0 sec(s) -``` - -The following code sample displays an incremental backup taken by specifying the `--parent` option. The option `-Fp` must be specified while taking an incremental backup as incremental backup can be taken only in plain text format. - -```text -[edb@localhost bin]$ ./bart BACKUP -s hr -Fp --parent hr_full_1 --backup-name -hr_incr_1 -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: checking /home/edb/bkup_new/hr/archived_wals for MBM files from 0/20000028 to -0/22000000 -INFO: new backup identifier generated 1566899827751 -INFO: creating 5 harvester threads -NOTICE: all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566899827751 -BACKUP NAME: hr_incr_1 -BACKUP PARENT: 1566899819709 -BACKUP LOCATION: /home/edb/bkup_new/hr/1566899827751 -BACKUP SIZE: 7.19 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: America/New_York -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000022 -STOP WAL LOCATION: 000000010000000000000023 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:57:07 EDT -STOP TIME: 2019-08-27 05:57:08 EDT -TOTAL DURATION: 1 sec(s) -``` \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/02_check_config.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/02_check_config.mdx deleted file mode 100644 index 69c51d5249e..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/02_check_config.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/check_config.html" ---- - -The `CHECK-CONFIG` subcommand checks the global parameter settings as well as the database server configuration in the BART configuration file. - -The following syntax is used to check the BART configuration file global section settings. - -```text -bart CHECK-CONFIG -``` - -The following syntax is used to check the database server configuration settings. - -```text -bart CHECK-CONFIG [ –s ] -``` - -The following table describes the `CHECK-CONFIG` option: - -| Option | Description | -| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -| `-s ` `--server ` | `` is the name of the database server whose configuration parameter settings are to be checked. | - -**Example** - -The following code sample demonstrates successfully checking the BART configuration file global parameters with the `bart CHECK-CONFIG` command: - -```text -bash-4.1$ bart CHECK-CONFIG -INFO: Verifying that pg_basebackup is executable -INFO: success - -INFO: success - pg_basebackup(/usr/edb/as11/bin/pg_basebackup) returns -version 11.400000 -``` - -The following code sample demonstrates successfully checking the BART configuration file database server parameters with the `bart CHECK-CONFIG` command with the `–s` option: - -```text -[edb@localhost bin]$ ./bart check-config -s hr -INFO: Checking server hr -INFO: Verifying cluster_owner and ssh/scp connectivity -INFO: success -INFO: Verifying user, host, and replication connectivity -INFO: success -INFO: Verifying that user is a database superuser -INFO: success -INFO: Verifying that cluster_owner can read cluster data files -INFO: success -INFO: Verifying that you have permission to write to vault -INFO: success -INFO: /home/edb/bkup_new/hr -INFO: Verifying database server configuration -INFO: success -INFO: Verifying that WAL archiving is working -INFO: waiting 30 seconds for -/home/edb/bkup_new/hr/archived_wals/00000001000000000000001E -INFO: success -INFO: Verifying that bart-scanner is configured and running -INFO: success -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/03_delete.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/03_delete.mdx deleted file mode 100644 index a148c571880..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/03_delete.mdx +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/delete.html" ---- - -The `DELETE` subcommand removes the subdirectory and data files from the BART backup catalog for the specified backups along with archived WAL files. - -**Syntax:** - -```text -bart DELETE –s --i { all | [']{ | },... }['] } -[ -n ] -``` - -Note that when invoking the `DELETE` subcommand, you must specify a database server. - -For database servers under a retention policy, there are conditions where certain backups may not be deleted. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `DELETE` options: - -| Options | Description | -| -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server whose backups are to be deleted. | -| ``-i { all \| [']{ \| }',... }[`] }``

``--backupid { all \| [']{ \| }',... }[`] }`` | `` is the backup identifier of the backup to be deleted. `` is the user-defined alphanumeric name for the backup.
Multiple backup identifiers and backup names may be specified in a comma-separated list. The list must be enclosed within single quotes if there is any white space appearing before or after each comma (see [Example](#deleting_multiple_backups_with_space_characters)).
If `all` is specified, all backups and their archived WAL files for the specified database server are deleted. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to physically removing files; no files are actually deleted. | - -**Example** - -The following code sample demonstrates deleting a backup from the specified database server: - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i acctg_2019-08-27 -INFO: deleting backup 'acctg_2019-08-27' of server 'acctg' -INFO: deleting backup '1566900093665' -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -'/home/edb/bkup_new/acctg/archived_wals/000000010000000000000025' -is required, yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -``` - -After the deletion, the BART backup catalog for the database server no longer contains the corresponding directory for the deleted `backup ID`. The following code sample displays information about `archived_wals` subdirectory that no longer contains the backup WAL files: - -```text -[edb@localhost acctg]$ ls -l -total 16 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900199604 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900204377 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900209087 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:05 1566900321228 -drwxrwxr-x. 2 edb edb 6 Aug 27 06:01 archived_wals -``` - -The following code sample demonstrates deleting multiple backups from the database server. - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i `1566988095633,1566988100760, -acctg_2019-08-28` -INFO: deleting backup `1566988095633` of server `acctg` -INFO: deleting backup `1566988095633` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000037` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566988100760` of server `acctg` -INFO: deleting backup `1566988100760` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000039` is -required, yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `acctg_2019-08-28` of server `acctg` -INFO: deleting backup `1566988115512` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000003C` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost acctg]$ -[edb@localhost acctg]$ ls -l -total 8 -drwxrwxr-x. 3 edb edb 4096 Aug 28 06:28 1566988105086 -drwxrwxr-x. 3 edb edb 4096 Aug 28 06:28 1566988109477 -drwxrwxr-x. 2 edb edb 6 Aug 28 06:09 archived_wals -[edb@localhost acctg]$ -``` - - - -**Deleting Multiple Backups with Space Characters** - -The following code sample demonstrates deleting multiple backups; since there are space characters in the comma-separated list, the entire list must be enclosed within single quotes: - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i -`1566900199604,1566900204377,1566900209087`; -INFO: deleting backup `1566900199604` of server `acctg` -INFO: deleting backup `1566900199604` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000028` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566900204377` of server `acctg` -INFO: deleting backup `1566900204377` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000002A` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566900209087` of server `acctg` -INFO: deleting backup `1566900209087` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000002C` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost acctg]$ ls -l -total 4 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:05 1566900321228 -drwxrwxr-x. 2 edb edb 6 Aug 27 06:01 archived_wals -[edb@localhost acctg]$ -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/04_init.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/04_init.mdx deleted file mode 100644 index 9f8b020ac03..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/04_init.mdx +++ /dev/null @@ -1,276 +0,0 @@ ---- -title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/init.html" ---- - - - -The `INIT` subcommand is used to create the BART backup catalog directory, rebuild the BART `backupinfo` file, and set the `archive_command` in the server based on the `archive_command` setting in the `bart.cfg` file. - -**Syntax:** - -```text -bart INIT [ –s { | all } ] [ -o ] - -[ -r [ -i { | | all } ] ] - -[--no-configure] -``` - -The following table describes the `INIT` options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server to which the `INIT` actions are to be applied. If `all` is specified or if the option is omitted, actions are applied to all servers. | -| `-o`
`--override` | Overrides the existing Postgres `archive_command` configuration parameter setting in the `postgresql.conf` file or the `postgresql.auto.conf` file using the BART `archive_command` parameter in the BART configuration file. The `INIT` generated `archive command` string is written to the `postgresql.auto.conf` file. | -| `-r`
`--rebuild` | Rebuilds the `backupinfo` file located in each backup subdirectory. If `all` is specified or if the option is omitted, the `backupinfo` files of all backups for the database servers specified by the `-s` option are recreated. This option is only intended for recovering from a situation where the backupinfo file has become corrupt.
If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild that `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. | -| `-i { \| \| all }`
`--backupid { \| \| all }` | `` is an integer, backup identifier and `` is the user-defined alphanumeric name for the backup. The `-i` option can only be used with the `-r` option. | -| `--no-configure` | Prevents the `archive_command` from being set in the PostgreSQL server. | - -**Examples** - -In the following code sample, you can see that `archive_mode = off` and `archive_command` is not set. After invoking the BART `INIT` subcommand, `archive_mode` is set to `on` and `archive_command` is set: - -```text -archive_mode = off # enables archiving; off, on, or always -# (change requires restart) -archive_command = '' -# command to use to archive a logfile segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_mode/archive_command is set. Restart the PostgreSQL -server using 'pg_ctl restart' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_mode = 'on' -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample, you can see that `archive_mode = on`, and `archive_command` is not set. After invoking the `INIT` subcommand, `archive_command` is set: - -```text -archive_mode = on # enables archiving; off, on, or always -# (change requires restart) -archive_command = '' # command to use to archive a logfile segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_command is set. Reload the configuration in the -PostgreSQL server using pg_reload_conf() or 'pg_ctl reload' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample, you can see that `archive_mode = on` and `archive_command` are already set. After invoking the `INIT` subcommand, there is no change in their settings. Note that to override the existing `archive_command`, you must include the `-o` option. - -```text -archive_mode = on # enables archiving; off, on, or always -# (change requires restart) -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' # command to use -to archive a logfile segment -# placeholders: %p = path of file to archive -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_command is not set for server 'ppas11' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -``` - -In the following code sample, you can see that `archive_mode = off` and `archive_command` is already set. After invoking the `INIT` subcommand `archive_mode` is set to `on`: - -```text -archive_mode = off # enables archiving; off, on, or always -# (change requires restart) -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' # command to use -to archive a log file segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_mode/archive_command is set. Restart the PostgreSQL -server using 'pg_ctl restart' -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_mode = 'on' -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample an existing `archive command` setting is overridden by resetting the `archive_command` in the PostgreSQL server with the `archive_command = 'cp %p %a/%f'` parameter from the `bart.cfg` file: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup_edb -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -The `archive_mode` and `archive_command` parameters in the database server are set as follows: - -```text -edb=# SHOW archive_mode; -archive_mode --------------- -on -(1 row) -edb=# SHOW archive_command; -archive_command ------------------------------------------------------------------- -scp %p bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f - -(1 row) -``` - -Invoke the `INIT` subcommand with the `-o` option to override the current `archive_command` setting in the PostgreSQL server: - -```text --bash-4.1$ bart INIT -s acctg -o -INFO: setting archive_mode/archive_command for server 'acctg' -WARNING: archive_command is set. Reload the configuration in the -PostgreSQL server using pg_reload_conf() or 'pg_ctl reload' -``` - -Reload the database server configuration; a restart of the database server is not necessary to reset only the `archive_command` parameter: - -```text -[root@localhost tmp]# service ppas11 reload -``` - -The `archive_command` in the PostgreSQL server is now set as follows: - -```text -edb=# SHOW archive_command; - archive_command ------------------------------------------------ -cp %p /opt/backup_edb/acctg/archived_wals/%f -(1 row) -``` - -The new command string is written to the `postgresql.auto.conf` file: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup_edb/acctg/archived_wals/%f' -``` - -When you invoke the BART `INIT` command with the `-r` option, BART rebuilds the `backupinfo` file using the content of the backup directory for the server specified or for all servers. The BART `backupinfo` file is initially created by the `BACKUP` subcommand and contains the backup information used by BART. - -!!! Note - If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild the `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. - -The following code sample shows the `backupinfo` file location in a backup subdirectory: - -```text -[root@localhost acctg]# pwd -/opt/backup/acctg -[root@localhost acctg]# ls -l -total 4 -drwx------ 2 enterprisedb enterprisedb 38 Oct 26 10:21 1477491569966 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Oct 26 10:19 archived_wals -[root@localhost acctg]# ls -l 1477491569966 -total 61144 --rw-rw-r-- 1 enterprisedb enterprisedb 703 Oct 26 10:19 backupinfo --rw-rw-r-- 1 enterprisedb enterprisedb 62603776 Oct 26 10:19 base.tar -``` - -The following code sample displays the `backupinfo` file content: - -```text -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1477491569966 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1477491569966 -BACKUP SIZE: 59.70 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -84b3eeb1e3f7b3e75c2f689570d04f10 base.tar -TABLESPACE(s): 0 -START WAL LOCATION: 2/A5000028 (file 0000000100000002000000A5) -STOP WAL LOCATION: 2/A50000C0 (file 0000000100000002000000A5) -CHECKPOINT LOCATION: 2/A5000028 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2016-10-26 10:19:30 EDT -LABEL: pg_basebackup base backup -STOP TIME: 2016-10-26 10:19:30 EDT -TOTAL DURATION: 0 sec(s) -``` - -The following code sample displays an error message if the `backupinfo` file is missing when invoking a BART subcommand: - -```text --bash-4.2$ bart SHOW-BACKUPS -ERROR: 'backupinfo' file does not exist for backup '1477491569966' -please use 'INIT -r' to generate the file -``` - -The `backupinfo` file may be missing if the `BACKUP` subcommand did not complete successfully. - -The following code sample displays information about rebuilding the `backupinfo` file of the specified backup for database server `acctg`: - -```text --bash-4.1$ bart INIT -s acctg -r -i 1428346620427 -INFO: rebuilding BACKUPINFO for backup '1428346620427' of server 'acctg' -INFO: backup checksum: ced59b72a7846ff8fb8afb6922c70649 of base.tar -``` - -The following code sample displays information about how the `backupinfo` files of all backups are rebuilt for all database servers: - -```text --bash-4.1$ bart INIT -r - -INFO: rebuilding BACKUPINFO for backup '1428347191544' of server 'acctg' -INFO: backup checksum: 1ac5c61f055c910db314783212f2544f of base.tar -INFO: rebuilding BACKUPINFO for backup '1428346620427' of server 'acctg' -INFO: backup checksum: ced59b72a7846ff8fb8afb6922c70649 of base.tar -INFO: rebuilding BACKUPINFO for backup '1428347198335' of server 'dev' -INFO: backup checksum: a8890dd8ab7e6be5d5bc0f38028a237b of base.tar -INFO: rebuilding BACKUPINFO for backup '1428346957515' of server 'dev' -INFO: backup checksum: ea62549cf090573625d4adeb7d919700 of base.tar -``` - -The following code sample displays information about invoking `BART INIT` with the `-r - i` option: - -```text -edb@localhost bin]$ ./bart init -s ppas11 -i 1551778898392 -r -INFO: rebuilding BACKUPINFO for backup '1551778898392' of server -'ppas11' -[edb@localhost bin]$ ls /home/edb/bkup/ppas11/1551778898392/ -backupinfo backup_label base base-1.tar base-2.tar base-3.tar -base-4.tar base-5.tar base.tar -``` - -The following code sample displays information about invoking the `BART INIT` command with the `--no-configure` option. You can use the `--no-configure` option with the `INIT` subcommand to prevent the `archive_command` option from being set in the PostgreSQL server. - -```text -[edb@localhost bin]$ ./bart init -s ppas11 -o --no-configure -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/05_manage.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/05_manage.mdx deleted file mode 100644 index 75e63130a8e..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/05_manage.mdx +++ /dev/null @@ -1,228 +0,0 @@ ---- -title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/manage.html" ---- - -The `MANAGE` subcommand can be invoked to: - -- Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file. -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file. - -**Syntax:** - -```text -bart MANAGE [ –s { | all} ] -[ -l ] [ -d ] -[ -c { keep | nokeep } --i { | | all } ] -[ -n ] -``` - -To view detailed information about the `MANAGE` subcommand and retention policy management, see *the EDB Backup and Recovery User Guide*. For information about setting the `wal_compression` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide*. These guides are available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `MANAGE` options: - -| Options | Description | -| ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `-s [ \| all ]`
`--server [ \| all ]` | `` is the name of the database server to which the `MANAGE` actions are to be applied.
If `all` is specified or if the `-s` option is omitted, actions are applied to all database servers. | -| `-l`
`--list-obsolete` | Lists the backups marked as obsolete. | -| `-d`
`--delete-obsolete` | Deletes the backups marked as obsolete. This action physically deletes the backup along with its archived WAL files and any MBM files for incremental backups. | -| `-c { keep \| nokeep }`
`--change-status { keep \| nokeep }` | Specify `keep` to change the backup status to `keep` to retain the backup indefinitely.

Specify `nokeep` to change the backup status back to `active`. You can then re-evaluate and possibly mark the backup as `obsolete` (according to the retention policy) using the `MANAGE` subcommand.

The `-c` option can only be used with the `-i` option. | -| `-i { \| \| all` }

`--backupid { \| \| all` } | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified, actions are applied to all backups.
The `-i` option can only be used with the `-c` option. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to actually implementing the actions as if the operation was performed, however, no changes are actually made.
If you specify `-n` with the `-d` option, it displays which backups would be deleted, but does not actually delete the backups.
If you specify `-n` with the `-c` option, it displays the keep or nokeep action, but does not actually change the backup status.
If you specify `-n` alone with no other options or if you specify `-n` with only the `-s` option, it displays which active backups would be marked as obsolete, but does not actually change the backup status. In addition, no compression is performed on uncompressed, archived WAL files even if WAL compression is enabled for the database server. | - -**Example** - -The following code sample performs a dry run for the specified database server displaying which active backups are evaluated as obsolete according to the retention policy, but does not actually change the backup status: - -```text --bash-4.2$ bart MANAGE -s acctg -n -INFO: processing server 'acctg', backup '1482770807519' -INFO: processing server 'acctg', backup '1482770803000' -INFO: marking backup '1482770803000' as obsolete -INFO: 1 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1482770735155' -INFO: marking backup '1482770735155' as obsolete -INFO: 2 incremental(s) of backup '1482770735155' will be marked obsolete -INFO: marking incremental backup '1482770780423' as obsolete -INFO: marking incremental backup '1482770763227' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample marks active backups as obsolete according to the retention policy for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1482770807519' -INFO: processing server 'acctg', backup '1482770803000' -INFO: marking backup '1482770803000' as obsolete -INFO: 1 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1482770735155' -INFO: marking backup '1482770735155' as obsolete -INFO: 2 incremental(s) of backup '1482770735155' will be marked obsolete -INFO: marking incremental backup '1482770780423' as obsolete -INFO: marking incremental backup '1482770763227' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample lists backups marked as obsolete for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -l -SERVER NAME: acctg -BACKUP ID: 1482770803000 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:46:43 EST -BACKUP SIZE: 59.52 MB -WAL FILE(s): 1 -WAL FILE: 000000010000000100000055 -SERVER NAME: acctg -BACKUP ID: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -INCREMENTAL BACKUP(s): 2 -BACKUP ID: 1482770780423 -BACKUP PARENT: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -BACKUP ID: 1482770763227 -BACKUP PARENT: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -WAL FILE(s): 3 -WAL FILE: 000000010000000100000054 -WAL FILE: 000000010000000100000053 -WAL FILE: 000000010000000100000052 -UNUSED FILE(s): 2 -UNUSED FILE: 000000010000000100000051 -UNUSED FILE: 0000000100000001510000280000000152000000.mbm -``` - -The following code sample deletes the obsolete backups for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1482770803000' -INFO: 1 WAL file(s) will be removed -INFO: removing WAL file '000000010000000100000055' -INFO: removing obsolete backup '1482770735155' -INFO: 3 WAL file(s) will be removed -INFO: 2 incremental(s) of backup '1482770735155' will be removed -INFO: removing obsolete incremental backup '1482770780423' -INFO: removing obsolete incremental backup '1482770763227' -INFO: removing WAL file '000000010000000100000054' -INFO: removing WAL file '000000010000000100000053' -INFO: removing WAL file '000000010000000100000052' -INFO: 8 Unused file(s) will be removed -INFO: removing (unused) file '000000010000000100000056.00000028.backup' -INFO: removing (unused) file '000000010000000100000056' -INFO: removing (unused) file '000000010000000100000055.00000028.backup' -INFO: removing (unused) file '000000010000000100000054.00000028.backup' -INFO: removing (unused) file '000000010000000100000053.00000028.backup' -INFO: removing (unused) file '000000010000000100000052.00000028.backup' -INFO: removing (unused) file '000000010000000100000051' -INFO: removing (unused) file -'0000000100000001510000280000000152000000.mbm' -``` - -The following code sample changes the specified backup to keep status to retain it indefinitely: - -```text --bash-4.2$ bart MANAGE -s acctg -c keep -i 1482770807519 -INFO: changing status of backup '1482770807519' of server 'acctg' from -'active' to 'keep' -INFO: 1 WAL file(s) changed --bash-4.2$ bart SHOW-BACKUPS -s acctg -i 1482770807519 -t -SERVER NAME : acctg -BACKUP ID : 1482770807519 -BACKUP NAME : none -BACKUP PARENT : none -BACKUP STATUS : keep -BACKUP TIME : 2016-12-26 11:46:47 EST -BACKUP SIZE : 59.52 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -LAST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -``` - -The following code sample resets the specified backup to active status: - -```text --bash-4.2$ bart MANAGE -s acctg -c nokeep -i 1482770807519 -INFO: changing status of backup '1482770807519' of server 'acctg' from -'keep' to 'active' -INFO: 1 WAL file(s) changed --bash-4.2$ bart SHOW-BACKUPS -s acctg -i 1482770807519 -t -SERVER NAME : acctg -BACKUP ID : 1482770807519 -BACKUP NAME : none -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-12-26 11:46:47 EST -BACKUP SIZE : 59.52 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -LAST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -``` - -The following code sample uses the enabled `wal_compression` parameter in the BART configuration file as shown by the following: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -allow_incremental_backups = disabled -wal_compression = enabled -description = "Accounting" -``` - -When the `MANAGE` subcommand is invoked, the following message is displayed indicating that WAL file compression is performed: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: 4 WAL file(s) compressed -WARNING: 'retention_policy' is not set for server 'acctg' -``` - -The following code sample shows the archived WAL files in compressed format: - -```text --bash-4.2$ pwd -/opt/backup/acctg --bash-4.2$ ls -l archived_wals -total 160 --rw------- 1 enterprisedb enterprisedb 27089 Dec 26 12:16 -00000001000000010000005B.gz --rw------- 1 enterprisedb enterprisedb 305 Dec 26 12:17 -00000001000000010000005C.00000028.backup --rw------- 1 enterprisedb enterprisedb 27112 Dec 26 12:17 -00000001000000010000005C.gz --rw------- 1 enterprisedb enterprisedb 65995 Dec 26 12:18 -00000001000000010000005D.gz --rw------- 1 enterprisedb enterprisedb 305 Dec 26 12:18 -00000001000000010000005E.00000028.backup --rw------- 1 enterprisedb enterprisedb 27117 Dec 26 12:18 -00000001000000010000005E.gz -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/06_restore.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/06_restore.mdx deleted file mode 100644 index b0399e9d3e4..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/06_restore.mdx +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/restore.html" ---- - -The `RESTORE` subcommand restores a backup and its archived WAL files for the designated database server to the specified directory location. - -**Syntax for Restore**: - -```text -bart RESTORE –s -p -[ –i { | } ] -[ -r @ ] -[ -w ] -[ -t ] -[ { -x | -g } ] -[ -c ] -``` - -To view detailed information about the `RESTORE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -If the backup is restored to a different database cluster directory than where the original database cluster resided, then some operations dependent upon the database cluster location may fail. This happens if the supporting service scripts are not updated to reflect the new directory location of restored backup. - -For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). - -The following table describes the `RESTORE` options: - -| Options | Description | -| --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server to be restored. | -| `-p --restore-path `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | -| `-i { \| }`

`--backupid { \| }` | `backup_id` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the latest backup is restored by default. | -| `-r `

`--remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored.
`` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `remote_host` parameter for this database server is not set in the BART configuration file.
For information about the `remote_host` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). | -| `-w `
`--workers ` | `` is the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location. If the `-w` option is omitted, the default is `1` worker process.
For example, if four worker processes are specified, four receiver processes on the restore host and four streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process.
When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. | -| `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | -| `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. | -| `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. | -| `-c`

`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
The `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, then the `restore_command` in the `postgresql.conf` retrieves the archived WAL files directly from the BART backup catalog.
For information about the `copy_wals_during_restore` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | - -**Examples** - -The following code sample restores a database server(named `mktg`) to the `/opt/restore` directory up to timestamp `2015-12-15 10:47:00`: - -```text --bash-4.1$ bart RESTORE -s mktg -i 1450194208824 -p /opt/restore -t 1 -g -'2015-12-15 10:47:00' -INFO: restoring backup '1450194208824' of server 'mktg' -INFO: restoring backup to enterprisedb@192.168.2.24:/opt/restore -INFO: base backup restored -INFO: WAL file(s) will be streamed from the BART host -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: tablespace(s) restored -``` - -The following parameters are set in the `postgresql.auto.conf` file: - -```text -restore_command = 'scp -o BatchMode=yes -o PasswordAuthentication=no -enterprisedb@192.168.2.22:/opt/backup/mktg/archived_wals/%f %p' -recovery_target_time = '2015-12-15 10:47:00' -recovery_target_timeline = 1 -``` - -The following is a list of the restored files and subdirectories: - -```text -[root@localhost restore]# pwd -/opt/restore -[root@localhost restore]# ls -l -total 108 --rw------- 1 enterprisedb enterprisedb 208 Dec 15 10:43 backup_label -drwx------ 6 enterprisedb enterprisedb 4096 Dec 2 10:38 base -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 dbms_pipe -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 global -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_clog\ --rw------- 1 enterprisedb enterprisedb 4438 Dec 2 10:38 pg_hba.conf --rw------- 1 enterprisedb enterprisedb 1636 Nov 10 15:38 pg_ident.conf -drwxr-xr-x 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_log -drwx------ 4 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_multixact -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_notify -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_serial -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_snapshots -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_stat -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:43 pg_stat_tmp -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_subtrans -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 pg_tblspc -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_twophase --rw------- 1 enterprisedb enterprisedb 4 Nov 10 15:38 PG_VERSION -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 pg_xlog --rw------- 1 enterprisedb enterprisedb 23906 Dec 15 11:00 -postgresql.conf --rw-r--r-- 1 enterprisedb enterprisedb 217 Dec 15 11:00 -postgresql.auto.conf -``` - -**Example** - -The following code sample performs a `RESTORE` operation with the `copy_wals_during_restore` parameter enabled to copy the archived WAL files to the local `/archived_wals` directory: - -```text --bash-4.1$ bart RESTORE -s hr -i hr_2017-03-29T13:50 -p -/opt/restore_pg96 -t 1 -g '2017-03-29 14:01:00' -INFO: restoring backup 'hr_2017-03-29T13:50' of server 'hr' -INFO: base backup restored -INFO: copying WAL file(s) to -postgres@192.168.2.24:/opt/restore_pg96/archived_wals -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: restore completed successfully -``` - -The following parameters are set in the `postgresql.auto.conf` file: - -```text -restore_command = 'cp archived_wals/%f %p' -recovery_target_time = '2017-03-29 14:01:00' -recovery_target_timeline = 1 -``` - -The following is a list of the restored files and subdirectories: - -```text --bash-4.1$ pwd -/opt/restore_pg96 --bash-4.1$ ls -l -total 128 -drwxr-xr-x 2 postgres postgres 4096 Mar 29 14:27 archived_wals --rw------- 1 postgres postgres 206 Mar 29 13:50 backup_label -drwx------ 5 postgres postgres 4096 Mar 29 12:25 base -drwx------ 2 postgres postgres 4096 Mar 29 14:27 global -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_clog -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_commit_ts -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_dynshmem --rw------- 1 postgres postgres 4212 Mar 29 13:18 pg_hba.conf --rw------- 1 postgres postgres 1636 Mar 29 12:25 pg_ident.conf -drwxr-xr-x 2 postgres postgres 4096 Mar 29 13:45 pg_log -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_logical -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_multixact -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_notify -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_replslot -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_serial -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_snapshots -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_stat -drwx------ 2 postgres postgres 4096 Mar 29 13:50 pg_stat_tmp -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_subtrans -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_tblspc -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_twophase --rw------- 1 postgres postgres 4 Mar 29 12:25 PG_VERSION -drwx------ 3 postgres postgres 4096 Mar 29 14:27 pg_xlog --rw------- 1 postgres postgres 169 Mar 29 13:24 postgresql.auto.conf --rw-r--r-- 1 postgres postgres 21458 Mar 29 14:27 postgresql.conf --rw-r--r-- 1 postgres postgres 118 Mar 29 14:27 postgresql.auto.conf -``` \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx deleted file mode 100644 index 8ada69b5622..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_servers.html" ---- - -The `SHOW-SERVERS` subcommand displays information for the managed database servers listed in the BART configuration file. - -**Syntax:** - -```text -bart SHOW-SERVERS [ –s { | all } ] -``` - -The following table describes the `SHOW-SERVERS` option: - -| Option | Description | -| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all` }
`--server { \| all` } | `` is the name of the database server to which the `SHOW-SERVERS` actions are to be applied.
If `all` is specified or if the `-s` option is omitted, the actions are applied to all database servers. | - -**Example** - -The following code sample shows all the database servers managed by BART as returned by the `SHOW-SERVERS` subcommand: - -```text --bash-4.2$ bart SHOW-SERVERS -SERVER NAME : acctg -BACKUP FRIENDLY NAME: acctg_%year-%month-%dayT%hour:%minute -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -SERVER NAME : hr -BACKUP FRIENDLY NAME: hr_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : postgres@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Human Resources" -SERVER NAME : mktg -BACKUP FRIENDLY NAME: mktg_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : enterprisedb@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/mktg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED\ -DESCRIPTION : "Marketing" -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx deleted file mode 100644 index 03b7727add3..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_backups.html" ---- - -The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. - -**Syntax:** - -```text -bart SHOW-BACKUPS [ –s { | all } ] -[ -i { | | all } ] -[ -t ] -``` - -The following table describes the `SHOW-BACKUPS` options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all` }

`--server { \| all` } | `` is the name of the database server whose backup information is to be displayed.
If `all` is specified or if the option is omitted, the backup information for all database servers is displayed. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified or if the option is omitted, all backup information for the relevant database server is displayed. | -| `-t`
`--toggle` | Displays detailed backup information in list format. If the option is omitted, the default is a tabular format. | - -**Example** - -The following code sample shows the backup from database server `dev`: - -```text --bash-4.2$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -dev 1477579596637 dev_2016-10-27T10:46:36 none -2016-10-27 10:46:37 EDT 54.50 MB 96.00 MB 6 active -``` - -The following code sample shows detailed information using the `-t` option: - -```text --bash-4.2$ bart SHOW-BACKUPS -s dev -i 1477579596637 -t -SERVER NAME : dev -BACKUP ID : 1477579596637 -BACKUP NAME : dev_2016-10-27T10:46:36 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:46:37 EDT -BACKUP SIZE : 54.50 MB -WAL(S) SIZE : 80.00 MB -NO. OF WALS : 5 -FIRST WAL FILE : 0000000100000001000000EC -CREATION TIME : 2016-10-27 10:46:37 EDT -LAST WAL FILE : 0000000100000001000000F0 -CREATION TIME : 2016-10-27 11:22:01 EDT -``` - -The following code sample shows a listing of an incremental backup along with its parent backup: - -```text --bash-4.2$ bart SHOW-BACKUPS -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -acctg 1477580293193 acctg_2016-10-27 none -2016-10-27 10:58:13 EDT 16.45 MB 16.00 MB 1 active -acctg 1477580111358 acctg_2016-10-27 none 2016-10-27 10:55:11 EDT 59.71 -MB 16.00 MB 1 active -``` - -The following code sample shows the complete, detailed information of the incremental backup and the parent backup: - -```text --bash-4.2$ bart SHOW-BACKUPS -t -SERVER NAME : acctg -BACKUP ID : 1477580293193 -BACKUP NAME : none -BACKUP PARENT : acctg_2016-10-27 -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:58:13 EDT -BACKUP SIZE : 16.45 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 0000000100000002000000D9 -CREATION TIME : 2016-10-27 10:58:13 EDT -LAST WAL FILE : 0000000100000002000000D9 -CREATION TIME : 2016-10-27 10:58:13 EDT -SERVER NAME : acctg -BACKUP ID : 1477580111358 -BACKUP NAME : acctg_2016-10-27 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:55:11 EDT -BACKUP SIZE : 59.71 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 0000000100000002000000D8 -CREATION TIME : 2016-10-27 10:55:12 EDT -LAST WAL FILE : 0000000100000002000000D8 -CREATION TIME : 2016-10-27 10:55:12 EDT -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx deleted file mode 100644 index 973ae05dc7d..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/verify_chksum.html" ---- - -The `VERIFY-CHKSUM` subcommand verifies the MD5 checksums of the full backups and any user-defined tablespaces for the specified database server or for all database servers. The checksum is verified by comparing the current checksum of the backup against the checksum when the backup was taken. - -!!! Note - The `VERIFY-CHKSUM` subcommand is only used for tar format backups. - -**Syntax:** - -```text -bart VERIFY-CHKSUM -[ –s { | all } ] -[ -i { | | all } ] -``` - -The following table describes the `VERIFY-CHKSUM` options: - -| Options | Description | -| ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all` } | `` is the name of the database server whose tar backup checksums are to be verified.
If `all` is specified or if the `-s` option is omitted, the checksums of all tar backups are verified for all database servers. | -| `-i { \| \| all` }

`--backupid { \| \| all` } | `` is the backup identifier of a tar format full backup whose checksum is to be verified along with any user-defined tablespaces. `` is the user-defined alphanumeric name for the full backup.
If `all` is specified or if the `-i` option is omitted, the checksums of all tar backups for the relevant database server are verified. | - -**Example** - -The following code sample verifies the checksum of all tar format backups of the specified database server: - -```text --bash-4.1$ bart VERIFY-CHKSUM -s acctg -i all -SERVER NAME BACKUP ID VERIFY -acctg 1430239348243 OK -acctg 1430232284202 OK -acctg 1430232016284 OK -acctg 1430231949065 OK -acctg 1429821844271 OK -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx deleted file mode 100644 index e28e5954347..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/running_the_bart_wal_scanner.html" ---- - -The BART WAL scanner is used to process each WAL file to find and record modified blocks in a corresponding MBM file. As a BART account user, use the BART WAL scanner to invoke the `bart-scanner` program located in the `/bin` directory. - -For detailed information about the WAL scanner and its usage, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -**Syntax:** - -```text -bart-scanner -[ -d ] -[ -c ] -{ –h | --v | ---daemon | --p | - | -RELOAD | -STOP -``` - -When the `bart-scanner` program is invoked, it forks a separate process for each database server enabled with the `allow_incremental_backups` parameter. - -The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option: - -- If the `--daemon` option is specified, the WAL scanner process runs in the background. All output messages can be viewed in the BART log file. -- If the `--daemon` option is omitted, the WAL scanner process runs in the foreground. All output messages can be viewed from the terminal running the program as well as in the BART log file. - -The following table describes the `VERIFY-CHKSUM` options. - -| Options | Description | -| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on WAL scanner usage. | -| `-v` `--version` | Displays the WAL scanner version information. | -| `-d` `--debug` | Displays debugging output while executing the WAL scanner with any of its options. | -| `-c ` `--config-path ` | Specifies `` as the full directory path to a BART configuration file. Use this option if you do not want to use the default BART configuration file `/etc/bart.cfg` | -| `--daemon` | Runs the WAL scanner as a background process. | -| `-p ` `--print ` | Specifies the full directory path to an MBM file whose content is to be printed. The `archived_wals` directory as specified in the the `archive_path` parameter in the `bart.cfg` file contains the MBM files. | -| `` | Specifies the full directory path to a WAL file to be scanned. The archive path directory contains the WAL files. Use it if a WAL file in the archive path is missing its MBM file. This option is to be used for assisting the EnterpriseDB support team for debugging problems that may have been encountered. | -| `RELOAD` | Reloads the BART configuration file. The keyword `RELOAD` is case-insensitive. The `RELOAD` option is useful if you make changes to the configuration file after the WAL scanner has been started. It will reload the configuration file and adjust the WAL scanners accordingly. For example, if a server section allowing incremental backups is removed from the BART configuration file, then the process attached to that server will stop. Similarly, if a server allowing incremental backups is added, a new WAL scanner process will be launched to scan the WAL files of that server. | -| `STOP` | Stops the WAL scanner. The keyword `STOP` is not case-sensitive. | - -**Example** - -The following code sample demonstrates starting the WAL scanner to run interactively. The WAL scanner begins scanning existing WAL files in the archive path that have not yet been scanned (that is, there is no corresponding MBM file for the WAL file): - -```text --bash-4.2$ bart-scanner -INFO: process created for server 'acctg', pid = 5287 -INFO: going to parse backlog of WALs, if any. -INFO: WAL file to be processed: 0000000100000000000000ED -INFO: WAL file to be processed: 0000000100000000000000EE -INFO: WAL file to be processed: 0000000100000000000000EF -INFO: WAL file to be processed: 0000000100000000000000F0 -INFO: WAL file to be processed: 0000000100000000000000F1 -``` - -The following code sample is the content of the archive path showing the MBM files created for the WAL files. (The user name and group name of the files have been removed from the example to list the WAL files and MBM files in a more readable manner): - -```text -[root@localhost archived_wals]# pwd -/opt/backup/acctg/archived_wals -[root@localhost archived_wals]# ls -l -total 81944 --rw------- 1 ... ... 16777216 Dec 20 09:10 0000000100000000000000ED --rw------- 1 ... ... 16777216 Dec 20 09:06 0000000100000000000000EE --rw------- 1 ... ... 16777216 Dec 20 09:11 0000000100000000000000EF --rw------- 1 ... ... 16777216 Dec 20 09:15 0000000100000000000000F0 --rw------- 1 ... ... 16777216 Dec 20 09:16 0000000100000000000000F1 --rw------- 1 ... ... 305 Dec 20 09:16 0000000100000000000000F1.00000028.backup --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000ED00002800000000EE000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000EE00002800000000EF000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000EF00002800000000F0000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000F000002800000000F1000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000F100002800000000F2000000.mbm -``` - -To stop the interactively running WAL scanner, either enter `ctrl-C` at the terminal running the WAL scanner or invoke the `bart-scanner` program from another terminal with the `STOP` option: - -```text --bash-4.2$ bart-scanner STOP --bash-4.2$ -``` - -The terminal on which the WAL scanner was running interactively appears as follows after it has been stopped: - -```text --bash-4.2$ bart-scanner -INFO: process created for server 'acctg', pid = 5287 -INFO: going to parse backlog of WALs, if any. -INFO: WAL file to be processed: 0000000100000000000000ED -INFO: WAL file to be processed: 0000000100000000000000EE -INFO: WAL file to be processed: 0000000100000000000000EF -INFO: WAL file to be processed: 0000000100000000000000F0 -INFO: WAL file to be processed: 0000000100000000000000F1 -INFO: bart-scanner stopped --bash-4.2$ -``` - -The following code sample demonstrates invoking the WAL scanner to run as a background process with the `--daemon` option: - -```text --bash-4.2$ bart-scanner --daemon --bash-4.2$ -``` - -The WAL scanner runs as a background process. There is also a separate background process for each database server that has been enabled for WAL scanning with the `allow_incremental_backups` parameter in the BART configuration file: - -```text --bash-4.2$ ps -ef | grep bart - enterpr+ 4340 1 0 09:48 ? 00:00:00 bart-scanner --daemon - enterpr+ 4341 4340 0 09:48 ? 00:00:00 bart-scanner --daemon - enterpr+ 4415 3673 0 09:50 pts/0 00:00:00 grep --color=auto bart -``` - -To stop the WAL scanner processes, invoke the WAL scanner with the `STOP` option: - -```text --bash-4.2$ bart-scanner STOP --bash-4.2$ -``` - -The following command demonstrates scanning an individual WAL file: - -```text --bash-4.2$ bart-scanner /opt/backup/acctg/archived_wals/0000000100000000000000FF --bash-4.2$ -``` - -To print the content of an MBM file for assisting the EnterpriseDB support team for debugging problems that may have been encountered, use the `-p` option to specify the file as shown in the following code sample: - -```text --bash-4.2$ bart-scanner -p -/opt/backup/acctg/archived_wals/0000000100000000FF0000280000000100000000.mbm - -Header: -Version: 1.0:90500:1.2.0 -Scan Start: 2016-12-20 10:02:11 EST, Scan End: 2016-12-20 10:02:11 EST, Diff: 0 sec(s) -Start LSN: ff000028, End LSN: 100000000, TLI: 1 -flags: 0, Check Sum: f9cfe66ae2569894d6746b61503a767d - -Path: base/14845/16384 -NodeTag: BLOCK_CHANGE -Relation: relPath base/14845/16384, isTSNode 0, Blocks -*............................................................................. -First modified block: 0 -Total modified blocks: 1 - -Path: base/14845/16391 -NodeTag: BLOCK_CHANGE -Relation: relPath base/14845/16391, isTSNode 0, Blocks -*.............................................................................. -First modified block: 0 -Total modified blocks: 1 -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/index.mdx b/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/index.mdx deleted file mode 100644 index 20c71192ef2..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/01_bart_subcommands_examples/index.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: "BART Subcommand Syntax and Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/bart_subcommands_examples.html" ---- - - - -This section briefly describes each BART subcommand and provides an example. - -**Invoking BART** - -BART subcommands are invoked at the Linux command line as a BART user. You can invoke the `bart` program (located in the `/bin` directory) with the desired options to manage your BART installation. - -The following examples demonstrate ways of invoking BART. In these examples, the BART user account is named `bartuser`. - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ ./bart SHOW-SERVERS -``` - -To run BART from any current working directory: - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ bart SHOW-SERVERS -``` - -**Syntax for invoking BART** - -```text -bart [ ]... [ ] []... -``` - -You can use either abbreviated or long option forms on the command line (for example `-h` or `--help`). - -**General Options** - -You can specify the following general options with `bart`. - -`-h` or (`--help`) - -- Displays general syntax and information about BART usage. -- All subcommands support a help option (`-h, --help`). If the help option is specified, information is displayed regarding that particular subcommand. The subcommand, itself, is not executed. - -The following code sample displays the result of invoking the `--help` option for the `BACKUP` subcommand: - -```text --bash-4.2$ bart BACKUP --help -bart: backup and recovery tool - -Usage: -bart BACKUP [OPTION]... - -Options: --h, --help Show this help message and exit --s, --server Name of the server or 'all' (full backups only) to specify all servers --F, --format=p|t Backup output format (tar (default) or plain) --z, --gzip Enables gzip compression of tar files --c, --compress-level Specifies the compression level (1 through 9, 9 being - best compression) ---backup-name Specify a friendly name for the current backup ---parent Specify parent backup for incremental backup ---check Verify checksum of required mbm files -``` - -`-v` (or `--version`) - -The following code sample displays information returned by the `bart --version` subcommand: - -```text -[edb@localhost bin]$ bart --version -bart (EnterpriseDB) 2.5.2 -[edb@localhost bin]$ -``` - -`-d` (or `--debug`) - -The following code sample displays debugging output returned by the `bart MANAGE` subcommand: - -```text --bash-4.1$ bart -d MANAGE -n -DEBUG: Server: acctg, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -259200 (secs) ==> 72 hour(s) -DEBUG: Server: dev, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -1814400 (secs) ==> 504 hour(s) -DEBUG: Server: hr, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -7776000 (secs) ==> 2160 hour(s) -``` - -`-c` (or `--config-path) ` - -The following code sample demonstrates using the `-c` option to specify a non-default configuration file name and installation location: - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ bart -c /home/bartuser/bart.cfg SHOW-SERVERS -``` - -
- -backup check_config delete init manage restore show_servers show_backups verify_chksum running_the_bart_wal_scanner - -
diff --git a/product_docs/docs/bart/2.5.9/bart_ref/02_additional_examples.mdx b/product_docs/docs/bart/2.5.9/bart_ref/02_additional_examples.mdx deleted file mode 100644 index 38a519f727d..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/02_additional_examples.mdx +++ /dev/null @@ -1,1473 +0,0 @@ ---- -title: "Additional Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/additional_examples.html" ---- - - - -This section lists examples of the following BART operations. - -- Restoring a database cluster with tablespaces. -- Restoring an incremental backup. -- Managing backups. -- Managing incremental backups. - -## Restoring a Database Cluster with Tablespaces - -The following code sample illustrates taking a backup and restoring a database cluster on a remote host containing tablespaces. For detailed information regarding using tablespaces, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -On an Advanced Server database running on a remote host, the following tablespaces are created for use by two tables: - -```text -edb=# CREATE TABLESPACE tblspc_1 LOCATION '/mnt/tablespace_1'; -CREATE TABLESPACE -edb=# CREATE TABLESPACE tblspc_2 LOCATION '/mnt/tablespace_2'; -CREATE TABLESPACE -edb=# \db - List of tablespaces -Name | Owner | Location -------------+-----------------+------------------- -pg_default | enterprisedb | -pg_global | enterprisedb | -tblspc_1 | enterprisedb | /mnt/tablespace_1 -tblspc_2 | enterprisedb | /mnt/tablespace_2 -(4 rows) - -edb=# CREATE TABLE tbl_tblspc_1 (c1 TEXT) TABLESPACE tblspc_1; -CREATE TABLE -edb=# CREATE TABLE tbl_tblspc_2 (c1 TEXT) TABLESPACE tblspc_2; -CREATE TABLE -edb=# \d tbl_tblspc_1 -Table "enterprisedb.tbl_tblspc_1" -Column | Type | Modifiers --------+------+----------- -c1 | text | -Tablespace: "tblspc_1" - -edb=# \d tbl_tblspc_2 -Table "enterprisedb.tbl_tblspc_2" -Column | Type | Modifiers --------+------+----------- -c1 | text | -Tablespace: "tblspc_2" -``` - -The following code sample shows the OIDs assigned to the tablespaces and the symbolic links to the tablespace directories: - -```text --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS/data/pg_tblspc --bash-4.1$ ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Nov 16 16:17 16587 ->/mnt/tablespace_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Nov 16 16:17 16588 ->/mnt/tablespace_2 -``` - -The BART configuration file contains the following settings. Note that the `tablespace_path` parameter does not have to be set at this point. - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -tablespace_path = -description = "Accounting" -``` - -After the necessary configuration steps are performed to ensure BART manages the remote database server, a full backup is taken as shown in the following code sample: - -```text --bash-4.1$ bart BACKUP -s acctg - -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1447709811516' -54521/54521 kB (100%), 3/3 tablespaces - -INFO: backup completed successfully -INFO: backup checksum: 594f69fe7d26af991d4173d3823e174f of 16587.tar -INFO: backup checksum: 7a5507567729a21c98a15c948ff6c015 of base.tar -INFO: backup checksum: ae8c62604c409635c9d9e82b29cc0399 of 16588.tar -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1447709811516 -BACKUP NAME: none -BACKUP LOCATION: /opt/backup/acctg/1447709811516 -BACKUP SIZE: 53.25 MB -BACKUP FORMAT: tar -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 3 -ChkSum File -594f69fe7d26af991d4173d3823e174f 16587.tar -7a5507567729a21c98a15c948ff6c015 base.tar -ae8c62604c409635c9d9e82b29cc0399 16588.tar - -TABLESPACE(s): 2 -Oid Name Location -16587 tblspc_1 /mnt/tablespace_1 -16588 tblspc_2 /mnt/tablespace_2 -START WAL LOCATION: 00000001000000000000000F -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2015-11-16 16:36:51 EST -STOP TIME: 2015-11-16 16:36:52 EST -TOTAL DURATION: 1 sec(s) -``` - -Note that in the output from the preceding example, checksums are generated for the tablespaces as well as the full backup. - -Within the backup subdirectory `1447709811516` of the BART backup catalog, the tablespace data is stored with file names `16587.tar.gz` and `16588.tar.gz` as shown below: - -```text --bash-4.1$ pwd -/opt/backup/acctg --bash-4.1$ ls -l -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 16:36 1447709811516 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 16:43 archived_wals --bash-4.1$ ls -l 1447709811516 -total 54536 --rw-rw-r-- 1 enterprisedb enterprisedb 19968 Nov 16 16:36 16587.tar --rw-rw-r-- 1 enterprisedb enterprisedb 19968 Nov 16 16:36 16588.tar --rw-rw-r-- 1 enterprisedb enterprisedb 949 Nov 16 17:05 backupinfo --rw-rw-r-- 1 enterprisedb enterprisedb 55792640 Nov 16 16:36 base.tar -``` - -When you are ready to restore the backup, in addition to creating the directory to which the main database cluster is to be restored, you must prepare the directories to which the tablespaces are to be restored. - -On the remote host, directories `/opt/restore_tblspc_1` and `/opt/restore_tblspc_2` are created and assigned the proper ownership and permissions as shown by the following example. The main database cluster is to be restored to `/opt/restore`. - -```text -[root@localhost opt]# mkdir restore_tblspc_1 -[root@localhost opt]# chown enterprisedb restore_tblspc_1 -[root@localhost opt]# chgrp enterprisedb restore_tblspc_1 -[root@localhost opt]# chmod 700 restore_tblspc_1 - -[root@localhost opt]# mkdir restore_tblspc_2 -[root@localhost opt]# chown enterprisedb restore_tblspc_2 -[root@localhost opt]# chgrp enterprisedb restore_tblspc_2 -[root@localhost opt]# chmod 700 restore_tblspc_2 -[root@localhost opt]# ls -l -total 20 -drwxr-xr-x 3 root daemon 4096 Nov 10 15:38 PostgresPlus -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:40 restore -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:40 -restore_tblspc_1 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:41 -restore_tblspc_2 -drwxr-xr-x. 2 root root 4096 Nov 22 2013 rh -``` - -Set the `tablespace_path` parameter in the BART configuration file to specify the tablespace directories. The remote host user and IP address are specified by the `remote_host` configuration parameter. - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -tablespace_path = -16587=/opt/restore_tblspc_1;16588=/opt/restore_tblspc_2 - -description = "Accounting" -``` - -The following code sample demonstrates invoking the `RESTORE` subcommand: - -```text --bash-4.1$ bart RESTORE -s acctg -i 1447709811516 -p /opt/restore -INFO: restoring backup '1447709811516' of server 'acctg' -INFO: restoring backup to enterprisedb@192.168.2.24:/opt/restore -INFO: base backup restored -INFO: archiving is disabled -INFO: tablespace(s) restored -``` - -The following code sample shows the restored full backup (including the restored tablespaces): - -```text -bash-4.1$ pwd -/opt --bash-4.1$ ls -l restore -total 104 --rw------- 1 enterprisedb enterprisedb 206 Nov 16 16:36 backup_label.old -drwx------ 6 enterprisedb enterprisedb 4096 Nov 10 15:38 base -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:46 global -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_clog --rw------- 1 enterprisedb enterprisedb 4438 Nov 10 16:23 pg_hba.conf --rw------- 1 enterprisedb enterprisedb 1636 Nov 10 15:38 pg_ident.conf -drwxr-xr-x 2 enterprisedb enterprisedb 4096 Nov 16 17:45 pg_log -drwx------ 4 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_multixact -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:45 pg_notify -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_serial -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_snapshots -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_stat -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_stat_tmp -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_subtrans -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:42 pg_tblspc -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_twophase --rw------- 1 enterprisedb enterprisedb 4 Nov 10 15:38 PG_VERSION -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_xlog --rw------- 1 enterprisedb enterprisedb 23906 Nov 16 17:42 postgresql.conf --rw------- 1 enterprisedb enterprisedb 61 Nov 16 17:45 postmaster.opts --bash-4.1$ --bash-4.1$ ls -l restore_tblspc_1 -total 4 -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 16:18 -PG_9.6_201306121 --bash-4.1$ ls -l restore_tblspc_2 -total 4 -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 16:18 -PG_9.6_201306121 -``` - -The symbolic links in the `pg_tblspc` subdirectory point to the restored directory location: - -```text -bash-4.1$ pwd -/opt/restore/pg_tblspc --bash-4.1$ ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 21 Nov 16 17:42 16587 -> -/opt/restore_tblspc_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 21 Nov 16 17:42 16588 -> -/opt/restore_tblspc_2 -``` - -`psql` queries also show the restored tablespaces: - -```text -edb=# \db - - List of tablespaces -Name | Owner | Location -------------+--------------+----------------------- -pg_default | enterprisedb | -pg_global | enterprisedb | -tblspc_1 | enterprisedb | /opt/restore_tblspc_1 -tblspc_2 | enterprisedb | /opt/restore_tblspc_2 -``` - -## Restoring an Incremental Backup - -Restoring an incremental backup may require additional setup steps depending upon the host on which the incremental backup is to be restored. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -This section provides an example of creating backup chains and then restoring an incremental backup. - -**Creating a Backup Chain** - -A *backup chain* is the set of backups consisting of a full backup and all of its successive incremental backups. Tracing back on the parent backups of all incremental backups in the chain eventually leads back to that single, full backup. - -In the following example, the `allow_incremental_backups` parameter is set to `enabled` in the BART configuration file to permit incremental backups on the listed database server: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.27 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -allow_incremental_backups = enabled -description = "Accounting" -``` - -After the database server has been started with WAL archiving enabled to the BART backup catalog, the WAL scanner is started: - -```text --bash-4.2$ bart-scanner --daemon -``` - -First, a full backup is taken. - -```text --bash-4.2$ bart BACKUP -s acctg --backup-name full_1 -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1490649204327'\ -63364/63364 kB (100%), 1/1 tablespace -INFO: backup completed successfully -INFO: backup checksum: aae27d4a7c09dffc82f423221154db7e of base.tar -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490649204327 -BACKUP NAME: full_1 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1490649204327 -BACKUP SIZE: 61.88 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -aae27d4a7c09dffc82f423221154db7e base.tar -TABLESPACE(s): 0 -START WAL LOCATION: 00000001000000000000000E -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2017-03-27 17:13:24 EDT -STOP TIME: 2017-03-27 17:13:25 EDT -TOTAL DURATION: 1 sec(s) -``` - -A series of incremental backups are taken. The first incremental backup specifies the full backup as the parent. Each successive incremental backup then uses the preceding incremental backup as its parent. - -```text --bash-4.2$ bart BACKUP -s acctg -F p --parent full_1 --backup-name -incr_1-a -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649255649 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490649255649 -BACKUP NAME: incr_1-a -BACKUP PARENT: 1490649204327 -BACKUP LOCATION: /opt/backup/acctg/1490649255649 -BACKUP SIZE: 16.56 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000010 -STOP WAL LOCATION: 000000010000000000000010 -BACKUP METHOD: pg_start_backup -BACKUP FROM: master -START TIME: 2017-03-27 17:14:15 EDT -STOP TIME: 2017-03-27 17:14:16 EDT -TOTAL DURATION: 1 sec(s) --bash-4.2$ bart BACKUP -s acctg -F p --parent incr_1-a --backup-name -incr_1-b -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649336845 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -. -. -. --bash-4.2$ bart BACKUP -s acctg -F p --parent incr_1-b --backup-name -incr_1-c -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649414316 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -. -. -. -``` - -The following output of the `SHOW-BACKUPS` subcommand lists the backup chain, which are backups `full_1, incr_1-a, incr_1-b, and incr_1-c`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -For the `full backup full_1`, the `BACKUP PARENT` field contains `none`. For each incremental backup, the `BACKUP PARENT` field contains the backup identifier or name of its parent backup. - -A second backup chain is created in the same manner with the `BACKUP` subcommand. The following example shows the addition of the resulting, second backup chain consisting of full backup `full_2` and incremental backups `incr_2-a` and `incr_2-b`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649605607 incr_2-b incr_2-a 2017-03-27 17:20:06 ... -acctg 1490649587702 incr_2-a full_2 2017-03-27 17:19:48 ... -acctg 1490649528633 full_2 none 2017-03-27 17:18:49 ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -The following additional incremental backups starting with `incr_1-b-1`, which designates `incr_1-b` as the parent, results in the forking from that backup into a second line of backups in the chain consisting of `full_1, incr_1-a, incr_1-b, incr_1-b-1, incr_1-b-2`, and `incr_1-b-3` as shown in the following list: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649791430 incr_1-b-3 incr_1-b-2 2017-03-27 17:23:12 ... -acctg 1490649763929 incr_1-b-2 incr_1-b-1 2017-03-27 17:22:44 ... -acctg 1490649731672 incr_1-b-1 incr_1-b 2017-03-27 17:22:12 ... -acctg 1490649605607 incr_2-b incr_2-a 2017-03-27 17:20:06 ... -acctg 1490649587702 incr_2-a full_2 2017-03-27 17:19:48 ... -acctg 1490649528633 full_2 none 2017-03-27 17:18:49 ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -**Restoring an Incremental Backup** - -Restoring an incremental backup is done with the `RESTORE` subcommand in the same manner as for restoring a full backup. Specify the backup identifier or backup name of the incremental backup to be restored as shown in the following example. - -```text --bash-4.2$ bart RESTORE -s acctg -p /opt/restore -i incr_1-b -INFO: restoring incremental backup 'incr_1-b' of server 'acctg' -INFO: base backup restored -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: incremental restore completed successfully -``` - -Restoring incremental backup `incr_1-b` as shown by the preceding example results in the restoration of full backup `full_1`, then incremental backups `incr_1-a` and finally, `incr_1-b`. - -## Managing Backups - -This section illustrates evaluating, marking, and deleting backups using the `MANAGE` subcommand using a redundancy retention policy and a recovery window retention policy. For detailed information about the `MANAGE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - - -### Using a Redundancy Retention Policy - -The following code sample uses a redundancy retention policy to evaluate, mark, and delete backups as shown by the following server configuration: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The following list is the set of backups. Note that the last backup in the list has been marked as `keep`. - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 active -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -Invoke the `MANAGE` subcommand with the `-n` option to perform a dry run to observe which active backups would be changed to obsolete according to the retention policy as shown in the following code sample: - -```text --bash-4.1$ bart MANAGE -s acctg -n -INFO: processing server 'acctg', backup '1428768344061' -INFO: processing server 'acctg', backup '1428684537299' -INFO: processing server 'acctg', backup '1428589759899' -INFO: processing server 'acctg', backup '1428502049836' -INFO: marking backup '1428502049836' as obsolete -INFO: 6 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428422324880' -INFO: marking backup '1428422324880' as obsolete -INFO: 2 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428355371389' -``` - -The dry run shows that backups `1428502049836` and `1428422324880` would be marked as `obsolete`. - -!!! Note - A dry run does not change the backup status. The two backups that would be considered obsolete are still marked as `active`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 active -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -Invoke the `MANAGE` subcommand omitting the `-n` option to change and mark the status of the backups as `obsolete`: - -```text --bash-4.1$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1428768344061' -INFO: processing server 'acctg', backup '1428684537299' -INFO: processing server 'acctg', backup '1428589759899' -INFO: processing server 'acctg', backup '1428502049836' -INFO: marking backup '1428502049836' as obsolete -INFO: 6 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428422324880' -INFO: marking backup '1428422324880' as obsolete -INFO: 2 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428355371389' -``` - -The obsolete backups can be observed in a number of ways. Use the `MANAGE` subcommand with the `-l` option to list the `obsolete` backups: - -```text --bash-4.1$ bart MANAGE -s acctg -l -INFO: 6 WAL file(s) will be removed -SERVER NAME: acctg -BACKUP ID: 1428502049836 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-08 10:07:30 EDT -BACKUP SIZE: 55.25 MB -WAL FILE(s): 6 -WAL FILE: 000000010000000100000003 -WAL FILE: 000000010000000100000002 -WAL FILE: 000000010000000100000001 -WAL FILE: 000000010000000100000000 -WAL FILE: 0000000100000000000000E3 -WAL FILE: 0000000100000000000000E2 -INFO: 2 WAL file(s) will be removed -SERVER NAME: acctg -BACKUP ID: 1428422324880 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-07 11:58:45 EDT -BACKUP SIZE: 54.53 MB -WAL FILE(s): 2 -WAL FILE: 0000000100000000000000E1 -WAL FILE: 0000000100000000000000E0 -``` - -The `STATUS` field of the `SHOW-BACKUPS` subcommand displays the current status: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 obsolete -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 obsolete -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -The details of an individual backup can be displayed using the `SHOW-BACKUPS` subcommand with the `-t` option. Note the status in the `BACKUP STATUS` field. - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -i 1428502049836 -t -SERVER NAME : acctg -BACKUP ID : 1428502049836 -BACKUP NAME : none -BACKUP STATUS : obsolete -BACKUP TIME : 2015-04-08 10:07:30 EDT -BACKUP SIZE : 55.25 MB -WAL(S) SIZE : 96.00 MB -NO. OF WALS : 6 -FIRST WAL FILE : 0000000100000000000000E2 -CREATION TIME : 2015-04-08 10:07:30 EDT -LAST WAL FILE : 000000010000000100000003 -CREATION TIME : 2015-04-09 10:25:46 EDT -``` - -Use the `MANAGE` subcommand with the `-d` option to physically delete the `obsolete` backups including the unneeded WAL files. - -```text --bash-4.1$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1428502049836' -INFO: 6 WAL file(s) will be removed -INFO: removing WAL file '000000010000000100000003' -INFO: removing WAL file '000000010000000100000002' -INFO: removing WAL file '000000010000000100000001' -INFO: removing WAL file '000000010000000100000000' -INFO: removing WAL file '0000000100000000000000E3' -INFO: removing WAL file '0000000100000000000000E2' -INFO: removing obsolete backup '1428422324880' -INFO: 2 WAL file(s) will be removed -INFO: removing WAL file '0000000100000000000000E1' -INFO: removing WAL file '0000000100000000000000E0' -``` - -The `SHOW-BACKUPS` subcommand now displays the remaining backups marked as `active` or `keep`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - - - -### Using a Recovery Window Retention Policy - -This section illustrates the evaluation, marking, and deletion of backup using a recovery window retention policy. To use the recovery window retention policy, set the `retention_policy` parameter to the desired length of time for the recovery window. - -This section provides examples of the following: - -- How to view the calculated recovery window. -- How to evaluate, mark, and delete backup using a recovery window retention policy. - -#### Viewing the Recovery Window - -You can view the actual, calculated recovery window by invoking any of the following subcommands: - -- `MANAGE` subcommand in debug mode (along with the `-n` option). -- `SHOW-SERVERS` subcommand. - -##### Viewing the Recovery Window Using the Manage Subcommand - -When invoking BART in debug mode with the `MANAGE` subcommand and the `-n` option, the length of the recovery window is calculated based on the `retention_policy` setting and the current date/time. - -For example, using the following `retention_policy` settings: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -backup-name = acctg_%year-%month-%dayT%hour:%minute:%second -description = "Accounting" - -[DEV] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 WEEKS -description = "Development" - -[HR] - -host = 127.0.0.1 -port = 5432 -user = postgres -retention_policy = 3 MONTHS -description = "Human Resources" -``` - -If the `MANAGE` subcommand is invoked in debug mode along with the `-n` option on 2015-04-17, the following results are displayed: - -```text --bash-4.1$ bart -d MANAGE -n -DEBUG: Server: acctg, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -259200 (secs) ==> 72 hour(s) -DEBUG: Server: dev, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -1814400 (secs) ==> 504 hour(s) -DEBUG: Server: hr, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -7776000 (secs) ==> 2160 hour(s) -``` - -For server `acctg`, 72 hours translates to a recovery window of 3 days. - -For server `dev`, 504 hours translates to a recovery window of 21 days (3 weeks). - -For server `hr`, 2160 hours translates to a recovery window of 90 days (3 months). - -For a setting of ` MONTHS`, the calculated total number of days for the recovery window is dependent upon the actual number of days in the preceding months from the current date/time. Thus, ` MONTHS` is not always exactly equivalent to ` x 30 DAYS`. For example, if the current date/time is in the month of March, a 1-month recovery window would be equivalent to only 28 days because the preceding month is February. Thus, for a current date of March 31, a 1-month recovery window would start on March 3. However, the typical result is that the day of the month of the starting recovery window boundary will be the same day of the month of when the `MANAGE` subcommand is invoked. - -##### Viewing the Recovery Window Using the Show-Servers Subcommand - -This section provides an example of viewing the recovery window using the `SHOW-SERVERS` subcommand; the `RETENTION POLICY` field displays the start of the recovery window. - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-day recovery window as the active backups. - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -description = "Accounting" -``` - -The start of the 3-day recovery window displayed in the `RETENTION POLICY` field is `2015-04-07 14:57:36 EDT` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-04-07 14:57:36 EDT` would be considered active. Backups taken prior to `2015-04-07 14:57:36 EDT` would be considered obsolete except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 14:57:33 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 2015-04-07 14:57:36 EDT -DISK UTILIZATION : 824.77 MB -NUMBER OF ARCHIVES : 37 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/acctg/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Accounting" -``` - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-week recovery window as the `active` backups. - -```text -[DEV] -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 WEEKS -description = "Development" -``` - -The start of the 3-week recovery window displayed in the `RETENTION POLICY` field is `2015-03-20 14:59:42 EDT` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-03-20 14:59:42 EDT` would be considered `active`. Backups taken prior to `2015-03-20 14:59:42 EDT` would be considered `obsolete` except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 14:59:39 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s dev -SERVER NAME : dev -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5445 -REMOTE HOST : -RETENTION POLICY : 2015-03-20 14:59:42 EDT -DISK UTILIZATION : 434.53 MB -NUMBER OF ARCHIVES : 22 -ARCHIVE PATH : /opt/backup/dev/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/dev/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Development" -``` - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-month recovery window as the `active` backups. - -```text -[HR] -host = 127.0.0.1 -port = 5432 -user = postgres -retention_policy = 3 MONTHS -description = "Human Resources" -``` - -The start of the 3-month recovery window displayed in the `RETENTION POLICY` field is `2015-01-10 14:04:23 EST` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-01-10 14:04:23 EST` would be considered `active`. Backups taken prior to `2015-01-10 14:04:23 EST` would be considered `obsolete`, except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 15:04:19 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s hr -SERVER NAME : hr -HOST NAME : 127.0.0.1 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : -RETENTION POLICY : 2015-01-10 14:04:23 EST -DISK UTILIZATION : 480.76 MB -NUMBER OF ARCHIVES : 26 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Human Resources" -``` - -#### Evaluating, Marking, and Deleting Backup Using a Recovery Window Retention Policy - -The following code sample uses a recovery window retention policy to evaluate, mark, and delete backups as shown by the following server configuration: - -```text -[DEV] -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -description = "Development" -``` - -The following is the current set of backups. Note that the last backup in the list has been marked as `keep`. - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB -14 active -dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB -3 active -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -The current date and time is `2015-04-13 16:46:35 EDT` as shown below: - -```text --bash-4.1$ date -Mon Apr 13 16:46:35 EDT 2015 -``` - -Thus, a 3-day recovery window would evaluate backups prior to `2015-04-10 16:46:35 EDT` as `obsolete` except for those marked as `keep`. - -Invoke the `MANAGE` subcommand with the `-n` option to perform a dry run to observe which active backups would be changed to `obsolete` according to the retention policy. - -```text --bash-4.1$ bart MANAGE -s dev -n -INFO: processing server 'dev', backup '1428933278236' -INFO: processing server 'dev', backup '1428862187757' -INFO: processing server 'dev', backup '1428768351638' -INFO: processing server 'dev', backup '1428684544008' -INFO: marking backup '1428684544008' as obsolete -INFO: 14 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428590536488' -INFO: marking backup '1428590536488' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428502171990' -``` - -The dry run shows that backups `1428684544008` and `1428590536488` would be marked as `obsolete`. - -Also note that a dry run does not change the backup status. The two backups that would be considered obsolete are still marked as `active`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev\ - SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE - WAL FILES STATUS - dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB - 1 active - dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB - 2 active - dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB - 2 active - dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB - 14 active - dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB - 3 active - dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB - 5 keep -``` - -Invoke the `MANAGE` subcommand omitting the `-n` option to change and mark the status of the backups as `obsolete`: - -```text --bash-4.1$ bart MANAGE -s dev -INFO: processing server 'dev', backup '1428933278236' -INFO: processing server 'dev', backup '1428862187757' -INFO: processing server 'dev', backup '1428768351638' -INFO: processing server 'dev', backup '1428684544008' -INFO: marking backup '1428684544008' as obsolete -INFO: 14 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428590536488' -INFO: marking backup '1428590536488' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428502171990' -``` - -The obsolete backups can be observed in a number of ways. Use the `MANAGE` subcommand with the `-l` option to list the `obsolete` backups: - -```text --bash-4.1$ bart MANAGE -s dev -l -INFO: 14 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -SERVER NAME: dev -BACKUP ID: 1428684544008 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-10 12:49:06 EDT -BACKUP SIZE: 5.65 MB -WAL FILE(s): 14 -UNUSED WAL FILE(s): 1 -WAL FILE: 00000001000000000000002E -WAL FILE: 00000001000000000000002D -WAL FILE: 00000001000000000000002C -WAL FILE: 00000001000000000000002B -WAL FILE: 00000001000000000000002A -WAL FILE: 000000010000000000000029 -WAL FILE: 000000010000000000000028 -WAL FILE: 000000010000000000000027 -WAL FILE: 000000010000000000000026 -WAL FILE: 000000010000000000000025 -WAL FILE: 000000010000000000000024 -WAL FILE: 000000010000000000000023 -WAL FILE: 000000010000000000000022 -WAL FILE: 000000010000000000000021 -UNUSED WAL FILE: 00000001000000000000000F.00000028 -INFO: 3 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -SERVER NAME: dev -BACKUP ID: 1428590536488 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-09 10:42:18 EDT\ -BACKUP SIZE: 5.65 MB -WAL FILE(s): 3 -UNUSED WAL FILE(s): 1 -WAL FILE: 000000010000000000000020 -WAL FILE: 00000001000000000000001F -WAL FILE: 00000001000000000000001E -UNUSED WAL FILE: 00000001000000000000000F.00000028 -``` - -The `STATUS` field of the `SHOW-BACKUPS` subcommand displays the current status: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB -14 obsolete -dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB -3 obsolete -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -The details of an individual backup can be displayed using the `SHOW-BACKUPS` subcommand with the `-t` option. Note the status in the `BACKUP STATUS` field. - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -i 1428684544008 -t -SERVER NAME : dev -BACKUP ID : 1428684544008 -BACKUP NAME : none -BACKUP STATUS : obsolete -BACKUP TIME : 2015-04-10 12:49:06 EDT -BACKUP SIZE : 5.65 MB -WAL(S) SIZE : 224.00 MB -NO. OF WALS : 14 -FIRST WAL FILE : 000000010000000000000021 -CREATION TIME : 2015-04-10 12:49:06 EDT -LAST WAL FILE : 00000001000000000000002E -CREATION TIME : 2015-04-11 12:02:15 EDT -``` - -Use the `MANAGE` subcommand with the `-d` option to physically delete the obsolete backups including the unneeded WAL files. - -```text --bash-4.1$ bart MANAGE -s dev -d -INFO: removing all obsolete backups of server 'dev' -INFO: removing obsolete backup '1428684544008' -INFO: 14 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -INFO: removing WAL file '00000001000000000000002E' -INFO: removing WAL file '00000001000000000000002D' -INFO: removing WAL file '00000001000000000000002C' -INFO: removing WAL file '00000001000000000000002B' -INFO: removing WAL file '00000001000000000000002A' -INFO: removing WAL file '000000010000000000000029' -INFO: removing WAL file '000000010000000000000028' -INFO: removing WAL file '000000010000000000000027' -INFO: removing WAL file '000000010000000000000026' -INFO: removing WAL file '000000010000000000000025' -INFO: removing WAL file '000000010000000000000024' -INFO: removing WAL file '000000010000000000000023' -INFO: removing WAL file '000000010000000000000022' -INFO: removing WAL file '000000010000000000000021' -INFO: removing (unused) WAL file '00000001000000000000000F.00000028' -INFO: removing obsolete backup '1428590536488' -INFO: 3 WAL file(s) will be removed -INFO: removing WAL file '000000010000000000000020' -INFO: removing WAL file '00000001000000000000001F' -INFO: removing WAL file '00000001000000000000001E' -``` - -The `SHOW-BACKUPS` subcommand now displays the remaining backups marked as `active` or `keep`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -## Managing Incremental Backups - -This section illustrates evaluating, marking, and deleting incremental backups using the `MANAGE` and `DELETE` subcommands utilizing redundancy retention policy and recovery window retention policy. For detailed information about the `MANAGE` and `DELETE` subcommands, as well as the redundancy retention and recovery window retention policy, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -- [Using a Redundancy Retention Policy](#redundancy_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 3 backup redundancy retention policy is in effect. -- [Using a Recovery Window Retention Policy](#recovery_window_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 1-day recovery window retention policy is in effect. - - - -### Using a Redundancy Retention Policy - -The following code sample uses the `MANAGE` and `DELETE` subcommands to evaluate, mark, and delete incremental backups when a 3 backup redundancy retention policy is in effect. The example uses the following server configuration: - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The example uses the following set of backups. In these code samples, some columns have been omitted from the `SHOW-BACKUPS` output to display the relevant information in a more observable manner. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -There is one backup chain. The first backup is the initial full backup. - -Backup chain: `1481749619582 => 1481749651927 => 1481749673603 => 1481749696905` - -The `MANAGE` subcommand is invoked as shown by the following: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481749619582' -INFO: 2 Unused WAL file(s) present -INFO: 4 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample shows the resulting status of the backups: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -The status remains active for all backups. Even though the total number of backups exceeds the 3 backup redundancy retention policy, it is only the total number of full backups that is used to determine if the redundancy retention policy has been exceeded. Additional full backups are added including a second backup chain. The following example shows the resulting list of backups: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -Second backup chain: `1481749997807 => 1481750098924` - -The `MANAGE` subcommand is invoked, but now with a total of four active full backups. - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481750365397' -INFO: processing server 'acctg', backup '1481749997807' -INFO: processing server 'acctg', backup '1481749992003' -INFO: processing server 'acctg', backup '1481749619582' -INFO: marking backup '1481749619582' as obsolete -INFO: 3 incremental(s) of backup '1481749619582' will be marked obsolete -INFO: marking incremental backup '1481749696905' as obsolete -INFO: marking incremental backup '1481749673603' as obsolete -INFO: marking incremental backup '1481749651927' as obsolete -INFO: 4 WAL file(s) marked obsolete -INFO: 2 Unused WAL file(s) present -INFO: 4 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The oldest full backup and its chain of incremental backups are now marked as obsolete. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... obsolete -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... obsolete -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... obsolete -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... obsolete -``` - -Invoking the `MANAGE` subcommand with the `-d` option deletes the entire obsolete backup chain. - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1481749619582' -INFO: 4 WAL file(s) will be removed -INFO: 3 incremental(s) of backup '1481749619582' will be removed -INFO: removing obsolete incremental backup '1481749696905' -INFO: removing obsolete incremental backup '1481749673603' -INFO: removing obsolete incremental backup '1481749651927' -INFO: removing WAL file '000000010000000100000000' -INFO: removing WAL file '0000000100000000000000FF' -INFO: removing WAL file '0000000100000000000000FE' -INFO: removing WAL file '0000000100000000000000FD' -INFO: 16 Unused file(s) will be removed -INFO: removing (unused) file '000000010000000100000004.00000028.backup' -. -. -. -INFO: removing (unused) file -'0000000100000000FB00002800000000FC000000.mbm' -``` - -The following code sample shows the remaining full backups and the second backup chain. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -``` - - - -### Using a Recovery Window Retention Policy - -The following example demonstrates using the `MANAGE` and `DELETE` subcommands to evaluate, mark, and delete incremental backups when a 1-day recovery window retention policy is in effect. The example uses the following server configuration: - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -retention_policy = 1 DAYS -description = "Accounting" -``` - -The example uses the following set of backups. In the samples, some columns have been omitted from the `SHOW-BACKUPS` output to display the relevant information in a more observable manner. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST ... active -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -There are two backup chains. In each of the following chains, the first backup is the initial full backup. - -First backup chain: `1481552078404 => 1481553088053 => 1481553914533 => 1481554802918 => 1481559014359` - -Second backup chain: `1481553651165 => 1481554203288 => 1481559303348` - -The `MANAGE` subcommand is invoked when the first full backup `1481552078404` falls out of the recovery window. When the `MANAGE` subcommand is invoked, it is `2016-12-13 09:20:03 EST`, thus making the start of the 1-day recovery window at `2016-12-12 09:20:03 EST` exactly one day earlier. This backup was taken at `2016-12-12 09:14:39 EST`, which is about 5 ½ minutes before the start of the recovery window, thus making the backup obsolete. - -```text --bash-4.2$ date -Tue Dec 13 09:20:03 EST 2016 --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481553651165' -INFO: processing server 'acctg', backup '1481552078404' -INFO: marking backup '1481552078404' as obsolete -INFO: 4 incremental(s) of backup '1481552078404' will be marked obsolete -INFO: marking incremental backup '1481559014359' as obsolete -INFO: marking incremental backup '1481554802918' as obsolete -INFO: marking incremental backup '1481553914533' as obsolete -INFO: marking incremental backup '1481553088053' as obsolete -INFO: 7 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the list -``` - -The incremental backup date and time are within the recovery window since they were taken after the start of the recovery window of `2016-12-12 09:20:03 EST`, but all backups in the chain are marked as `obsolete`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg\ -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST -... obsolete -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST -... obsolete -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -The following code sample shows how the entire backup chain is changed back to active status by invoking the `MANAGE` subcommand with the `-c nokeep` option on the full backup of the chain. - -```text --bash-4.2$ bart MANAGE -s acctg -c nokeep -i 1481552078404 -INFO: changing status of backup '1481552078404' of server 'acctg' from -'obsolete' to 'active' -INFO: status of 4 incremental(s) of backup '1481552078404' will be -changed -INFO: changing status of incremental backup '1481559014359' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481554802918' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481553914533' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481553088053' of server -'acctg' from 'obsolete' to 'active' -INFO: 7 WAL file(s) changed -``` - -The backup chain has now been reset to active status. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST ... active -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -The following code sample shows usage of the `DELETE` subcommand on an incremental backup. The specified incremental backup `1481554802918` in the first backup chain as well as its successive incremental backup `1481559014359` are deleted. - -```text --bash-4.2$ bart DELETE -s acctg -i 1481554802918 -INFO: deleting backup '1481554802918' of server 'acctg' -INFO: deleting backup '1481554802918' -INFO: 1 incremental backup(s) will be deleted -INFO: deleting incremental backup '1481559014359' -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or -will be marked unused -INFO: 2 Unused file(s) will be removed -INFO: removing (unused) file '0000000100000000000000BA' -INFO: removing (unused) file -'0000000100000000BA00002800000000BB000000.mbm' -INFO: backup(s) deleted -``` - -The results show that the backups `1481554802918` and `1481559014359` are no longer listed by the `SHOW-BACKUPS` subcommand. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -The `MANAGE` subcommand is invoked again. This time both backup chains are marked `obsolete` since the full backups of both chains fall out of the start of the recovery window, which is now `2016-12-12 09:55:03 EST`. - -```text --bash-4.2$ date -Tue Dec 13 09:55:03 EST 2016 --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481553651165' -INFO: marking backup '1481553651165' as obsolete -INFO: 2 incremental(s) of backup '1481553651165' will be marked obsolete -INFO: marking incremental backup '1481559303348' as obsolete -INFO: marking incremental backup '1481554203288' as obsolete -INFO: 38 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1481552078404' -INFO: marking backup '1481552078404' as obsolete -INFO: 2 incremental(s) of backup '1481552078404' will be marked obsolete -INFO: marking incremental backup '1481553914533' as obsolete -INFO: marking incremental backup '1481553088053' as obsolete -INFO: 7 WAL file(s) marked obsolete -``` - -The following code sample shows both backup chains marked as `obsolete`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... obsolete -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... obsolete -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... obsolete -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -The following code sample demonstrates using the `MANAGE` subcommand with the `-c keep` option to keep a backup chain indefinitely. The `MANAGE` subcommand with the `-c keep` option must specify the backup identifier or backup name of the full backup of the chain, and not any incremental backup. - -```text --bash-4.2$ bart MANAGE -s acctg -c keep -i 1481553651165 -INFO: changing status of backup '1481553651165' of server 'acctg' from -'obsolete' to 'keep' -INFO: status of 2 incremental(s) of backup '1481553651165' will be -changed -INFO: changing status of incremental backup '1481559303348' of server -'acctg' from 'obsolete' to 'keep' -INFO: changing status of incremental backup '1481554203288' of server -'acctg' from 'obsolete' to 'keep' -INFO: 38 WAL file(s) changed -``` - -The full backup `1481553651165` and its successive incremental backups `1481554203288` and `1481559303348` have been changed to `keep` status: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... keep -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... keep -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... keep -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -Finally, the `MANAGE` subcommand with the `-d` option is used to delete the `obsolete` backup chain: - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1481552078404' -INFO: 7 WAL file(s) will be removed -INFO: 2 incremental(s) of backup '1481552078404' will be removed -INFO: removing obsolete incremental backup '1481553914533' -INFO: removing obsolete incremental backup '1481553088053' -INFO: removing WAL file '0000000100000000000000C1' -INFO: removing WAL file '0000000100000000000000C0' -INFO: removing WAL file '0000000100000000000000BF' -INFO: removing WAL file '0000000100000000000000BE' -INFO: removing WAL file '0000000100000000000000BD' -INFO: removing WAL file '0000000100000000000000BC' -INFO: removing WAL file '0000000100000000000000BB' -INFO: 48 Unused file(s) will be removed -INFO: removing (unused) file '0000000100000000000000FA' -. -. -. -INFO: removing (unused) file '0000000100000000000000BB.00000028.backup' -``` - -Only the backup chain with the `keep` status remains as shown below: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... keep -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... keep -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... keep -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx b/product_docs/docs/bart/2.5.9/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx deleted file mode 100644 index b1527216806..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx +++ /dev/null @@ -1,1385 +0,0 @@ ---- -title: "Sample BART System with Local and Remote Database Servers" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/sample_bart_system_with_local_and_remote_database_servers.html" ---- - - - -This section describes a sample BART managed backup and recovery system consisting of both local and remote database servers. The complete steps to configure and operate the system are provided. - -For detailed information about configuring a BART system, see the *EDB Backup and Recovery Installation and Upgrade Guide*. For detailed information about the operational procedures and BART subcommands, see the *EDB Backup and Recovery User Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). - -The environment for this sample system is as follows: - -- BART on host `192.168.2.22` running with BART user account `enterprisedb` -- Local Advanced Server on host `192.168.2.22` running with user account `enterprisedb` -- Remote Advanced Server on host `192.168.2.24` running with user account `enterprisedb` -- Remote PostgreSQL server on host `192.168.2.24` running with user account `postgres` - -Passwordless SSH/SCP connections are required between the following: - -- BART on host `192.168.2.22` and the local Advanced Server on the same host `192.168.2.22` -- BART on host `192.168.2.22` and the remote Advanced Server on host `192.168.2.24` -- BART on host `192.168.2.22` and the remote PostgreSQL server on host `192.168.2.24` - -The following sections demonstrate configuring and taking full backups only. To support incremental backups as well, enable the `allow_incremental_backups` parameter for the desired database servers and use the `WAL scanner` program. - -- [The BART Configuration File](#bart_configuration_file) shows the settings used in the BART configuration file. -- [Establishing SSH/SCP Passwordless Connections](#establishing-sshscp-passwordless-connections) provides an example of how to establish an SSH/SCP passwordless connection. -- [Configuring a Replication Database User](#configuring-a-replication-database-user) provides an example of how to configure the replication database user. -- [WAL Archiving Configuration Parameters](#wal-archiving-configuration-parameters) provides an example of how to configure WAL archiving. -- [Creating the BART Backup Catalog](#creating-the-bart-backup-catalog-backup_path) provides information about creating a BART Backup Catalog. -- [Starting the Database Servers with WAL Archiving](#starting-the-database-servers-with-wal-archiving) provides example of starting the database servers with WAL archiving. -- [Taking a Full Backup](#taking-a-full-backup) illustrates taking the first full backup of the database servers. -- [Using Point-In-Time Recovery](#using-point-in-time-recovery) demonstrates the point-in-time recovery operation on the remote PostgreSQL database server. - - - -## The BART Configuration File - -The following code sample shows the settings used in the BART configuration file for the examples that follow: - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" - -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" - -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - - - -## Establishing SSH/SCP Passwordless Connections - -This section demonstrates how passwordless SSH/SCP connections are established with the authorized public keys files. - - - -### Generating a Public Key File for the BART User Account - -The BART user account is `enterprisedb` with a home directory of `/opt/PostgresPlus/9.6AS`. - -To generate the public key file, as a root user, first create the `.ssh` subdirectory in the BART user’s home directory and assign ownership of this directory to the `enterprisedb` user, ensuring there are no groups or other users that can access the `.ssh` directory. - -```text -[root@localhost 9.6AS]# pwd -/opt/PostgresPlus/9.6AS -[root@localhost 9.6AS]# mkdir .ssh -[root@localhost 9.6AS]# chown enterprisedb .ssh -[root@localhost 9.6AS]# chgrp enterprisedb .ssh -[root@localhost 9.6AS]# chmod 700 .ssh -[root@localhost 9.6AS]# ls -la | grep ssh -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 13:02 .ssh -``` - -Generate the public key file: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key -(/opt/PostgresPlus/9.6AS/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa. -Your public key has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa.pub. -The key fingerprint is: -de:65:34:d6:b1:d2:32:3c:b0:43:c6:a3:c0:9f:f4:64 -enterprisedb@localhost.localdomain -The key's randomart image is: -+----[ RSA 2048]----+ -| . .+ . | -| o .oE+ o o | -| + * o.X + | -| + .+ * | -| S o | -| . . o | -| . . | -| - | -| | -+-------------------+ -``` - -The following are the resulting files. `id_rsa.pub` is the public key file of BART user account `enterprisedb`. - -```text --bash-4.1$ ls -l .ssh -total 8 --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -### Configuring Access between Local Advanced Server and the BART Host - -Even when the Advanced Server database is on the same host as the BART user account, and the Advanced Server database cluster owner is also the BART user account (`enterprisedb` is this case), a passwordless SSH/SCP connection must be established from the same user account to itself. - -On the BART host where the public key file was just generated (as shown in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account)), create the authorized keys file by appending the public key file to any existing authorized keys file. - -Log into the BART host as the BART user account and append the public key file, `id_rsa.pub` onto the `authorized_keys` file in the same `.ssh` directory. - -```text -[user@localhost ~]$ su - enterprisedb -Password: -Last login: Thu Mar 23 10:27:35 EDT 2017 on pts/0 --bash-4.2$ pwd -/opt/PostgresPlus/9.6AS --bash-4.2$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts --bash-4.2$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys --bash-4.2$ ls -l .ssh -total 16 --rw-rw-r-- 1 enterprisedb enterprisedb 416 Mar 23 10:33 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts -``` - -The `authorized_keys` file must have file permission `600` as set by the following `chmod 600` command, or the passwordless connection will fail: - -```text --bash-4.2$ chmod 600 ~/.ssh/authorized_keys --bash-4.2$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 416 Mar 23 10:33 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts -``` - -Test the passwordless connection. Use the `ssh` command to verify that you can access the same user account as you are currently logged in as (`enterprisedb`) without being prompted for a password: - -```text --bash-4.2$ ssh enterprisedb@127.0.0.1 -Last login: Thu Mar 23 10:27:50 2017 --bash-4.2$ exit -logout -Connection to 127.0.0.1 closed. -``` - -### Configuring Access from Remote Advanced Server to BART Host - -On the remote host `192.168.2.24`, create the public key file for the remote database server user account, `enterprisedb`, for access to the BART user account, `enterprisedb`, on the BART host 192.168.2.22. - -Create the `.ssh` directory for user account `enterprisedb` on the remote host: - -```text -[root@localhost 9.6AS]# pwd -/opt/PostgresPlus/9.6AS -[root@localhost 9.6AS]# mkdir .ssh -[root@localhost 9.6AS]# chown enterprisedb .ssh -[root@localhost 9.6AS]# chgrp enterprisedb .ssh -[root@localhost 9.6AS]# chmod 700 .ssh -[root@localhost 9.6AS]# ls -la | grep ssh -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 13:08 .ssh -``` - -Generate the public key file on the remote host for user account `enterprisedb`: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key -(/opt/PostgresPlus/9.6AS/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa. -Your public key has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa.pub. -The key fingerprint is: -15:27:1e:1e:61:4b:48:66:67:0b:b2:be:fc:ea:ea:e6 -enterprisedb@localhost.localdomain -The key's randomart image is: -+--[ RSA 2048]---+ -| ..=.@.. | -| =.O O | -| . * | -| . . | -| . S | -| . . | -| o | -| . . | -| +Eoo.. | -+----------------+ -``` - -Copy the generated public key file, `id_rsa.pub`, to the BART user account, `enterprisedb`, on the BART host, `192.168.2.22`: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.22:/tmp/tmp.pub -The authenticity of host '192.168.2.22 (192.168.2.22)' can't be -established. -RSA key fingerprint is b8:a9:97:31:79:16:b8:2b:b0:60:5a:91:38:d7:68:22. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.22' (RSA) to the list of known hosts. -enterprisedb@192.168.2.22's password: -id_rsa.pub -``` - -Log into the BART host as the BART user account and append the temporary public key file, `/tmp/tmp.pub` onto the `authorized_keys` file owned by the BART user account. - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -enterprisedb@192.168.2.22's password: -Last login: Tue Apr 21 17:03:24 2015 from 192.168.2.22 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 12 --rw-rw-r-- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -The `authorized_keys` file must have file permission `600` as set by the following `chmod 600` command, otherwise the passwordless connection fails: - -```text --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -Test the passwordless connection. From the remote host, verify that you can log into the BART host with the BART user account without being prompted for a password: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -Last login: Thu Apr 23 13:14:48 2015 from 192.168.2.24 --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -### Configuring Access from the BART Host to a Remote Advanced Server - -On the BART host `192.168.2.22`, copy the public key file for the BART user account, `enterprisedb`, for access to the remote database server user account, `enterprisedb`, on the remote host `192.168.2.24`. - -The following lists the current SSH keys files in the BART user’s `.ssh` directory on the BART host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -The public key file, `id_rsa.pub`, for BART user account `enterprisedb` on the BART host that was earlier generated in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account), is now copied to the remote Advanced Server host on `192.168.2.24`: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.24:/tmp/tmp.pub -The authenticity of host '192.168.2.24 (192.168.2.24)' can't be -established. -RSA key fingerprint is 59:41:fb:0c:ae:64:3d:3f:a2:d9:90:95:cf:2c:99:f2. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.24' (RSA) to the list of known -hosts. -enterprisedb@192.168.2.24's password: -id_rsa.pub -``` - -Log into the `enterprisedb` user account on the remote host and copy the public key file onto the `authorized_keys` file of the remote `enterprisedb` user account under its `.ssh` directory: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.24 -enterprisedb@192.168.2.24's password: -Last login: Tue Apr 21 09:53:18 2015 from 192.168.2.22 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:11 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:11 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:12 known_hosts --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys -``` - -Adjust the file permission on `authorized_keys`: - -```text --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:26 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:11 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:11 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:12 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -While logged into the BART host, test the passwordless connection from the BART host to the remote Advanced Server host: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.24 -Last login: Thu Apr 23 13:25:53 2015 from 192.168.2.22 --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -### Configuring Access from a Remote PostgreSQL Server to a BART Host - -On the remote host (192.168.2.24), create a public key file owned by the database server user account (`postgres`), allowing access to the BART user account (`enterprisedb`) on the BART host (192.168.2.22). - -Create the `.ssh` directory for the `postgres` user account on the remote host: - -```text -[root@localhost 9.6]# cd /opt/PostgreSQL/9.6 -[root@localhost 9.6]# mkdir .ssh -[root@localhost 9.6]# chown postgres .ssh -[root@localhost 9.6]# chgrp postgres .ssh -[root@localhost 9.6]# chmod 700 .ssh -[root@localhost 9.6]# ls -la | grep ssh -drwx------ 2 postgres postgres 4096 Apr 23 13:32 .ssh -``` - -Create and copy the generated public key file, `id_rsa.pub`, to the BART user account (`enterprisedb`), on the BART host (`192.168.2.22`): - -```text -[user@localhost ~]$ su - postgres -Password: --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key (/opt/PostgreSQL/9.6/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in /opt/PostgreSQL/9.6/.ssh/id_rsa. -Your public key has been saved in /opt/PostgreSQL/9.6/.ssh/id_rsa.pub. -The key fingerprint is: -1f:f8:76:d6:fc:a5:1a:c5:5a:66:66:01:d0:a0:ca:ba -postgres@localhost.localdomain -The key's randomart image is: -+--[ RSA 2048]----+ -| o+. | -| . .. | -| . . | -| . . . . . | -| o S . O | -| . o . @ | -| . + = o .| -| . . o . o.| -| E ... .| -+-----------------+ --bash-4.1$ ls -l .ssh -total 8 --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.22:/tmp/tmp.pub -The authenticity of host '192.168.2.22 (192.168.2.22)' can't be -established. -RSA key fingerprint is b8:a9:97:31:79:16:b8:2b:b0:60:5a:91:38:d7:68:22. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.22' (RSA) to the list of known -hosts. -enterprisedb@192.168.2.22's password: -id_rsa.pub -``` - -Log into the BART host as the BART user account and append the temporary public key file, `/tmp/tmp.pub`, onto the `authorized_keys` file owned by the BART user account. - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -enterprisedb@192.168.2.22's password: -Last login: Thu Apr 23 13:19:25 2015 from 192.168.2.24 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 828 Apr 23 13:40 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:24 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -Make sure the `authorized_keys` file has file permission 600 as shown, or the passwordless connection will fail. Test the passwordless connection; from the remote host, while logged in as user account `postgres`, verify that you can log into the BART host with the BART user account without being prompted for a password: - -```text --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ ssh enterprisedb@192.168.2.22 -Last login: Thu Apr 23 13:40:10 2015 from 192.168.2.24 --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -### Configuring Access from the BART Host to Remote PostgreSQL - -Copy the public key file on the BART host that is owned by the BART user account (`enterprisedb`) to the remote database server user account (`postgres`), on the remote host (192.168.2.24). - -The following lists the current SSH keys files in the BART user’s `.ssh` directory on the BART host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 828 Apr 23 13:40 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:24 known_hosts -``` - -The public key file, `id_rsa.pub`, for BART user account `enterprisedb` on the BART host that was earlier generated in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account), now resides on the remote PostgreSQL host: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub postgres@192.168.2.24:/tmp/tmp.pub -postgres@192.168.2.24's password: -id_rsa.pub -``` - -Log into the `postgres` user account on the remote host and copy the public key file onto the `authorized_keys` file of `postgres` under its `.ssh` directory: - -```text --bash-4.1$ ssh postgres@192.168.2.24 -postgres@192.168.2.24's password: -Last login: Mon Jan 26 18:08:36 2015 from 192.168.2.19 --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys -``` - -Adjust the file permissions on `authorized_keys`: - -```text --bash-4.1$ ls -l .ssh -total 16 --rw-rw-r-- 1 postgres postgres 416 Apr 23 13:52 authorized_keys --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --rw-r--r-- 1 postgres postgres 394 Apr 23 13:36 known_hosts --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 postgres postgres 416 Apr 23 13:52 authorized_keys --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --rw-r--r-- 1 postgres postgres 394 Apr 23 13:36 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -Test the passwordless connection from the BART host to the remote PostgreSQL host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ssh postgres@192.168.2.24 -Last login: Thu Apr 23 13:52:25 2015 from 192.168.2.22 --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - - - -## Configuring a Replication Database User - -This section demonstrates how a replication database user is established. - -**All database servers must use a superuser as the replication database user.** - -The replication database user for each database server is specified by the `user` parameter in the BART configuration file as shown by the following: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb <=== Replication Database User -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" - -[MKTG] -host = 192.168.2.24 -port = 5444 -user = repuser <=== Replication Database User -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" - -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres <=== Replication Database User -cluster_owner = enterprisedb -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -Add entries to the `.pgpass` file on each server to allow the BART user account to initiate a backup without being prompted for credentials. The `.pgpass` file is located in `/opt/PostgresPlus/9.6AS/.pgpass`: - -```text -127.0.0.1:5444:*:enterprisedb:password -192.168.2.24:5444:*:repuser:password -192.168.2.24:5432:*:postgres:password -``` - -For more information about using a `.pgpass` file, please see the [PostgreSQL documentation](https://www.postgresql.org/docs/current/libpq-pgpass.html). - -While connected to `MKTG` on 192.168.2.24, execute the following `CREATE ROLE` command to create the replication database superuser: - -```text -CREATE ROLE repuser WITH LOGIN SUPERUSER PASSWORD 'password'; -``` - -Access is granted in the `pg_hba.conf` file for the local Advanced Server: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 enterprisedb 127.0.0.1/32 md5 -host edb enterprisedb 127.0.0.1/32 md5 -#host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -#local replication enterprisedb md5 -host replication enterprisedb 127.0.0.1/32 md5 -``` - -Similarly, access is granted in the `pg_hba.conf` file for the remote Advanced Server installation: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 repuser 192.168.2.22/32 md5 -host all enterprisedb 127.0.0.1/32 md5 -#host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -#local replication enterprisedb md5 -host replication repuser 192.168.2.22/32 md5 -``` - -Access is also granted in the `pg_hba.conf` file for the remote PostgreSQL server: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 postgres 192.168.2.22/32 md5 -host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -q# replication privilege. -#local replication postgres md5 -host replication postgres 192.168.2.22/32 md5 -``` - - - -## WAL Archiving Configuration Parameters - -Use the following parameters in the `postgresql.conf` file to enable WAL archiving. The `postgresql.conf` file for the local Advanced Server database (`ACCTG`) is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -#archive_command = '' # command to use to archive - a logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set based on the BART `archive_command` parameter located in the BART configuration file. - -!!! Note - If the Postgres `archive_command` is already set, invoke the `INIT` subcommand with the `-- no-configure` option to prevent the `archive_command` from being reset. For details, see [INIT](../bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init/#init). - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -When the `INIT` subcommand is invoked, the `postgresql.auto.conf` file contains the following: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup/acctg/archived_wals/%f' -``` - -The `archive_command` uses the `cp` command instead of `scp` since the BART backup catalog is local to this database cluster and the BART user account (the account that owns the backup catalog, `enterprisedb`), is the same user account running Advanced Server. The result is that there is no directory permission conflict during the archive operation. - -The `postgresql.conf` file for the remote Advanced Server, `MKTG` is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -archive_command = '' # command to use to archive a - logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set by the default BART format of the BART `archive_command` parameter (since it is not explicitly set for this database server in the BART configuration file). - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -. -. -. -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" -``` - -The default BART `archive_command` format is: - -```text -archive_command = 'scp %p %h:%a/%f' -``` - -The `postgresql.auto.conf` file contains the following after the `INIT` subcommand is invoked: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f' -``` - -The `archive_command` uses the `scp` command since the BART backup catalog is remote relative to this database cluster. The BART user account, `enterprisedb`, is specified on the `scp` command since this is the user account owning the BART backup catalog where the archived WAL files are to be copied. The result is that there is no directory permission conflict during the archive operation. - -The `postgresql.conf` file for the remote PostgreSQL server (`HR`) is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -#archive_command = '' # command to use to archive a - logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set by the default BART format of the BART `archive_command` parameter (since it is not explicitly set for this database server in the BART configuration file): - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -. -. -. -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -The default BART `archive_command` format is: - -```text -archive_command = 'scp %p %h:%a/%f' -``` - -The `postgresql.auto.conf` file contains the following after the `INIT` subcommand is invoked: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f' -``` - -The `archive_command` uses the `scp` command since the BART backup catalog is remote relative to this database cluster. The BART user account, `enterprisedb`, is specified on the `scp` command since this is the user account owning the BART backup catalog where the archived WAL files are to be copied. The result is that there is no directory permission conflict during the archive operation. - - - -## Creating the BART Backup Catalog (backup_path) - -Create the directory specified by the `backup_path` configuration parameter. - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -``` - -Ensure that the directory is owned by the BART user account: - -```text -[root@localhost opt]# pwd -/opt -[root@localhost opt]# mkdir backup -[root@localhost opt]# chown enterprisedb backup -[root@localhost opt]# chgrp enterprisedb backup -[root@localhost opt]# chmod 700 backup -[root@localhost opt]# ls -l | grep backup -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 15:36 backup -``` - -Use the BART `INIT` subcommand to complete the directory structure and set the Postgres `archive_command` configuration parameter. - -Before invoking any BART subcommands, set up a profile under the BART user account’s home directory to set the `LD_LIBRARY_PATH` and `PATH` environment variables. For more information regarding setting this variable, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -The `-o` option is specified with the `INIT` subcommand to force the setting of the Postgres `archive_command` configuration parameter when `archive_mode` is `off` or if the Postgres `archive_command` parameter is already set and needs to be overridden. - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ bart INIT -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -INFO: setting archive_command for server 'hr' -WARNING: archive_command is set. server restart is required -INFO: setting archive_command for server 'mktg' -WARNING: archive_command is set. server restart is required -``` - -The BART `SHOW-SERVERS` subcommand displays the following: - -```text --bash-4.1$ bart SHOW-SERVERS -SERVER NAME : acctg -BACKUP FRIENDLY NAME: acctg_%year-%month-%dayT%hour:%minute -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -SERVER NAME : hr -BACKUP FRIENDLY NAME: hr_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : postgres@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Human Resources" -SERVER NAME : mktg -BACKUP FRIENDLY NAME: mktg_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : enterprisedb@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/mktg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Marketing" --bash-4.1$ cd /opt/backup --bash-4.1$ pwd -/opt/backup --bash-4.1$ ls -l -total 12 -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 acctg -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 hr -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 mktg --bash-4.1$ ls -l acctg -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals --bash-4.1$ ls -l hr -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals --bash-4.1$ ls -l mktg -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals -``` - -The `ARCHIVE PATH` field displays the full directory path to where the WAL files are copied. This directory path must match the directory path specified in the Postgres `archive_command` parameter of the `postgresql.conf` file or the `postgresql.auto.conf` file of each database server. - - - -### Starting the Database Servers with WAL Archiving - -After the BART backup catalog directory structure has been configured, start the archiving of WAL files from the database servers by restarting each database server. - -On BART host 192.168.2.22: - -```text -[root@localhost data]# service ppas-9.6 restart -``` - -On remote host 192.168.2.24: - -```text -[root@localhost data]# service ppas-9.6 restart - -[root@localhost data]# service postgresql-9.6 restart -``` - -In the BART backup catalog, verify that the WAL files are archiving. - -Archived WAL files may not appear very frequently depending upon how often WAL archiving is set to switch to a new segment file with the `archive_timeout` parameter in your database server configuration settings. - -Verify that there are no archiving-related errors in the database server log files. - -## Taking a Full Backup - -The following code sample shows the first full backup of the database servers. - -```text --bash-4.1$ bart BACKUP -s acctg -z -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1490809695281' -60776/60776 kB (100%), 1/1 tablespace - -INFO: backup completed successfully -INFO: backup checksum: 37f3defb98ca88dcf05079815555dfc2 of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809695281 -BACKUP NAME: acctg_2017-03-29T13:48 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1490809695281 -BACKUP SIZE: 6.10 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -37f3defb98ca88dcf05079815555dfc2 base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000004 -STOP WAL LOCATION: 000000010000000000000004 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:48:15 EDT -STOP TIME: 2017-03-29 13:48:17 EDT -TOTAL DURATION: 2 sec(s) - --bash-4.1$ bart BACKUP -s mktg -z -INFO: creating backup for server 'mktg' -INFO: backup identifier: '1490809751193' -61016/61016 kB (100%), 1/1 tablespace - -INFO: backup completed successfully -INFO: backup checksum: 8b010e130a105e76d01346bb56dfcf14 of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809751193 -BACKUP NAME: mktg_2017-03-29T13:49 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/mktg/1490809751193 -BACKUP SIZE: 6.13 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -8b010e130a105e76d01346bb56dfcf14 base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000100000085 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:49:11 EDT -STOP TIME: 2017-03-29 13:49:14 EDT -TOTAL DURATION: 3 sec(s) - --bash-4.1$ bart BACKUP -s hr -z -INFO: creating backup for server 'hr' -INFO: backup identifier: '1490809824946' -38991/38991 kB (100%), 1/1 tablespace -INFO: backup completed successfully -INFO: backup checksum: 277e8a1a80ba3474f541eb316a417c9a of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809824946 -BACKUP NAME: hr_2017-03-29T13:50 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/hr/1490809824946 -BACKUP SIZE: 2.59 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -277e8a1a80ba3474f541eb316a417c9a base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000002 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:50:25 EDT -STOP TIME: 2017-03-29 13:50:26 EDT -TOTAL DURATION: 1 sec(s) -``` - -The following code sample shows the backup directories created for each backup of each database server. The backup ID is used as the backup directory name. - -```text --bash-4.1$ cd /opt/backup --bash-4.1$ ls -l -total 12 -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:48 acctg -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:50 hr -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:49 mktg --bash-4.1$ ls -l acctg -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:48 1490809695281 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:48 archived_wals --bash-4.1$ ls -l hr -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:50 1490809824946 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:50 archived_wals --bash-4.1$ ls -l mktg -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:49 1490809751193 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:49 archived_wals -``` - - - -## Using Point-In-Time Recovery - -This section demonstrates using the point-in-time recovery operation on the remote PostgreSQL database server. - -The following tables were created about two minutes apart with WAL archiving enabled: - -```text -postgres=# \dt - - List of relations -Schema | Name | Type | Owner - ---------+----------------+---------+--------- -public | hr_rmt_t1_1356 | table | postgres -public | hr_rmt_t1_1358 | table | postgres -public | hr_rmt_t1_1400 | table | postgres -public | hr_rmt_t1_1402 | table | postgres -public | hr_rmt_t1_1404 | table | postgres -public | hr_rmt_t1_1406 | table | postgres -(6 rows) -``` - -In the table name `hr_rmt_t_, n` represents the active timeline. `` is the approximate time the table was created. For example, `hr_rmt_t1_1356` was created at approximately 1:56 PM while timeline #1 is active. - -The PostgreSQL database server was then stopped. WAL files that have been created, but not yet archived must be identified, and then saved. The following archived WAL files are in the BART backup catalog: - -```text --bash-4.1$ ls -l hr/archived_wals -total 49156 --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 13:50 -000000010000000000000001 --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 13:50 -000000010000000000000002 --rw------- 1 enterprisedb enterprisedb 302 Mar 29 13:50 -000000010000000000000002.00000028.backup --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 14:07 -000000010000000000000003 -``` - -The following sample lists the current PostgreSQL server WAL files. The unarchived WAL files are marked with two stars (\*\*). - -```text --bash-4.1$ cd /opt/PostgreSQL/9.6/data/pg_xlog --bash-4.1$ pwd -/opt/PostgreSQL/9.6/data/pg_xlog --bash-4.1$ ls -l -total 49160 --rw------- 1 postgres postgres 302 Mar 29 13:50 -000000010000000000000002.00000028.backup --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000003 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -**000000010000000000000004** --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -**000000010000000000000005** -drwx------ 2 postgres postgres 4096 Mar 29 14:07 archive_status -``` - -Copies of the unarchived WAL files are saved to a temporary location: - -```text --bash-4.1$ mkdir /tmp/unarchived_pg96_wals --bash-4.1$ pwd -/opt/PostgreSQL/9.6/data/pg_xlog -bash-4.1$ cp -p 000000010000000000000004 /tmp/unarchived_pg96_wals -bash-4.1$ cp -p 000000010000000000000005 /tmp/unarchived_pg96_wals -bash-4.1$ ls -l /tmp/unarchived_pg96_wals -total 32768 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 000000010000000000000005 -``` - -On the remote host, a directory is created to which the PostgreSQL database cluster is to be restored. This restore path is named `/opt/restore_pg96` and is owned by user account `postgres`. - -```text -[user@localhost ~]$ su root -Password: -[root@localhost user]# cd /opt -[root@localhost opt]# mkdir restore_pg96 -[root@localhost opt]# chown postgres restore_pg96 -[root@localhost opt]# chgrp postgres restore_pg96 -[root@localhost opt]# chmod 700 restore_pg96 -[root@localhost opt]# ls -l -total 16 -drwxr-xr-x 4 root daemon 4096 Mar 29 12:10 PostgresPlus -drwxr-xr-x 3 root daemon 4096 Mar 29 12:25 PostgreSQL -drwx------ 2 postgres postgres 4096 Mar 29 14:15 restore_pg96 -drwxr-xr-x. 2 root root 4096 Nov 22 2013 rh -``` - -In the BART configuration file, the remote user and remote host IP address, `postgres@192.168.2.24`, have been set with the `remote_host` parameter. If not given in the BART configuration file, this information must then be specified by the `--remote-host` option when giving the `RESTORE` subcommand (for example, `bart RESTORE --remote-host postgres@192.168.2.24 …`). - -```text -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -Use the `SHOW-BACKUPS` subcommand to identify the backup to use with the `RESTORE` subcommand. - -```text -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME -BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -acctg 1490809695281 acctg_2017-03-29T13:48 none -2017-03-29 13:48:17 EDT -6.10 MB 32.00 MB 2 active -hr 1490809824946 hr_2017-03-29T13:50 none -2017-03-29 13:50:26 EDT -2.59 MB 32.00 MB 2 active -mktg 1490809751193 mktg_2017-03-29T13:49 none -2017-03-29 13:49:14 EDT -6.13 MB 64.00 MB 4 active -``` - -The `-t` option with the `SHOW-BACKUPS` subcommand displays additional backup information: - -```text --bash-4.1$ bart SHOW-BACKUPS -s hr -i 1490809824946 -t -SERVER NAME : hr -BACKUP ID : 1490809824946 -BACKUP NAME : hr_2017-03-29T13:50 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2017-03-29 13:50:26 EDT -BACKUP SIZE : 2.59 MB -WAL(S) SIZE : 32.00 MB -NO. OF WALS : 2 -FIRST WAL FILE : 000000010000000000000002 -CREATION TIME : 2017-03-29 13:50:31 EDT -LAST WAL FILE : 000000010000000000000003 -CREATION TIME : 2017-03-29 14:07:35 EDT -``` - -A recovery is made using timeline `1` to `2017-03-29 14:01:00`. - -```text --bash-4.1$ bart RESTORE -s hr -i hr_2017-03-29T13:50 -p -/opt/restore_pg96 -t 1 -g '2017-03-29 14:01:00' -INFO: restoring backup 'hr_2017-03-29T13:50' of server 'hr' -INFO: base backup restored -INFO: copying WAL file(s) to -postgres@192.168.2.24:/opt/restore_pg96/archived_wals -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: restore completed successfully -``` - -The following example shows the restored backup files in the restore path directory, `/opt/restore_pg96`: - -```text --bash-4.1$ pwd -/opt/restore_pg96 --bash-4.1$ ls -l -total 128 -drwxr-xr-x 2 postgres postgres 4096 Mar 29 14:27 archived_wals --rw------- 1 postgres postgres 206 Mar 29 13:50 backup_label -drwx------ 5 postgres postgres 4096 Mar 29 12:25 base -drwx------ 2 postgres postgres 4096 Mar 29 14:27 global -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_clog -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_commit_ts -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_dynshmem --rw------- 1 postgres postgres 4212 Mar 29 13:18 pg_hba.conf --rw------- 1 postgres postgres 1636 Mar 29 12:25 pg_ident.conf -drwxr-xr-x 2 postgres postgres 4096 Mar 29 13:45 pg_log -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_logical -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_multixact -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_notify -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_replslot -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_serial -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_snapshots -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_stat -drwx------ 2 postgres postgres 4096 Mar 29 13:50 pg_stat_tmp -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_subtrans -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_tblspc -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_twophase --rw------- 1 postgres postgres 4 Mar 29 12:25 PG_VERSION -drwx------ 3 postgres postgres 4096 Mar 29 14:27 pg_xlog --rw------- 1 postgres postgres 169 Mar 29 13:24 postgresql.auto.conf --rw-r--r-- 1 postgres postgres 21458 Mar 29 14:27 postgresql.conf --rw-r--r-- 1 postgres postgres 118 Mar 29 14:27 postgresql.auto.conf -``` - -Copy the saved, unarchived WAL files to the restore path `pg_xlog` subdirectory (`/opt/restore_pg96/pg_xlog`): - -```text --bash-4.1$ pwd -/opt/restore_pg96/pg_xlog --bash-4.1$ ls -l -total 16388 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000002 -drwx------ 2 postgres postgres 4096 Mar 29 14:27 archive_status --bash-4.1$ ls -l /tmp/unarchived_pg96_wals -total 32768 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000005 --bash-4.1$ cp -p /tmp/unarchived_pg96_wals/* . --bash-4.1$ ls -l -total 49156 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000002 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000005 -drwx------ 2 postgres postgres 4096 Mar 29 14:27 archive_status -``` - -Inspect the `/opt/restore_pg96/postgresql.auto.conf` file to verify that it contains the correct recovery settings: - -```text -restore_command = 'cp archived_wals/%f %p' -recovery_target_time = '2017-03-29 14:01:00' -recovery_target_timeline = 1 -``` - -Note that the command restores from the `archived_wals` subdirectory of `/opt/restore_pg96` since the `copy_wals_during_restore` parameter in the BART configuration file is set to `enabled` for database server `hr`. - -Start the database server to initiate the point-in-time recovery operation: - -```text -[user@localhost ~]$ su postgres -Password: -bash-4.1$ cd /opt/restore_pg96 -bash-4.1$ /opt/PostgreSQL/9.6/bin/pg_ctl start -D /opt/restore_pg96 -l -/opt/restore_pg96/pg_log/logfile -server starting -``` - -Inspect the database server log file to ensure the operation did not result in any errors: - -```text -2017-03-29 14:33:23 EDT LOG: database system was interrupted; last known -up at 2017-03-29 13:50:25 EDT -2017-03-29 14:33:23 EDT LOG: starting point-in-time recovery to -2017-03-29 14:01:00-04 -2017-03-29 14:33:23 EDT LOG: restored log file -"000000010000000000000002" from archive -2017-03-29 14:33:23 EDT LOG: redo starts at 0/2000098 -2017-03-29 14:33:23 EDT LOG: consistent recovery state reached at -0/20000C0 -2017-03-29 14:33:23 EDT LOG: restored log file -"000000010000000000000003" from archive -2017-03-29 14:33:23 EDT LOG: recovery stopping before commit of -transaction 1762, time 2017-03-29 14:02:28.100072-04 -2017-03-29 14:33:23 EDT LOG: redo done at 0/303F390 -2017-03-29 14:33:23 EDT LOG: last completed transaction was at log time -2017-03-29 14:00:43.351333-04 -cp: cannot stat `archived_wals/00000002.history': No such file or -directory -2017-03-29 14:33:23 EDT LOG: selected new timeline ID: 2 -cp: cannot stat `archived_wals/00000001.history': No such file or -directory -2017-03-29 14:33:23 EDT LOG: archive recovery complete -2017-03-29 14:33:23 EDT LOG: MultiXact member wraparound protections are -now enabled -2017-03-29 14:33:23 EDT LOG: database system is ready to accept -connections -2017-03-29 14:33:23 EDT LOG: autovacuum launcher started -``` - -The tables that exist in the recovered database cluster are: - -```text -postgres=# \dt - List of relations -Schema | Name | Type | Owner ---------+----------------+-------+---------- -public | hr_rmt_t1_1356 | table | postgres -public | hr_rmt_t1_1358 | table | postgres -public | hr_rmt_t1_1400 | table | postgres -(3 rows) -``` - -Since recovery was up to and including 2017-03-29 14:01:00, the following tables created after 14:01 are not present: - -```text -public | hr_rmt_t1_1402 | table | postgres -public | hr_rmt_t1_1404 | table | postgres -public | hr_rmt_t1_1406 | table | postgres -``` - -The BART `RESTORE` operation stops WAL archiving by adding an `archive_mode = off` parameter at the very end of the `postgresql.conf` file. This last parameter in the file overrides any other previous setting of the same parameter in the file. Delete the last setting and restart the database server to start WAL archiving. - -```text -# Add settings for extensions here -archive_mode = off -``` diff --git a/product_docs/docs/bart/2.5.9/bart_ref/images/EDB_logo.png b/product_docs/docs/bart/2.5.9/bart_ref/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.5.9/bart_ref/images/edb.png b/product_docs/docs/bart/2.5.9/bart_ref/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.5.9/bart_ref/images/edb_logo.svg b/product_docs/docs/bart/2.5.9/bart_ref/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_ref/images/image2.png b/product_docs/docs/bart/2.5.9/bart_ref/images/image2.png deleted file mode 100644 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.5.9/bart_ref/index.mdx b/product_docs/docs/bart/2.5.9/bart_ref/index.mdx deleted file mode 100644 index 6a8817bd039..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_ref/index.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -navTitle: Reference Guide -title: "EDB Postgres Backup and Recovery Reference Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/index.html" ---- - -This guide acts as a quick reference for BART subcommands and provides comprehensive examples of the following BART operations: - -- Performing a full backup of database servers -- Performing a point-in-time recovery (PITR) on a remote PostgreSQL database server -- Restoring an incremental backup -- Restoring a database cluster with tablespaces -- Evaluating, marking, and deleting backups and incremental backups -- Configuring and operating local and remote database servers - -For detailed information about BART subcommands and operations, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The document is organized as follows: - -- See [Subcommands](01_bart_subcommands_examples/#using_bart_subcommands) to view BART subcommand examples. -- See [Examples](02_additional_examples/#examples) to view BART operations examples. -- See [Sample BART System](03_sample_bart_system_with_local_and_remote_database_servers/#a_sample_bart_system_with_local_and_remote_database_servers) to view examples of both local and remote database server configuration and operation. - -
- -bart_subcommands_examples additional_examples sample_bart_system_with_local_and_remote_database_servers conclusion - -
diff --git a/product_docs/docs/bart/2.5.9/bart_user/01_introduction.mdx b/product_docs/docs/bart/2.5.9/bart_user/01_introduction.mdx deleted file mode 100644 index 1212b2847bf..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/01_introduction.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Introduction" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" ---- - -The EDB Backup and Recovery Tool (BART) is an administrative utility that provides simplified backup and recovery management for multiple local or remote EDB Advanced Server and PostgreSQL database servers. - -BART provides the following features: - -- Support for complete, hot, physical backups of multiple Advanced Servers and PostgreSQL database servers -- Support for two types of backups – full base backups and block-level incremental backups -- Backup and recovery management of database servers on local or remote hosts -- A single, centralized catalog for backup data -- Retention policy support for defining and managing how long backups should be kept -- The capability to store the backup data in compressed format -- Verified backup data with checksums -- Backup information displayed in an easy-to-read format -- A simplified point-in-time recovery process - -This guide provides the following information about using BART: - -- an [overview](02_overview/#overview) of the BART components and concepts. -- [backup and recovery management process](03_using_bart/#using_bart). -- [using tablespaces](04_using_tablespaces/#using_tablespaces). - -For information about installing BART, see the *EDB Backup and Recovery Installation and Upgrade Guide*; for examples of BART operations and subcommand usage, see the *EDB Backup and Recovery Reference Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). - - - -## Conventions Used in this Guide - -The following is a list of conventions used throughout this document. - -- Much of the information in this document applies interchangeably to the PostgreSQL and EDB Advanced Server database systems. The term *Advanced Server* is used to refer to EDB Advanced Server. The term *Postgres* is used to generically refer to both PostgreSQL and Advanced Server. When a distinction needs to be made between these two database systems, the specific names, PostgreSQL or Advanced Server are used. - -- The installation directory of the PostgreSQL or Advanced Server products is referred to as `POSTGRES_INSTALL_HOME`: - - - For PostgreSQL Linux installations, this defaults to `/opt/PostgreSQL/` for version 10 and earlier. For later versions, the installation directory is `/var/lib/pgsql/`. - - For Advanced Server Linux installations performed using the interactive installer for version 10 and earlier, this defaults to `/opt/PostgresPlus/AS` or `/opt/edb/as`. For Advanced Server Linux installations performed with an RPM package, this defaults to `/usr/ppas-` or `/usr/edb/as`. For Advanced Server Linux installations performed with an RPM package for version 11 or later, this defaults to `/usr/edb/as`. - -## Restrictions on pg_basebackup - -BART takes full backups using the `pg_basebackup` utility program under the following conditions: - -- The backup is taken on a standby server. -- The `--with-pg_basebackup` option is specified with the `BACKUP` subcommand (see [Backup](03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup)). -- The number of thread count in effect is 1, and the `with-pg_basebackup` option is not specified with the `BACKUP` subcommand. -- Database servers can only be backed up using `pg_basebackup` utility program of the same or later version than the database server version. - -In the global section of the BART configuration file, the `pg_basebackup_path` parameter specifies the complete directory path to the `pg_basebackup` program. For information about the `pg_basebackup_path` parameter and the `thread_count`, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - -For information about `pg_basebackup`, see the [PostgreSQL Core Documentation](https://postgresql.org/docs/current/static/app-pgbasebackup.html). diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx deleted file mode 100644 index a3fe8894d09..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Incremental Backup Limitations and Requirements" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/incremental_backup_limitations_and_requirements.html" ---- - - - -The following limitations apply to incremental backup: - -- If you have restored a full or incremental backup, you must take a full backup before enabling incremental backup. -- If a standby node has been promoted to the role of a primary node, you must take a full backup before enabling incremental backup on the cluster. -- On a standby database server, you cannot take an incremental backup. - -You must meet the following requirements before implementing incremental backup: - -- You must create or select an operating system account to be used as the BART user account. - -- You must create or select the replication database user, which must be a superuser. - -- In the BART configuration file: - - - You must set the `cluster_owner` parameter to the Linux operating system user account that owns the database cluster directory from which incremental backups are to be taken. - - You must enable the `allow_incremental_backups` parameter. - -- A passwordless SSH/SCP connection must be established between the BART user account on the BART host and the `cluster_owner` user account on the database server. - - It must be noted that a passwordless SSH/SCP connection must be established even if BART and the database server are running on the same host and the BART user account and the `cluster_owner` user account are the same account. - -- In addition to the BART host (where the BART backup catalog resides), the BART package must also be installed on every remote database server on which incremental backups are to be restored. To restore an incremental backup, the `bart` program must be executable on the remote host by the remote user (the remote user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup). - -- When [restoring incremental backups on a remote database server](05_restoring_an_incremental_backup/#restoring-an-incremental-backup-on-a-remote-host), a passwordless SSH/SCP connection must be established from the BART user account on the BART host to the remote user on the remote host (the remote user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup). - -- Compression of archived WAL files in the BART backup catalog is not permitted for database servers on which incremental backups are to be taken. The `wal_compression` setting in the BART configuration file must be disabled for those database servers. - -- The incremental backup must be on the same timeline as the parent backup. The timeline changes after each recovery operation so an incremental backup cannot use a parent backup from an earlier timeline. - -For information about configuring these requirements, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -The following section provides an overview of the basic incremental backup concepts. diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx deleted file mode 100644 index 8183d4802bd..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Concept Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/concept_overview.html" ---- - - - -Using incremental backups involves the following sequence of steps: - -1. Configure BART, and enable and initiate archiving of WAL files to the `archive_path` in the same manner as done for full backups. - - The default `archive_path` is the BART backup catalog (`//archived_wals`). Using the `` parameter in the server section of the BART configuration file, you can specify the location where WAL files will be archived. - - For more information about the `archive_path` parameter and configuring BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -2. Take an initial full backup with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. - -3. Scan all WAL files produced by database servers on which incremental backups are to be taken. These WAL files are scanned once they have been archived to the `archive_path`. - - Each scanned WAL file results in a modified block map (MBM) file that records the location of modified blocks obtained from the corresponding WAL file. The BART WAL scanner program `bart-scanner` performs this process. - -4. Take incremental backups using the `BACKUP` subcommand with the `--parent` option to specify the backup identifier or name of a previous, full backup or an incremental backup. Any previous backup may be chosen as the parent as long as all backups belong to the same timeline. - -5. The incremental backup process identifies which WAL files may contain changes from when the parent backup was taken to the starting point of the incremental backup. The corresponding MBM files are used to locate and copy the modified blocks to the incremental backup directory along with other database cluster directories and files. Instead of backing up all, full relation files, only the modified blocks are copied and saved. In addition, the relevant MBM files are condensed into one consolidated block map (CBM) file that is stored with the incremental backup. - - Multiple block copier threads can be used to copy the modified blocks to the incremental backup directory. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting the `thread_count` parameter in the BART configuration file. See [Backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for information about using the `--thread-count` option with the `BACKUP` subcommand. - -6. Invoke the restore process for an incremental backup using the `RESTORE` subcommand in the same manner as restoring a full backup. The `-i` option specifies the backup identifier or name of the incremental backup to restore. The restore process begins by going back through the chain of past, parent incremental backups until the initial full backup starting the chain is identified. This full backup provides the initial set of directories and files to be restored to the location specified with the `-p` option. Each subsequent incremental backup in the chain is then restored. Restoration of an incremental backup uses its CBM file to restore the modified blocks from the incremental backup. - -The following sections provide some additional information on these procedures. diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx deleted file mode 100644 index 5264499e13e..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "WAL Scanning – Preparation for an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/wal_scanning_preparation_for_an_incremental_backup.html" ---- - - - -The WAL scanner program (`bart-scanner`) scans the WAL files created from the time of the parent backup up to the start of the incremental backup to determine which blocks have modified since the parent backup, and records the information in a file called the *modified block map (MBM) file*. One MBM file is created for each WAL file. - -The MBM file is stored in the directory where archived_wals will be stored, as specified in the `archive_path` parameter in the `bart.cfg` file. If the `archive_path` is not specified, the default `archived_wals` directory is: - -`//` - -Where: - -`` is the BART backup catalog parent directory specified in the global section of the BART configuration file. - -`` is the lowercase conversion of the database server name specified in the server section of the BART configuration file. - -The following code snippet is the content of the archive path showing the MBM files created for the WAL files. (The user name and group name of the files have been removed from the example to list the WAL files and MBM files in a more comparable manner): - -```text -[root@localhost archived_wals]# pwd -/opt/backup/acctg/archived_wals -[root@localhost archived_wals]# ls -l -total 131104 --rw------- 1 ... ... 16777216 Oct 12 09:38 000000010000000100000078 --rw------- 1 ... ... 16777216 Oct 12 09:38 000000010000000100000079 --rw------- 1 ... ... 16777216 Oct 12 09:38 00000001000000010000007A --rw------- 1 ... ... 16777216 Oct 12 09:35 00000001000000010000007B --rw------- 1 ... ... 16777216 Oct 12 09:38 00000001000000010000007C --rw------- 1 ... ... 16777216 Oct 12 09:39 00000001000000010000007D --rw------- 1 ... ... 16777216 Oct 12 09:42 00000001000000010000007E --rw------- 1 ... ... 16777216 Oct 12 09:47 00000001000000010000007F --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 0000000100000001780000280000000179000000.mbm --rw-rw-r-- 1 ... ... 684 Oct 12 09:49 000000010000000179000028000000017A000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017A000028000000017B000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017B000028000000017C000000.mbm --rw-rw-r-- 1 ... ...1524 Oct 12 09:49 00000001000000017C000028000000017D000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017D000028000000017E000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017E000028000000017F000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017F0000280000000180000000.mbm -``` - -MBM files have the suffix, `.mbm`. - -In preparation for any incremental backup, the WAL files should be scanned as soon as they are copied to the `archive_path`. Thus, the WAL scanner should be running as soon as the WAL files from the database cluster are archived to the `archive_path`. If the `archive_path` contains WAL files that have not yet been scanned, starting the WAL scanner begins scanning these files. If WAL file fails to be scanned (resulting in a missing MBM file), you can use the WAL scanner to specify an individual WAL file. - -Under certain conditions such as when the Network File System (NFS) is used to copy WAL files to the `archive_path`, the WAL files may have been missed by the WAL scanner program for scanning and creation of MBM files. Use the `scan_interval` parameter in the BART configuration file to initiate force scanning of WAL files in the `archive_path` to ensure MBM files are generated. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about the `scan_interval` parameter. - -See [Running the BART WAL Scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) for information about using the WAL scanner. diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx deleted file mode 100644 index 7cd01990da6..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Performing an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_an_incremental_backup.html" ---- - - - -The WAL files produced at the time of the parent backup up to the start of the incremental backup contain information about which blocks were modified during that time interval. That information is consolidated into an MBM file for each WAL file by the WAL scanner. - -The MBM files for the relevant WAL files are read, and the information is used to copy the modified blocks from the database cluster to the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file. When compared to a full backup, the number and sizes of relation files can be significantly less for an incremental backup. - -For comparison, the following is an abbreviated list of the files copied to the archived `base` subdirectory of a full backup for one database: - -```text -[root@localhost 14845]# pwd -/opt/backup/acctg/1476301238969/base/base/14845 -[root@localhost 14845]# ls -112 13182_vm 14740 16467 16615 2608_vm 2655 2699 2995 ... -113 13184 14742 16471 174 2609 2656 2701 2995_vm ... -1247 13186 14745 16473 175 2609_fsm 2657 2702 2996 ... -1247_fsm 13187 14747 16474 2187 2609_vm 2658 2703 2998 ... -1247_vm 13187_fsm 14748 16476 2328 2610 2659 2704 2998_vm ... -1249 13187_vm 14749 16477 2328_fsm 2610_fsm 2660 2753 2999 ... -1249_fsm 13189 14752 16479 2328_vm 2610_vm 2661 2753_fsm 2999_vm ... -1249_vm 13191 14754 16488 2336 2611 2662 2753_vm 3079 ... -1255 13192 14755 16490 2336_vm 2611_vm 2663 2754 3079_fsm ... - . - . - . -13182_fsm 14739 16465 16603 2608_fsm 2654 2696 2893_vm 3501_vm ... -``` - -In contrast, the following is the content of the archived `base` subdirectory of the same database from a subsequent incremental backup: - -```text -[root@localhost 14845]# pwd -/opt/backup/acctg/1476301835391/base/base/14845 -[root@localhost 14845]# ls -1247 1249 1259 16384 17006 2608 2610 2658 2663 2678 ... -1247_fsm 1249_fsm 1259_fsm 16387 17009 2608_fsm 2610_fsm 2659 2673 2679 ... -1247_vm 1249_vm 1259_vm 16389 17011 2608_vm 2610_vm 2662 2674 2703 ... -``` - -The information from the MBM files are consolidated into one file called a *consolidated block map* (CBM) file. During the restore operation for the incremental backup, the CBM file is used to identify the modified blocks to be restored for that backup. In addition, the incremental backup also stores other required subdirectories and files from the database cluster as is done for full backups. - -Before taking an incremental backup, an initial full backup must be taken with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. - -The syntax for taking a full backup is: - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - [ -z ] [ –c ] - [ --backup-name ] - [ --thread-count ] - [ { --with-pg_basebackup | --no-pg_basebackup } ] -``` - -The syntax for taking an incremental backup is: - -```text -bart BACKUP –s { | all } [ -F p] - [ --parent { | } ] - [ --backup-name ] - [ --thread-count ] - [ --check ] -``` - -You must specify the following before taking an incremental backup: - -- `-Fp` option for plain text format as incremental backup can only be taken in the plain text format. -- `--check` option to verify if the required MBM files are present in the `archived_wals` directory. The `--parent` option must be specified when the `--check` option is used. - -See [BACKUP](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for more information about using the `BACKUP` subcommand. diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx deleted file mode 100644 index c86914aa329..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Restoring an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restoring_an_incremental_backup.html" ---- - - - -Restoring an incremental backup may require additional steps depending upon the host on which the incremental backup is to be restored: - -- [Restoring an Incremental Backup on a BART Host](#restoring-an-incremental-backup-on-a-bart-host) - This section outlines restoring an incremental backup onto the same host where BART has been installed. -- [Restoring an Incremental Backup on a Remote Host](#restoring-an-incremental-backup-on-a-remote-host) - This section outlines restoring an incremental backup onto a remote host where BART has not been installed. - - - -## Restoring an Incremental Backup on a BART Host - -Specify a backup identifier or name, and include the `-i` option when invoking the `RESTORE` subcommand to restore an incremental backup. All `RESTORE` options may be used in the same manner as when restoring a full backup. See [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) command for more details. - -First, all files from the full backup from the beginning of the backup chain are restored. For each incremental backup, the CBM file is used to identify and restore blocks from the incremental backup. If there are new relations or databases identified in the CBM file, then relevant relation files are copied. If consolidated block map information is found indicating the drop of a relation or a database, then the relevant files are removed from the restore directory. Similarly, if there is any indication of a table truncation, then the related files are truncated. - -Also note that you can use the `-w` option of the `RESTORE` subcommand to specify a multiple number of parallel worker processes to stream the modified blocks to the restore host. - - - -## Restoring an Incremental Backup on a Remote Host - -Ensure the `bart` program is available on the remote host when restoring an incremental backup on a remote host; the invocation of the `RESTORE` subcommand for an incremental backup results in the execution of the `bart` program on the remote host to restore the modified blocks to their proper location. - -To restore an incremental backup onto a remote host where BART has not been installed, perform the following steps: - -**Step 1:** Install `BART` on the remote host to which an incremental backup is to be restored. - -No editing is needed in the `bart.cfg` file installed on the remote host. - -**Step 2:** Determine the Linux operating system user account on the remote host to be used as the remote user. This user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup. The remote user must be the owner of the directory where the incremental backup is to be restored on the remote host. By default, the user account is `enterprisedb` for Advanced Server or `postgres` for PostgreSQL. - -**Step 3:** Ensure a passwordless SSH/SCP connection is established from the BART user on the BART host to the remote user on the remote host. For information about creating a passwordless SSH/SCP connection, see the *EDB Backup and Recovery Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - -When restoring an incremental backup, specify the backup identifier or name of the incremental backup that will be restored. See the [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) documentation for more details. To view an example of restoring an incremental backup, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/index.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/index.mdx deleted file mode 100644 index 3e65e3b0056..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/01_block-level_incremental_backup/index.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Block-Level Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/block-level_incremental_backup.html" ---- - - - -This section describes the basic concepts of a block-level incremental backup (referred to as an incremental backup). An incremental backup is a unique functionality of BART. - -An incremental backup provides a number of advantages when compared to using a full backup: - -- The amount of time required to produce an incremental backup is generally less than a full backup, as modified relation blocks are saved instead of all full relation files of the database cluster. -- An incremental backup uses less disk space than a full backup. - -Generally, all BART features (such as retention policy management) apply to incremental backups and full backups. See [Managing Incremental Backups](../../03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups/#managing_incremental_backups) for more information. - -
- -incremental_backup_limitations_and_requirements concept_overview wal_scanning_preparation_for_an_incremental_backup performing_an_incremental_backup restoring_an_incremental_backup - -
diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/02_creating_a_backup_chain.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/02_creating_a_backup_chain.mdx deleted file mode 100644 index 644040d87f1..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/02_creating_a_backup_chain.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Creating a Backup Chain" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/creating_a_backup_chain.html" ---- - - - -A *backup chain* is the set of backups consisting of a full backup and all of its successive incremental backups. Tracing back on the parent backups of all incremental backups in the chain eventually leads back to that single, full backup. - -It is possible to have a *multi-forked* backup chain, which is two or more successive lines of incremental backups, all of which begin with the same, full backup. Thus, within the chain there is a backup that serves as the parent of more than one incremental backup. - -Since restoration of an incremental backup is dependent upon first restoring the full backup, then all successive incremental backups up to, and including the incremental backup specified by the `RESTORE` subcommand, it is crucial to note the following: - -- Deletion or corruption of the full backup destroys the entire backup chain. It is not possible to restore any of the incremental backups that were part of that chain. -- Deletion or corruption of an incremental backup within the chain results in the inability to restore any incremental backup that was added to that successive line of backups following the deleted or corrupted backup. The full backup and incremental backups prior to the deleted or corrupted backup can still be restored. - -The actions of retention policy management are applied to the full backup and all of its successive incremental backups within the chain in an identical manner as if they were one backup. Thus, use of retention policy management does not result in the breakup of a backup chain. - -See the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/) for examples of creating a backup chain and restoring an incremental backup. diff --git a/product_docs/docs/bart/2.5.9/bart_user/02_overview/index.mdx b/product_docs/docs/bart/2.5.9/bart_user/02_overview/index.mdx deleted file mode 100644 index 7b5b7e92fb3..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/02_overview/index.mdx +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: "Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview.html" ---- - - - -BART provides a simplified interface for the continuous archiving and point-in-time recovery method provided with Postgres database servers. This consists of the following processes: - -- Capturing a complete image of a database cluster as a full base backup or referred to simply as a *full backup*. -- Capturing a modified image of a database cluster called a *block-level incremental backup* or referred as *incremental backup*, which is similar to a full backup, but contains the modified blocks of the relation files that have been changed since a previous backup. -- Archiving the `Write-Ahead Log segments` (WAL files), which continuously record changes to be made to the database files. -- Performing *Point-In-Time Recovery* (PITR) to a specified transaction ID or timestamp with respect to a timeline using a full backup along with successive, [block-level incremental backups](01_block-level_incremental_backup/#block-level_incremental_backup) that reside in the same backup chain, and the WAL files. - -Detailed information regarding WAL files and point-in-time recovery is documented in the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). - -The general term *backup* refers to both full backups and incremental backups. - -When taking a full backup of a standby server, BART uses the PostgreSQL `pg_basebackup` utility program. However, it must be noted that for standby servers, you can only take a full backup, but cannot take an incremental or parallel backups. For information about standby servers, see the [PostgreSQL Documentation](https://www.postgresql.org/docs/current/static/high-availability.html). - -BART uses a centralized backup catalog, a single configuration file, and a command line interface controlling the necessary operations to simplify the management process. Reasonable defaults are automatically used for various backup and restore options. BART also performs the necessary recovery file configuration required for point-in-time recovery using its command line interface. - -BART also provides the following features to enhance backup management: - -- Automation of the WAL archiving command configuration. -- Usage of retention policies to evaluate, categorize, and delete obsolete backups. -- Compression of WAL files to conserve disk space. -- Customizable naming of backups to ease their usage. -- Easy access to comprehensive information about each backup. - -The key components of a BART installation are: - -- **BART Host.** The host system on which BART is installed. BART operations are invoked from this host system. The database server backups and archived WAL files are stored on this host as well. -- **BART User Account.** Linux operating system user account you choose to run BART. The BART user account owns the BART backup catalog directory. -- **BART Configuration File.** File in editable text format containing the configuration information that BART uses. -- **BART Backup Catalog.** File system directory structure containing all of the backups for the database servers that BART manages. It is also the default `archive_path` to store archived WAL files. -- **BART Backupinfo File.** File in text format containing information for a BART backup. A `backupinfo` file resides in each backup subdirectory within the BART backup catalog. -- **BART Command Line Utility Program.** Single, executable file named `bart`, which is used to manage all BART operations. -- **BART WAL Scanner Program.** Single, executable file named `bart-scanner`, which is used to scan WAL files to locate and record the modified blocks for incremental backups. - -Other concepts and terms referred to in this document include the following: - -- **Postgres Database Cluster.** Also commonly called the *data directory*, this is the file system directory where all of the data files related to a particular Postgres database server instance are stored. (Each specific running instance is identified by its host and port number when connecting to a database.) The database cluster is identified by the `–D` option when it is created, started, stopped, etc. by the `Postgres initdb` and `pg_ctl` commands. A full backup is a copy of a database cluster. - - The terms database cluster and database server are used somewhat interchangeably throughout this document, though a single database server can run multiple database clusters. - -- **Postgres User Account.** Linux operating system user account that runs the Advanced Server or PostgreSQL database server and owns the database cluster directory. - - - By default, the database user account is `enterprisedb` when Advanced Server is installed to support compatibility with Oracle databases. - - - By default, the database user account is `postgres` when Advanced Server is installed in PostgreSQL compatible mode. For a PostgreSQL database server, the default database user account is also `postgres`. - - The BART configuration parameter `cluster_owner` must be set to the database user account for each database server. - -- **Replication Database User.** For each database server that BART manages, a database superuser must be selected to act as the replication database user. This database user is used to connect to the database server when backups are taken. The database superusers created with an initial Postgres database server installation (`enterprisedb` or `postgres`) may be used for this purpose. The BART configuration parameter `user` must be set to this replication database user for each database server. - -- **Secure Shell (SSH)/Secure Copy (SCP).** Linux utility programs used to log into hosts (SSH) and copy files (SCP) between hosts. A valid user account must be specified that exists on the target host and in fact is the user account under which the SSH or SCP operations occur. - -For information on how all of these components are configured and used with BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -**Supported BART Operations** - -The following tables are not a conclusive list of the scenarios supported by BART, but instead provides an overview of some of the most common scenarios in both `pg_basebackup` (thread count=1) as well as parallel backup mode (thread count greater than 1). - -| | -Fp-xlog-method=fetch | -Fp-xlog-method=stream | -Ft-xlog-method=fetch | -Ft-xlog-method=stream | -| -------------------------------------------- | --------------------- | ---------------------- | --------------------- | ---------------------- | -| `Primary Database Server/Full backup` | Supported | Supported | Supported | Supported | -| `Primary Database Server/Incremental backup` | Supported | Supported | Not Supported | Not Supported | -| `Standby Database Server/Full backup` | Supported | Supported | Supported | Supported | -| `Standby Database Server/Incremental backup` | Not Supported | Not Supported | Not Supported | Not Supported | - -Backup - -| | Wal compression by BART | WAL scanner | -| -------------------------------------------- | ----------------------- | ----------- | -| `Primary Database Server/Full backup` | Supported | N/A | -| `Primary Database Server/Incremental backup` | Not Supported | N/A | -| `Standby Database Server/Full backup` | Supported | N/A | -| `Standby Database Server/Incremental backup` | Not Supported | N/A | - -Wal Archiving - -| | Wal compression = enabled | Wal compression = disabled | -| ------------------ | ------------------------- | -------------------------- | -| `Restore` | Supported | Supported | -| `Parallel restore` | Supported | Supported | - -Restore - -
- -block-level_incremental_backup creating_a_backup_chain - -
diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx deleted file mode 100644 index 8b5fdec0c09..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Performing a Restore Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_a_restore_operation.html" ---- - - - -The following steps describe the process of restoring a backup: - -**Step 1:** Use your system-specific command to shut down the database server. - -**Step 2:** Inspect the `pg_wal` subdirectory (inspect the `pg_xlog` subdirectory if you are using server version 9.6) of the data directory and save any WAL files that have not yet been archived to the `archive_path`. If there are files that have not been archived, save them to a temporary location. - -**Step 3:** If you want to restore to current data directory, it is recommended to make a copy of the current data directory and then delete all files and subdirectories under the data directory if you have enough extra space. If there is not enough space, then make a copy of `pg_wal` directory (or `pg_xlog` if you are using server version 9.6) until the server is successfully restored. - -If you want to restore to a new, empty directory, create the directory on which you want to restore the backed up database cluster. Ensure the data directory can be written to by the BART user account or by the user account specified by the `remote_host` configuration parameter, or by the `--remote-host` option of the `RESTORE` subcommand (if these are to be used). - -**Step 4:** Perform the same process for tablespaces as described in Step 3. The `tablespace_path` parameter in the BART configuration file must contain the tablespace directory paths to which the tablespace data files are to be restored. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about this parameter. - -**Step 5:** Identify the backup to use for the restore operation and obtain the backup ID or backup name. - -To use the latest backup, omit the `-i` option; the `RESTORE` subcommand uses that backup by default. The backups can be listed with the `SHOW-BACKUPS` subcommand. - -**Step 6:** Run the BART `RESTORE` subcommand. - -- Minimal recovery settings will be saved in the `postgresql.auto.conf` file and archive recovery will proceed only until consistency is reached, with no restoration of files from the archive. See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for detailed information about `Restore` subcommand. - -- If the `-c` option is specified or if the `copy_wals_during_restore` BART configuration parameter is enabled for this database server, then the following actions occur: - - - In addition to restoring the database cluster to the directory specified by the `-p restore_path` option, the archived WAL files of the backup are copied from the BART backup catalog to the subdirectory `restore_path/archived_wals`. - - If recovery settings are saved in the `postgresql.auto.conf` file, the command string set in the `restore_command` parameter retrieves the WAL files from this `archived_wals` subdirectory relative to the `restore_path` parent directory as: `restore_command = cp archived_wals/%f %p` - -You must ensure that valid options are specified when using the `RESTORE` subcommand. BART will not generate an error message if invalid option values or invalid option combinations are provided. BART will accept the invalid options and pass them to the `postgresql.auto.conf` file, which will then be processed by the database server when it is restarted. - -**Step 7:** Copy any saved WAL files from Step 2 to the `restore_path/pg_xlog` subdirectory. - -**Step 8:** Inspect the restored directories and data files of the restored database cluster in directory `restore_path`. - -All files and directories must be owned by the user account that you intend to use to start the database server. Recursively change the user and group ownership of the `restore_path` directory, its files, and its subdirectories if necessary. There must only be directory access privileges for the user account that will start the database server. No other groups or users can have access to the directory. - -**Step 9:** The `postgresql.auto.conf` file should be configured to recover only until the cluster reaches consistency. In either case, the settings may be modified as desired. - -**Step 10:** Disable WAL archiving at this point. The BART `RESTORE` subcommand adds `archive_mode = off` to the end of the `postgresql.conf` file. - -- If you want to restart the database server with WAL archiving enabled, ensure that this additional parameter is deleted. -- The original `archive_mode` parameter still resides in the `postgresql.conf` file in its initial location with its last setting. - -**Step 11:** Start the database server to initiate recovery. After completion, check the database server log file to ensure the recovery was successful. - -If the backup is restored to a different location than where the original database cluster resided, operations dependent upon the database cluster location may fail if supporting service scripts are not updated to reflect the location where the backup has been restored. For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). - -See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the BART `Restore` subcommand. - -An example of a restore operation is documented in the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx deleted file mode 100644 index caaaa89e7c0..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Point-In-Time Recovery Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/point_in_time_recovery_operation.html" ---- - - - -The following steps outline how to perform a point-in-time recovery operation for a database cluster: - -1. Use your system-specific command to shut down the database server. - -2. If you want to: - a. restore the database cluster and tablespace files to new, empty directories, create the new directories with the appropriate directory ownership and permissions. - b. reuse the existing database cluster directories, delete all the files and subdirectories in the existing directories. We strongly recommend that you make a copy of this data before deleting it. Be sure to save any recent WAL files in the `pg_wal` subdirectory ( `pg_xlog` subdirectory if you are using server version 9.6) that have not been archived to `archive_path`. - -3. Run the BART `SHOW-BACKUPS -s ` subcommand to list the backup IDs and backup names of the backups for the database server. You will need to provide the appropriate backup ID or backup name with the BART `RESTORE` subcommand, unless you intend to restore the latest backup in which case the `-i` option of the `RESTORE` subcommand for specifying the backup ID or backup name may be omitted. - -4. Run the BART `RESTORE` subcommand with the appropriate options. - - - The backup is restored to the directory specified by the `-p restore_path` option. - - - In addition, if the `RESTORE` subcommand `-c` option is specified or if the enabled setting of the `copy_wals_during_restore` BART configuration parameter is applicable to the database server, then the required archived WAL files from the `archive_path` are copied to the `restore_path/archived_wals` subdirectory. - - - Ensure the `restore_path` directory and all subdirectories and files in the `restore_path` are owned by the proper Postgres user account (for example, `enterprisedb` or `postgres`). Also ensure that only the Postgres user account has access permission to the `restore_path` directory. - - Use the `chown` command to make the appropriate adjustments to file permissions; for example, the following command changes the ownership of `restore_path` to `enterprisedb`: - - `chown -R enterprisedb:enterprisedb restore_path` - - The following command restricts access to `restore_path`: - - `chmod 700 restore_path` - -5. Copy any saved WAL files from Step 2 that were not archived to the BART backup catalog to the `restore_path/pg_wal` subdirectory (`pg_xlog` subdirectory if you are using server version 9.6). - -6. Identify the timeline ID you wish to use to perform the restore operation. - - The available timeline IDs can be identified by the first non-zero digit of the WAL file names reading from left to right. - -7. Verify that the `postgresql.auto.conf` file created in the directory specified with the `RESTORE` subcommand’s `-p ` option was generated with the correct recovery parameter settings. - - If the `RESTORE` subcommand `-c` option is specified or if the enabled setting of the `copy_wals_during_restore` BART configuration parameter is applicable to the database server, then the `restore_command` parameter retrieves the archived WAL files from the `/archived_wals` subdirectory that was created by the `RESTORE` subcommand, otherwise the `restore_command` retrieves the archived WAL files from the BART backup catalog. - -8. The BART `RESTORE` subcommand disables WAL archiving in the restored database cluster. If you want to immediately enable WAL archiving, modify the `postgresql.conf` file by deleting the `archive_mode = off` parameter that BART appends to the end of the file. - -9. Start the database server, which will then perform the point-in-time recovery operation if recovery settings are saved in the `postgresql.auto.conf` file. - -For a detailed description of the `RESTORE` subcommand, see [Basic BART Subcommand Usage](../03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage). An example of a Point-in-Time Recovery operation is documented in the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the `Restore` subcommand. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/index.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/index.mdx deleted file mode 100644 index 4cb9c779397..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/01_bart_management_overview/index.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "BART Management Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/bart_management_overview.html" ---- - - - -After configuring BART, you can begin the backup and recovery management process. The following steps will help you get started: - -1. Run the `CHECK-CONFIG` subcommand without the `-s` option. When the `CHECK-CONFIG` subcommand is used without specifying the `-s` option, it checks the parameters in the global section of the BART configuration file. -2. Run the `INIT` subcommand (if you have not already done so) to finish creation of the BART backup catalog, which results in the complete directory structure to which backups and WAL files are saved. This step must be done before restarting the database servers with enabled WAL archiving, otherwise the copy operation in the `archive_command` parameter of the `postgresql.conf` file or the `postgresql.auto.conf` file fails due to the absence of the target archive directory. When the directory structure is complete, the `archived_wals` subdirectory should exist for each database server. -3. Start the Postgres database servers with archiving enabled. Verify that the WAL files are appearing in the `archive_path`. The archiving frequency is dependent upon other `postgresql.conf` configuration parameters. Check the Postgres database server log files to ensure there are no archiving errors. Archiving should be operational before taking a backup in order to ensure that the WAL files that may be created during the backup process are archived. -4. Start the WAL scanner if you intend to take incremental backups. Since the WAL scanner processes the WAL files copied to the `archive path`, it is advantageous to commence the WAL scanning as soon as the WAL files begin to appear in the `archive_path` in order to keep the scanning in pace with the WAL archiving. -5. Run the BART `CHECK-CONFIG` subcommand for each database server with the `-s` option specifying the server name. This ensures the database server is properly configured for taking backups. -6. Create a full backup for each database server. The full backup establishes the starting point of when point-in-time recovery can begin and also establishes the initial parent backup for any incremental backups to be taken. - -There are now a number of other BART management processes you may perform: - -- Execute the `BACKUP` subcommand to create additional full backups or incremental backups. -- Use the `VERIFY-CHKSUM` subcommand to verify the checksum of the full backups. -- Display database server information with the `SHOW-SERVERS` subcommand. -- Display backup information with the `SHOW-BACKUPS` subcommand. -- Compress the archived WAL files in the `archive_path` by enabling WAL compression in the BART configuration file and then invoking the `MANAGE` subcommand. -- Determine and set the retention policy for backups in the BART configuration file. -- Establish the procedure for using the `MANAGE` subcommand to enforce the retention policy for backups. This may include using `cron` jobs to schedule the `MANAGE` subcommand. - -
- -performing_a_restore_operation point_in_time_recovery_operation - -
diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx deleted file mode 100644 index 7169d6f7bb6..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Overview - Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview_managing_backups_using_a_retention_policy.html" ---- - - - -The BART retention policy results in the categorization of each backup in one of three statuses – *active*, *obsolete*, and *keep*. - -- **Active.** The backup satisfies the retention policy applicable to its server. Such backups would be considered necessary to ensure the recovery safety for the server and thus should be retained. -- **Obsolete.** The backup does not satisfy the retention policy applicable to its server. The backup is no longer considered necessary for the recovery safety of the server and thus can be deleted. -- **Keep.** The backup is to be retained regardless of the retention policy applicable to its server. The backup is considered vital to the recovery safety for the server and thus should not be deleted for an indefinite period of time. - -There are two types of retention policies - redundancy retention policy and recovery window retention policy. - -- **Redundancy Retention Policy** - The [redundancy retention policy](03_setting_the_retention_policy/#redundancy-retention-policy) relies on a specified, maximum number of most recent backups to retain for a given server. When the number of backups exceeds that maximum number, the oldest backups are considered obsolete (except for backups marked as keep). -- **Recovery Window Retention Policy** - The [recovery window retention policy](03_setting_the_retention_policy/#recovery-window-retention-policy) relies on a time frame (the recovery window) for when a backup should be considered active. The boundaries defining the recovery window are the current date/time (the ending boundary of the recovery window) and the date/time going back in the past for a specified length of time (the starting boundary of the recovery window). - - If the date/time the backup was taken is within the recovery window (that is, the backup date/time is on or after the starting date/time of the recovery window), then the backup is considered active, otherwise it is considered obsolete (except for backups marked as keep). - - Thus, for the recovery window retention policy, the recovery window time frame dynamically shifts, so the end of the recovery window is always the current date/time when the `MANAGE` subcommand is run. As you run the `MANAGE` subcommand at future points in time, the starting boundary of the recovery window moves forward in time. At some future point, the date/time of when a backup was taken will be earlier than the starting boundary of the recovery window. This is when an active backup’s status will be considered obsolete. - - You can see the starting boundary of the recovery window at any point in time by running the `SHOW-SERVERS` subcommand. The `RETENTION POLICY` field of the `SHOW-SERVERS` subcommand displays the starting boundary of the recovery window. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx deleted file mode 100644 index 047552d0a9e..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Marking the Backup Status" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/marking_the_backup_status.html" ---- - - - -When a backup is initially created with the `BACKUP` subcommand, it is always recorded with active status. Use the `MANAGE` subcommand to evaluate if the backup status should be changed to obsolete in accordance with the retention policy. You can review the current status of your backups with the `SHOW-BACKUPS` subcommand. - -Active backups are evaluated and also marked (that is, internally recorded by BART) as obsolete only when the `MANAGE` subcommand is invoked either with no options or with only the `-s` option. - -Once a backup has been marked as obsolete, you cannot change it back to active unless you perform the following steps: - -- Use the `MANAGE` subcommand with the `-c` option along with the backup identifier or name with the `-i` option. To keep this particular backup indefinitely, use `-c keep`, otherwise use `-c nokeep`. -- If you use the `-c nokeep` option, the backup status is changed back to active. When the `MANAGE` subcommand is used the next time, the backup is re-evaluated to determine if its status needs to be changed back to obsolete based on the current retention policy in the BART configuration file. - -After setting the `retention_policy` parameter and running the `MANAGE` subcommand if you change the `retention_policy` parameter, the current, marked status of the backups are probably inconsistent with the new `retention_policy` setting. To modify the backup status to be consistent with the new `retention_policy` setting, you need to run the `MANAGE` subcommand with: - -- the `-c nokeep` option to change the obsolete status to active status if there are backups currently marked as obsolete that would no longer be considered obsolete under a new retention policy. You can also specify the `-i all` option to change all backups back to active status, including those currently marked as keep. -- no options or with only the `-s` option to reset the marked status based on the new `retention_policy` setting in the BART configuration file. - -See [MANAGE](../03_basic_bart_subcommand_usage/07_manage/#manage) for usage information for the `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx deleted file mode 100644 index a4396239bfe..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "Setting the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/setting_the_retention_policy.html" ---- - - - -The retention policy is determined by the `retention_policy` parameter in the BART configuration file. It can be applied globally to all servers, but each server can override the global retention policy with its own. For information about creating a global retention policy and an individual database server retention policy, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -There are two types of retention policies - redundancy retention policy and the recovery window retention policy as described in the following sections. - - - -## Redundancy Retention Policy - -To use the redundancy retention policy, set `retention_policy = max_number BACKUPS` where `max_number` is a positive integer designating the maximum number of most recent backups. - -**Additional Restrictions:** - -- The keyword `BACKUPS` must always be specified in plural form (for example, `1 BACKUPS`). -- BART will accept a maximum integer value of 2,147,483,647 for `max_number`; however, you should use a realistic, practical value based on your system environment. - -The redundancy retention policy is the default type of retention policy if all keywords `BACKUPS`, `DAYS`, `WEEKS`, and `MONTHS` following the `max_number` integer are omitted as shown by the following example: - -`retention_policy = 3` - -In the following example, the redundancy retention policy setting considers the three most recent backups as the active backups. Any older backups, except those marked as `keep`, are considered obsolete: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The `SHOW-SERVERS` subcommand displays the `3 Backups` redundancy retention policy in the `RETENTION POLICY` field: - -```bash --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 3 Backups -DISK UTILIZATION : 627.04 MB -NUMBER OF ARCHIVES : 25 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/acctg/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Accounting" -``` - - - -## Recovery Window Retention Policy - -To use the recovery window retention policy, set the `retention_policy` parameter to the desired length of time for the recovery window in one of the following ways: - -- Set to `max_number DAYS` to define the start date/time recovery window boundary as the number of days specified by `max_number` going back in time from the current date/time. -- Set to `max_number WEEKS` to define the start date/time recovery window boundary as the number of weeks specified by `max_number` going back in time from the current date/time. -- Set to `max_number MONTHS` to define the start date/time recovery window boundary as the number of months specified by `max_number` going back in time from the current date/time. - -**Additional Restrictions:** - -- The keywords `DAYS`, `WEEKS`, and `MONTHS` must always be specified in plural form (for example, `1 DAYS`, `1 WEEKS`, or `1 MONTHS`). -- BART will accept a maximum integer value of `2,147,483,647` for `max_number`, however, a realistic, practical value based on your system environment must always be used. - -A backup is considered active if the date/time of the backup is equal to or greater than the start of the recovery window date/time. - -You can view the actual, calculated recovery window by: - -- Invoking the `MANAGE` subcommand in debug mode, along with the `-n` option. -- Using the `SHOW-SERVERS` subcommand. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx deleted file mode 100644 index def779a4026..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: "Managing the Backups Based on the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_the_backups_based_on_the_retention_policy.html" ---- - - - -The [MANAGE](../03_basic_bart_subcommand_usage/07_manage/#manage) subcommand is used to evaluate and categorize backups according to the retention policy set in the BART configuration file. When a backup is first created with the `BACKUP` subcommand, it is `active`. You can use the `MANAGE` subcommand to change the status of an active backup to `obsolete`. Obsolete backups can then be deleted. - -This section covers following aspects of backup management: - -- The rules for [deleting backups](#deletions_permitted_under_retention_policy) depending upon the backup status and the subcommand used. -- The process to retain a backup indefinitely by [marking it as keep](#marking-backups-for-indefinite-keep-status). This section also provides information about resetting backups status (that are marked as `obsolete` and `keep`) back to active status. -- The general process for [evaluating, marking, and then deleting obsolete backups](#evaluating-marking-and-deleting-obsolete-backups). - - - -## Deletions Permitted Under a Retention Policy - -This section describes how and under what conditions backups may be deleted under a retention policy. - -You must use the `MANAGE` subcommand to delete obsolete backups. Use the `DELETE` subcommand only for special administrative purposes. - -The deletion behavior of the `MANAGE` subcommand and the `DELETE` subcommand are based on different aspects of the retention policy. - -- The `MANAGE` subcommand deletion relies solely upon how a backup status is currently marked (that is, internally recorded by BART). The current setting of the `retention_policy` parameter in the BART configuration file is ignored. -- The `DELETE` subcommand relies solely upon the current setting of the `retention_policy` parameter in the BART configuration file. The current active, obsolete, or keep status of a backup is ignored. - -The specific deletion rules for the `MANAGE` and `DELETE` subcommands are as follows: - -- `MANAGE` subcommand: The `MANAGE` subcommand with the `-d` option can only delete backups marked as obsolete. This deletion occurs regardless of the current `retention_policy` setting in the BART configuration file. The deletion of backups relies on the last occasion when the backups have been marked. -- `DELETE` subcommand: - - - Under a redundancy retention policy currently set with the `retention_policy` parameter in the BART configuration file, any backup regardless of its marked status, can be deleted with the `DELETE` subcommand when the backup identifier or name is specified with the `-i` option and if the current total number of backups for the specified database server is greater than the maximum number of redundancy backups currently specified with the `retention_policy` parameter. - - If the total number of backups is less than or equal to the specified, maximum number of redundancy backups, then no additional backups can be deleted using `DELETE` with the `-i backup` option. - - - Under a recovery window retention policy currently set with the `retention_policy` parameter in the BART configuration file, any backup regardless of its marked status, can be deleted with the `DELETE` subcommand when the backup identifier or name is specified with the `-i` option, and if the backup date/time is not within the recovery window currently specified with the `retention_policy` parameter. If the backup date/time is within the recovery window, then it cannot be deleted using `DELETE` with the `-i backup` option. - - - Invoking the `DELETE` subcommand with the `-i all` option results in the deletion of all backups regardless of the retention policy and regardless of whether the status is marked as active, obsolete, or keep. - -The following table summarizes the deletion rules of backups according to their marked status. An entry of `Yes` indicates the backup may be deleted under the specified circumstances. An entry of `No` indicates that the backup may not be deleted. - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OperationRedundancy Retention PolicyRecovery Window Retention Policy
ActiveObsoleteKeepActiveObsoleteKeep
MANAGE –dNoYesNoNoYesNo
DELETE –i *backup* -

Yes

-

(see Note 1)

- 		-

Yes

-

(see Note 1)

- 		-

Yes

-

(see Note 1_)

- 		-

Yes

-

(see Note 2

- 		-

Yes

(see Note 2 - 		-

Yes

(see Note 2) -
DELETE –i allYesYesYesYesYesYes
- - - -!!! Note - Redundancy Retention Policy (Note 1) : Deletion occurs only if the total number of backups for the specified database server is greater than the specified, maximum number of redundancy backups currently set with the `redundancy_policy` parameter in the BART configuration file. - - - -!!! Note - Recovery Window Retention Policy (Note 2): Deletion occurs only if the backup is not within the recovery window currently set with the `redundancy_policy` parameter in the BART configuration file. - - - -## Marking Backups for Indefinite Keep Status - -There may be certain backups that you wish to keep for an indefinite period of time and do not wish to delete based upon the retention policy applied to the database server. Such backups can be marked as `keep` to exclude them from being marked as obsolete. Use the `MANAGE` subcommand with the `-c keep` option to retain such backups indefinitely. - - - -## Evaluating, Marking, and Deleting Obsolete Backups - -When the `MANAGE` subcommand is invoked, BART evaluates active backups: - -- If you include the `-s` option when invoking the `MANAGE` subcommand, BART evaluates backups for the database server. -- If you include the `-s all` option when invoking the `MANAGE` subcommand, BART evaluates backups for all database servers. -- If the `-s` option is omitted, the command evaluates the current number of backups for the database server based on the redundancy retention policy or the current date/time for a recovery window retention policy. - -!!! Note - The status of backups currently marked as `obsolete` or `keep` is not changed. To re-evaluate such backups and then classify them, their status must first be reset to `active` with the `MANAGE -c nokeep` option. See [Marking the Backup Status](02_marking_the_backup_status/#marking_the_backup_status) for more information. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) to review examples of how to evaluate, mark, and delete backups using a redundancy retention policy and recovery window retention policy, as well as examples of `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx deleted file mode 100644 index c69f6b09086..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Managing Incremental Backups" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_incremental_backups.html" ---- - - - -The following section summarizes how retention policy management affects incremental backups. - -- The retention policy rules are applied to full backups. - - A redundancy retention policy uses the number of full backups to determine if a backup is obsolete. Incremental backups are excluded from the comparison count against the `retention_policy` setting for the maximum number of backups. - - A recovery window retention policy uses the backup date/time of any full backups to determine if a backup is obsolete. The backup date/time of any successive incremental backups in the chain are ignored when comparing with the recovery window. -- The retention status of all incremental backups in a chain is set to the same status applied to the full backup of the chain. -- The actions applied by the `MANAGE` and `DELETE` subcommands on a full backup are applied to all incremental backups in the chain in the same manner. -- Thus, a backup chain (that is, the full backup and all its successive incremental backups) are treated by retention policy management as if they are all one, single backup. - - The status setting applied to the full backup is also applied to all incremental backups in its chain. - - If a full backup is marked as obsolete and then deleted according to the retention policy, all incremental backups in the chain are also marked obsolete and then deleted as well. - -The following are some specific points regarding the `MANAGE` and `DELETE` subcommands on incremental backups. - -- `MANAGE` subcommand: - - When the `MANAGE` subcommand is invoked, the status applied to the full backup is also applied to all successive incremental backups in the chain. - - The `MANAGE` subcommand with the `-c { keep | nokeep}` option cannot specify the backup identifier or backup name of an incremental backup with `-i` backup option. The `-i` backup option can only specify the backup identifier or backup name of a full backup. - - You can also use the `-i` all option to take a backup of all backups. When the `MANAGE` subcommand with the `-c { keep | nokeep }` option is applied to a full backup, the same status change is made to all incremental backups in the chain. -- `DELETE` subcommand: - - The `DELETE` subcommand with the `-s server -i` backup option specifies the backup identifier or backup name of an incremental backup in which case that incremental backup along with all its successive incremental backups are deleted, thus shortening that backup chain. - -## Using a Redundancy Retention Policy with Incremental Backups - -When a [redundancy retention policy](03_setting_the_retention_policy/#redundancy-retention-policy) is used and the `MANAGE` subcommand is invoked, the status of the oldest `active` full backup is changed to `obsolete` if the number of full backups exceeds the maximum number specified by the `retention_policy` parameter in the BART configuration file. - -!!! Note - When a full backup is changed from `active` to `obsolete`, all successive incremental backups in the chain of the full backup are also changed from `active` to `obsolete`. - -When determining the number of backups that exceeds the number specified by the `retention_policy` parameter, only full backups are counted for the comparison. Incremental backups are not included in the count for the comparison against the `retention_policy` parameter setting. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a redundancy retention policy is in effect. - -## Using a Recovery Window Retention Policy with Incremental Backups - -If the `MANAGE` command is invoked when BART is configured to use a [recovery window retention policy](03_setting_the_retention_policy/#recovery-window-retention-policy), the status of `active` full backups are changed to `obsolete` if the date/time of the full backup is outside of the recovery window. - -!!! Note - If a full backup is changed from `active` to `obsolete`, all successive incremental backups in the chain of the full backup are also changed from `active` to `obsolete`. - -The status of an incremental backup is changed to `obsolete` regardless of whether or not the date/time of when the incremental backup was taken still lies within the recovery window. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a recovery window retention policy is in effect. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx deleted file mode 100644 index aff92bbd6a5..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_backups_using_a_retention_policy.html" ---- - - - -Over the course of time when using BART, the number of backups can grow significantly. This ultimately leads to a large consumption of disk space unless an administrator periodically performs the process of deleting the oldest backups that are no longer needed. This process of determining when a backup is old enough to be deleted and then actually deleting such backups can be done and automated with the following basic steps: - -1. Determine and set a retention policy in the BART configuration file. A *retention policy* is a rule that determines when a backup is considered obsolete. The retention policy can be applied globally to all servers, but each server can override the global retention policy with its own. - -2. Use the `MANAGE` subcommand to categorize and manage backups according to the retention policy. - -3. Create a cron job to periodically run the `MANAGE` subcommand to evaluate the backups and then list and/or delete the obsolete backups. - - Retention policy management applies differently to incremental backups than to full backups. See [Managing Incremental Backups](05_managing_incremental_backups/#managing_incremental_backups) for information about how retention policy management is applied to each backup type. - - The following sections describe how retention policy management generally applies to backups, and its specific usage and effect on full backups. - -
- -overview_managing_backups_using_a_retention_policy marking_the_backup_status setting_the_retention_policy managing_the_backups_based_on_the_retention_policy managing_incremental_backups - -
diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx deleted file mode 100644 index f12dd038edd..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/check_config.html" ---- - - - -The `CHECK-CONFIG` subcommand checks the parameter settings in the BART configuration file as well as the database server configuration for which the `-s` option is specified. - -**Syntax:** - -`bart CHECK-CONFIG [ –s server_name ]` - -The following table describes the option. - -| Options | Description | -| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s ` or `--server ` | `server_name` is the name of the database server to be checked for proper configuration. If the option is omitted, the settings of the global section of the BART configuration file are checked. | - -- When the `-s` option is omitted, the global section \[BART] parameters including `bart_host`, `backup_path`, and `pg_basebackup_path` are checked. -- When the `-s` option is specified, the server section parameters are checked. In addition, certain database server `postgresql.conf` parameters are also checked, which include the following: - - The `cluster_owner` parameter must be set to the user account owning the database cluster directory. - - A passwordless SSH/SCP connection must be set between the BART user and the user account specified by the `cluster_owner` parameter. - - A database superuser must be specified by the BART `user` parameter. - - The `pg_hba.conf` file must contain a replication entry for the database superuser specified by the BART `user` parameter. - - The `archive_mode` parameter in the `postgresql.conf` file must be enabled. - - The `archive_command` parameter in the `postgresql.auto.conf` or the `postgresql.conf` file must be set. - - The `allow_incremental_backups` parameter in the BART configuration file must be enabled for database servers for which incremental backups are to be taken. - - Archiving of WAL files to the `archive_path` must be in process. - - The WAL scanner program must be running. - -The `CHECK-CONFIG` subcommand displays an error message if the required configuration is not properly set. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx deleted file mode 100644 index d8cdeed8126..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/init.html" ---- - - - -The `INIT` subcommand is used to create the BART backup catalog directory, rebuild the BART `backupinfo` file, and set the `archive_command` in the PostgreSQL server based on the `archive_command` setting in the `bart.cfg` file. - -!!! Note - If the `archive_mode` configuration parameter is set to `off`, then the `-o` option must be used to set the Postgres `archive_command` using the BART `archive_command` parameter in the BART configuration file even if the `archive_command` is not currently set in `postgresql.conf` nor in `postgresql.auto.conf` file. - -**Syntax:** - -```text -bart INIT [ –s { | all } ] [ -o ] - [ -r [ -i { | | all } ] ] - [--no-configure] -``` - -All subcommand options are generally specified in lowercase. The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`

`--server { \| all }` | `server_name` is the name of the database server to which the `INIT` actions are to be applied. If `all` is specified or if the option is omitted, the actions are applied to all servers. | -| `-o`

`--override` | Overrides the existing, active Postgres `archive_command` configuration parameter setting in the `postgresql.conf` file or the `postgresql.auto.conf` file using the BART `archive_command` parameter in the BART configuration file. The `INIT` generated archive command string is written to the `postgresql.auto.conf` file. | -| `-r`

`--rebuild` | Rebuilds the backupinfo file (a text file named `backupinfo`) located in each backup subdirectory. This option is only intended for recovering from a situation where the backupinfo file has become corrupt.
If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild that `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is an integer, backup identifier and `` is the user-defined alphanumeric name for the backup. If `all` is specified or if the option is omitted, the backupinfo files of all backups for the database servers specified by the `-s` option are recreated. The `-i` option can only be used with the `-r` option. | -| `--no-configure` | Prevents the `archive_command` from being set in the PostgreSQL server. | - -**Archive Command Setting** - -After the `archive_command` is set, you need to either restart the PostgreSQL server or reload the configuration file in the PostgreSQL server based on the following conditions. - -- If the `archive_mode` is set to `off` and `archive_command` is not set in the PostgreSQL server, the `archive_command` is set based on the `archive_command` setting in the `bart.cfg` and also sets the `archive_mode` to `on`. In this case, you need to restart the PostgreSQL server using `pg_ctl restart` -- If the `archive_mode` is set to `on` and `archive_command` is not set in the PostgreSQL server, the `archive_command` is set based on the `archive_command` setting in the `bart.cfg`. In this case, you need to reload the configuration in the PostgreSQL server using `pg_reload_conf()` or `pg_ctl reload`. -- If the `archive_mode` is set to `off` and `archive_command` is already set in the PostgreSQL server, the `archive_mode` is set to on. In this case, you need to restart the PostgreSQL server using `pg_ctl restart` -- If the `archive_mode` is set to `on` and `archive_command` is already set in the PostgreSQL server, then the `archive_command` is not set unless `-o` option is specified. diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx deleted file mode 100644 index aa12cd957e2..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/backup.html" ---- - - - -The `BACKUP` subcommand is used to create a full backup or an incremental backup. - -**Syntax for full backup:** - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - [ -z ] [ –c ] - [ --backup-name ] - [ --thread-count ] - [ { --with-pg_basebackup | --no-pg_basebackup } ] -``` - -!!! Note - While taking a backup, if a file (for example, database server log file) exceeding 1 GB size is stored in the `$PGDATA` directory, the backup will fail. To avoid such backup failure, you need to store large files (exceeding 1 GB) outside the `$PGDATA` directory. - -**Syntax for incremental Backup:** - -```text -bart BACKUP –s { | all } [ -F p] - [ --parent { | } ] - [ --backup-name ] - [ --thread-count ] - [ --check ] -``` - -!!! Note - To take an [incremental backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup), you must take a full backup first followed by incremental backup. - -**Please Note:** - -- While a `BACKUP` subcommand is in progress, no other subcommands must be invoked. Any subcommands invoked while a backup is in progress will skip and ignore the backups. - -- For full backup, the target default format is a tar file, whereas for incremental backup, only plain format must be specified. - -- The backup is saved in the `//` directory, where `` is the value assigned to the `` parameter in the BART configuration file, `` is the lowercase name of the database server as listed in the configuration file, and `` is a backup identifier assigned by BART to the particular backup. - -- MD5 checksums of the full backup and any user-defined tablespaces are saved as well for tar backups. - -- Before performing the backup, BART checks to ensure if there is enough disk space to completely store the backup in the BART backup catalog. - -- In the `postgresql.conf` file, ensure the `wal_keep_segments` configuration parameter is set to a sufficiently large value. A low setting of the `wal_keep_segments` configuration parameter may result in the deletion of some WAL files before the BART `BACKUP` subcommand saves them to the `archive_path`. For information about the `wal_keep_segments` parameter, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/runtime-config-replication.html). - -- In the BART configuration file, setting `xlog_method=stream` will instruct the server to stream the transaction log in parallel with creation of the backup for a specific database server; otherwise the transaction log files are collected upon completion of the backup. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details about database server setting. - - !!! Note - If the transaction log streaming method is used, the `-Fp` option for a plain text backup format must be specified with the `BACKUP` subcommand. - -- When you use BART to take a backup of PostgreSQL server, multiple backups can be taken simultaneously and if a backup is interrupted, the backup mode is terminated automatically without the need to run `pg_stop_backup()` command manually to terminate the backup. - -**Options** - -Along with the `BACKUP` subcommand, specify the following option: - -| Options | Description | -| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { server_name \| all }`
`--server { server_name \| all }` | `server_name` is the database server name to be backed up as specified in the BART configuration file. If `all` is specified, all servers are backed up. This option is mandatory.
If `all` is specified, and a connection to a database server listed in the BART configuration file cannot be opened, the backup for that database server is skipped, but the backup operation continues for the other database servers. | - -Specify the following options as required. If you do not specify any of the following options, the backup is created using default settings. - -| Options | Description | -| -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-F { p \| t }`
`--format { p \| t }` | Specify this option to provide the backup file format. Use `p` for plain text or `t` for tar. If the option is omitted, the default is tar format.
For taking incremental backups, the option `-Fp` must be specified. | -| `-z`
`--gzip` | This is applicable only for full backup. Specify this option to use gzip compression on the tar file output using the default compression level. This option is applicable only for the tar format. | -| `-c `
`--compress-level ` | This is applicable only for full backup. Specify this option to use the gzip compression level on the tar file output. `compression_level` is a digit from 1 through 9, with 9 being the best compression. This option is applicable only for the tar format. | -| `--parent { backup_id \| backup_name }` | Specify this option to take an incremental backup. `` is the backup identifier of a parent backup. `` is the user-defined alphanumeric name of a parent backup.
The parent is a backup taken prior to the incremental backup. The parent backup can be either a full backup or an incremental backup.
The option `–Fp` must be specified since an incremental backup can only be taken in plain text format.
An incremental backup cannot be taken on a standby database server. See [Block-Level Incremental Backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup) for additional information on incremental backups. | -| `--backup-name ` | Specify this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
The backup name may include the following variables to be substituted by the timestamp values when the backup is taken: 1) `%year` – 4-digit year, 2) `%month` – 2-digit month, 3) `%day` – 2-digit day, 4) `%hour` 2-digit hour, 5) `%minute` – 2-digit minute, and 6) `%second` – 2-digit second.
To include the percent sign (`%`) as a character in the backup name, specify `%%` in the alphanumeric string.
If the backup name contains space characters (i.e. more than one word) or when referenced with the option `-i` by other subcommands (such as `restore`), enclose the string in single quotes or double quotes. See [backup name examples](#backup_name_examples).
If the `--backup-name` option is not specified, and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to use the number of worker threads to run in parallel to copy blocks for a backup.
If the option `--thread-count` is omitted, then the `thread_count` parameter in the BART configuration file applicable to this database server is used.
If the option `--thread-count` is not enabled for this database server, then the `thread_count` setting in the global section of the BART configuration file is used.
If the option `--thread-count` is not set in the global section as well, the default number of threads is 1.
If parallel backup is run with N number of worker threads, then it will initiate N+ 1 concurrent connections with the server.
Thread count will not be effective if backup is taken on a standby server.
For more information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/) | -| `--with-pg_basebackup` | This is applicable only for full backup. Specify this option to use `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the option `--with-pg_basebackup` is specified with the `BACKUP` subcommand. | -| `--no-pg_basebackup` | This is applicable only for full backup. Specify this option if you do not want `pg_basebackup` to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the option `--no-pg_basebackup` is specified with the `BACKUP` subcommand. | -| `--check` | This is applicable only for incremental backup. Specify this option to verify if the required MBM files are present in the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file before taking an incremental backup. The option `--parent` must be specified when the option `--check` is used. An actual incremental backup is not taken when the option `--check` is specified. | - - - -**Backup Name Examples** - -The following examples demonstrate using the `--backup-name` clause: - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year -MONTH = %month DAY = %day" -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year -MONTH = %month DAY = %day %%" -./bart show-backups -s ppas12 -i "test backup" -``` - -**Error messages** - -The following table lists the error messages that may be encountered when using the `BACKUP` subcommand: - -| error message | Cause | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `edb@localhost bin]$ ./bart backup -s mktg -Ft`

`WARNING: xlog_method is empty, defaulting to global policy`

`ERROR: backup failed for server 'mktg'`

`free disk space is not enough to backup the server 'mktg'`

`space available 13.35 GB, approximately required 14.65 GB` | Insufficient free disk space. | -| `ERROR: backup failed for server 'mktg'`

`command failed with exit code 1`

`pg_basebackup: could not get transaction log end position from server: ERROR: requested WAL segment 00000001000000D50000006B has already been removed` | The wal_keep_segments configuration parameter is not set to a sufficiently large value in the postgresql.conf file. | -| `ERROR: backup failed for server 'mktg'`

`connection to the server failed: could not connect to server: Connection refused`

`Is the server running on host "172.16.114.132" and accepting`

`TCP/IP connections on port 5444?` | A connection to a database server listed in the BART configuration file fails. As a result the backup for that database server is skipped, but the backup operation continues for other database servers | diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx deleted file mode 100644 index 778efd3d4d6..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_servers.html" ---- - - - -The `SHOW-SERVERS` subcommand displays the information for the managed database servers listed in the BART configuration file. - -**Syntax:** - -`bart SHOW-SERVERS [ –s { | all } ]` - -The following table describes the command options. - -| Options | Description | -| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server whose BART configuration information is to be displayed. If `all` is specified or if the option is omitted, information for all database servers is displayed. | diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx deleted file mode 100644 index d006df69db1..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_backups.html" ---- - -The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. - -**Syntax:** - -```text -bart SHOW-BACKUPS [ –s { | all } ] - [ -i { | | all } ] - [ -t ] -``` - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server whose backup information is to be displayed.
If `all` is specified or if the option is omitted, the backup information for all database servers is displayed with the exception as described by the following note:
If `SHOW-BACKUPS` is invoked while the BART `BACKUP` subcommand is in progress, backups affected by the backup process are shown in progress status in the displayed backup information. | -| `-i { \| \| all }`
`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified or if the option is omitted, all backup information for the relevant database server is displayed. | -| `-t`
`--toggle` | Displays more backup information in a list format. If the option is omitted, the default is a tabular format. | diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx deleted file mode 100644 index 4ec79d52d62..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/verify_chksum.html" ---- - - - -The `VERIFY-CHKSUM` subcommand verifies the MD5 checksums of the full backups and any user-defined tablespaces for the specified database server or for all database servers. The checksum is verified by comparing the current checksum of the backup against the checksum when the backup was taken. - -!!! Note - The `VERIFY-CHKSUM` subcommand is only used for tar format backups. It is not applicable to plain format backups. - -**Syntax:** - -```text -bart VERIFY-CHKSUM - [ -s { | all } ] - [ -i { | | all } ] -``` - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`

`--server { \| all }` | `` is the name of the database server whose tar backup checksums are to be verified. If `all` is specified or if the `-s` option is omitted, the checksums are verified for all database servers. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is the backup identifier of a tar format full backup whose checksum is to be verified along with any user-defined tablespaces.
`` is the user-defined alphanumeric name for the full backup.
If `all` is specified or if the `-i` option is omitted, the checksums of all tar backups for the relevant database server are verified. | diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx deleted file mode 100644 index 52a74badaa7..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/manage.html" ---- - - - -The `MANAGE` subcommand can be invoked to: - -- Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file (See [Managing Backups Using a Retention Policy](../02_managing_backups_using_a_retention_policy/#managing_backups_using_a_retention_policy) for information about retention policy management). - -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file (See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting this parameter). - - **Syntax:** - - ```text - bart MANAGE [ –s { | all} ] - [ -l ] [ -d ] - [ -c { keep | nokeep } - -i { | | all } ] - [ -n ] - ``` - -The following summarizes the actions performed when the `MANAGE` subcommand is invoked: - -- When the `MANAGE` subcommand is invoked with no options or with only the `-s ` or `-s all` option, the following actions are performed: - - For the server specified by the `-s` option, or for all servers (if `-s all` is specified or the `-s` option is omitted), active backups are marked as `obsolete` in accordance with the retention policy. - - All backups that were marked `obsolete` or `keep` prior to invoking the `MANAGE` subcommand remain marked with the same prior status. - - If WAL compression is enabled for the database server, then any uncompressed, archived WAL files in the BART backup catalog of the database server are compressed with gzip. -- When the `MANAGE` subcommand is invoked with any other option besides the `-s` option, the following actions are performed: - - For the server specified by the `-s` option, or for all servers, the action performed is determined by the other specified options (that is, `-l` to list obsolete backups, `-d` to delete obsolete backups, `-c` to keep or to return backups to `active` status, or `-n` to perform a dry run of any action). - - No marking of `active` backups to `obsolete` status is performed regardless of the retention policy. - - All backups that were marked `obsolete` or `keep` prior to invoking the `MANAGE` subcommand remain marked with the same prior status unless the `-c` option (without the `-n` option) is specified to change the backup status of the particular backup or all backups referenced with the `-i` option. - - No compression is applied to any uncompressed, archived WAL file in the BART backup catalog regardless of whether or not WAL compression is enabled. - -The following are additional considerations when using WAL compression: - -- Compression of archived WAL files is not permitted for database servers on which incremental backups are to be taken. -- The gzip compression program must be installed on the BART host and be accessible in the `PATH` of the BART user account. -- When the `RESTORE` subcommand is invoked, if the `-c` option is specified or if the `copy_wals_during_restore` BART configuration parameter is enabled for the database server, then the following actions occur: - - - If compressed, archived WAL files are stored in the BART backup catalog and the location to which the WAL files are to be restored is on a remote host relative to the BART host: - - - the archived WAL files are transmitted across the network to the remote host in compressed format only if the gzip compression program is accessible in the `PATH` of the remote user account that is used to log into the remote host when performing the `RESTORE` operation. - - This remote user is specified with either the `remote_host` parameter in the BART configuration file or the `RESTORE -r` option (see [RESTORE](08_restore/#restore)). - - Transmission of compressed WAL files results in less network traffic. After the compressed WAL files are transmitted across the network, the `RESTORE` subcommand uncompresses the files for the point-in-time recovery operation. - - If the gzip program is not accessible on the remote host in the manner described in the previous bullet point, then the compressed, archived WAL files are first uncompressed while on the BART host, then transmitted across the network to the remote host in uncompressed format. -- When the `RESTORE` subcommand is invoked without the `-c` option and the `copy_wals_during_restore` BART configuration parameter is disabled for the database server, then any compressed, archived WAL files needed for the `RESTORE` operation are uncompressed in the BART backup catalog. The uncompressed WAL files can then be saved to the remote host by the `restore_command` in the `postgresql.auto.conf` file when the database server archive recovery begins. - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `s { \| all }`
`--server { \| all }` | `` is the name of the database server to which the actions are to be applied. If `all` is specified or if the `-s` option is omitted, the actions are applied to all database servers. | -| `-l`
`--list-obsolete` | Lists the backups marked as obsolete. | -| `-d`
`--delete-obsolete` | Delete the backups marked as `obsolete`. This action physically deletes the backup along with its archived WAL files and any MBM files for incremental backups. | -| `-c { keep \| nokeep }`

`--change-status { keep \| nokeep }` | Specify `keep` to change the status of a backup to `keep` to retain it indefinitely.
Specify `nokeep` to change the status of any backup back to active status. The backup can then be re-evaluated and possibly be marked to `obsolete` according to the retention policy by subsequent usage of the `MANAGE` subcommand.
The `–i` option must be included when using the `-c` option. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified, then actions are applied to all backups.
The `–c` option must be included when using the `-i` option. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to actually implementing the actions as if the operation was performed, however, no changes are actually made.
If `-n` is specified with the `-d` option, it displays which backups would be deleted, but does not actually delete the backups.
If `-n` is specified with the `-c` option, it displays the keep or nokeep action, but does not actually change the backup from its current status.
If `-n` is specified alone with no other options, or with only the `-s` option, it displays which active backups would be marked as obsolete, but does not actually change the backup status. In addition, no compression is performed on uncompressed, archived WAL files even if WAL compression is enabled for the database server. | diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx deleted file mode 100644 index d74a4d1f5d6..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restore.html" ---- - - - -The `RESTORE` subcommand restores a backup and its archived WAL files for the designated database server to the specified directory location. If the appropriate `RESTORE` options are specified, all recovery settings will be saved in the `postgresql.auto.conf` file. - -**Syntax:** - -```text -bart RESTORE –s -p - [ –i { | } ] - [ -r ] - [ -w ] - [ -t ] - [ { -x | -g } ] - [ -c ] -``` - -For information about using a continuous archive backup for recovery, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/13/static/continuous-archiving.html). This reference material provides detailed information about the underlying point-in-time recovery process and the meaning and usage of the restore options that are generated into the `postgresql.auto.conf` file by BART. - -**Please note**: - -- For special requirements when restoring an incremental backup to a remote database server, see [Restoring an Incremental Backup on a Remote Host](../../02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup/#restoring_an_incremental_backup_on_a_remote_host). -- Check to ensure that the host where the backup is to be restored contains enough disk space for the backup and its archived WAL files. The `RESTORE` subcommand may result in an error while copying files if there is not enough disk space available. -- See [Performing a Restore Operation](../01_bart_management_overview/01_performing_a_restore_operation/#performing_a_restore_operation) to view steps on how to perform a restore operation and see [Point-In-Time Recovery Operation](../01_bart_management_overview/02_point_in_time_recovery_operation/#point_in_time_recovery_operation) to view steps on how to perform a point-in-time recovery operation. -- If the backup is restored to a different database cluster directory than where the original database cluster resided, certain operations dependent upon the database cluster location may fail. This happens if their supporting service scripts are not updated to reflect the new directory location of restored backup. For information about the usage and modification of service scripts, see the *EDB Advanced Server Installation Guide* available at the [EDB website](/epas/latest/). - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server to be restored. | -| `-p `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | -| `-i { \| }`

`--backupid { \| }` | `` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the default is to use the latest backup. | -| `-r or --remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored and `` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `` parameter for this database server is not set in the BART configuration file.
If the BART user account is not the same as the operating system account owning the `` directory given with the `-p` option, use the `` BART configuration parameter or the `RESTORE` subcommand `-r` option to specify the `` directory owner even when restoring to a directory on the same host as the BART host.
See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `` parameter. | -| `-w `
`--workers ` | `` is the specification of the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location.
For example, if 4 worker processes are specified, 4 receiver processes on the restore host and 4 streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process. When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. If the `-w` option is omitted, the default is `1` \| worker process. | -| `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | -| `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. Include either the `-x ` or the `--target-xid ` option if point-in-time recovery is desired. | -| `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. Include either the `--target-timestamp ` or the `-g ` option if point-in-time recovery is desired. | -| `-c`
`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
If recovery settings are saved in the `postgresql.auto.conf` file for point-in-time recovery, the `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, the `restore_command` in the `postgresql.auto.conf` file is generated by default to retrieve the archived WAL files directly from the BART backup catalog. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `copy_wals_during_restore` parameter. | \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx deleted file mode 100644 index 7f9836ad724..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/delete.html" ---- - - - -The `DELETE` subcommand removes the subdirectory and data files from the BART backup catalog for the specified backups along with its archived WAL files. - -**Syntax:** - -```text -bart DELETE –s - -i { all | - [']{ | },... }['] - } - [ -n ] -``` - -!!! Note - While invoking the `DELETE` subcommand, you must specify a specific database server. - -For database servers under a retention policy, there are conditions where certain backups may not be deleted. See [Deletions Permitted Under a Retention Policy](../02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy/#deletions_permitted_under_retention_policy) for information about permitted backup deletions. - -The following table describes the command options: - -| Options | Description | -| -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `

`--server ` | `` is the name of the database server whose backups are to be deleted. | -| `-i { all \| [']{ \| },... }['] }`

`--backupid { all \| [']{ \| },... }['] }` | `` is the backup identifier of the backup to be deleted and `` is the user-defined alphanumeric name for the backup.
Multiple backup identifiers and backup names may be specified in a comma-separated list. The list must be enclosed within single quotes if there is any white space appearing before or after each comma.
If `all` is specified, all of the backups and their archived WAL files for the specified database server are deleted. | -| `-n`
`--dry-run` | Displays the results as if the deletions were done, however, no physical removal of the files are actually performed. In other words, a test run is performed so that you can see the potential results prior to actually initiating the action.
After the deletion, the BART backup catalog for the database server no longer contains the corresponding directory for the deleted backup ID. The `archived_wals` subdirectory no longer contains the WAL files of the backup. | diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx deleted file mode 100644 index 379dd137082..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Basic BART Subcommand Usage" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/basic_bart_subcommand_usage.html" ---- - - - -This section briefly describes the BART subcommands and options. You can invoke the `bart` program (located in the `/bin` directory) with the desired options and subcommands to manage your BART installation. - -To view examples of BART subcommands, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -**Syntax for invoking BART**: - - `bart [ general_option ]... [ subcommand ] [subcommand_option ]...` - -- When invoking a subcommand, the subcommand name is not case-sensitive (that is, the subcommand can be specified in uppercase, lowercase, or mixed case). -- Each subcommand has a number of its own applicable options that are specified following the subcommand. All options are available in both single-character and multi-character forms. -- Keywords are case-sensitive; options are generally specified in lowercase unless specified otherwise in this section. -- When invoking BART, the current user must be the BART user account (operating system user account used to run the BART command line program). For example, enterprisedb or postgres can be selected as the BART user account when the managed database servers are Advanced Server or PostgreSQL respectively. -- The chosen operating system user account must own the BART backup catalog directory, be able to run the `bart` program and the `bart scanner` program, and have a passwordless SSH/SCP connection established between database servers managed by BART. - -You can specify one or more of the following general options: - -| Options | Description | -| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` or `--help` | Displays general syntax and information on BART usage. All subcommands support a help option (`-h`, `--help`). If the help option is specified, information is displayed regarding that particular subcommand. The subcommand, itself, is not executed. | -| `-v` or `--version` | Displays the BART version information. | -| `-d` or `--debug` | Displays debugging output while executing BART subcommands. | -| `-c `or `--config-path ` | Specifies `config_file_path` as the full directory path to a BART configuration file. Use this option if you do not want to use the default BART configuration file `/etc/bart.cfg`. | - -**Troubleshooting: Setting Path Environment Variable** - -If execution of BART subcommands fails with the following error message, then you need to set the `LD_LIBRARY_PATH` to include the `libpq` library directory: - - `./bart: symbol lookup error: ./bart: undefined symbol: PQping` - -**Workaround:** Set the `LD_LIBRARY_PATH` environment variable for the BART user account to include the directory containing the `libpq` library. This directory is `POSTGRES_INSTALL_HOME/lib`. - -It is suggested that the `PATH` and the `LD_LIBRARY_PATH` environment variable settings be placed in the BART user account’s profile. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details. - -In the following sections, the `help` option is omitted from the syntax diagrams for the purpose of providing readability for the subcommand options. - -
- -check_config init backup show_servers show_backups verify_chksum manage restore delete - -
diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx deleted file mode 100644 index b047505556e..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/running_the_bart_wal_scanner.html" ---- - - - -Use the BART WAL scanner to invoke the `bart-scanner` program located in the `BART_HOME/bin` directory. When invoking the WAL scanner, the current user must be the BART user account. - -**Syntax:** - -```text -bart-scanner - [ -d ] - [ -c ] - { –h | - -v | - --daemon | - -p | - | - RELOAD | - STOP -``` - -!!! Note - For clarity, the syntax diagram shows only the single-character option form (for example, `-d`), but the multi-character option form (for example, `--debug`) is supported as well. - -The WAL scanner processes each WAL file to find and record modified blocks in a corresponding modified block map (MBM) file. The default approach is that the WAL scanner gets notified whenever a new WAL file is added to the `archived_wals` directory specified in the `archive_path` parameter of the configuration file. It then scans the WAL file and produces the MBM file. - -The default approach does not work in some cases; for example when the WAL files are shipped to the `archive_path` using the Network File System (NFS) and also in case of some specific platforms. This results in the WAL files being copied to the `archived_wals` directory, but the WAL scanner does not scan them (as WAL scanner is not aware of WAL file) and produce the MBM files. This results in the failure of an incremental backup. This can be avoided by using the timer-based WAL scanning approach, which is done by using the `scan_interval` parameter in the BART configuration file. The value for `scan_interval` is the number of seconds after which the WAL scanner will initiate force scanning of the new WAL files. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about `scan_interval` parameter. - -When the `bart-scanner` program is invoked, it forks a separate process for each database server enabled with the `allow_incremental_backups` parameter. - -The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option. Use the `--daemon` option to run the WAL scanner process in the background so that all output messages can be viewed in the BART log file. If the `--daemon` option is omitted, the WAL scanner process runs in the foreground and all output messages can be viewed from the terminal running the program as well as in the BART log file. - -See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for additional information about WAL scanning, `allow_incremental_backups`, and `logfile` parameters. - -!!! Note - The BART user account’s `LD_LIBRARY_PATH` environment variable may need to be set to include the directory containing the `libpq` library if invocation of the WAL scanner program fails. See [Basic BART Subcommand Usage](03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage) for information about setting the `LD_LIBRARY_PATH` environment variable. - -The following table describes the scanner options: - -| Options | Description | -| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on WAL scanner usage. | -| `-v` `--version` | Displays the WAL scanner version information. | -| `-d` `--debug` | Displays debugging output while executing the WAL scanner with any of its options. | -| `-c ` `--config-path ` | Use this option to specify the `config_file_path` of a BART configuration file if you do not want to use the default BART configuration file path `BART_HOME/etc/bart.cfg`. | -| `--daemon` | Runs the WAL scanner as a background process. | -| `-p ` `--print ` | Use this option to specify the full directory path to an MBM file whose content is to be printed. The directory specified in the `archive_path` parameter in the `bart.cfg` file contains the MBM files. | -| `` | Specify the full directory path to a WAL file to be scanned. The directory specified in the `archive_path` parameter in the `bart.cfg` file contains the WAL files. Use this option if a WAL file in the archive path is missing its MBM file. This option is to be used for assisting the EnterpriseDB support team for debugging problems that may have been encountered. | -| `RELOAD` | Reloads the BART configuration file. The keyword `RELOAD` is not case-sensitive. The `RELOAD` option is useful if you make changes to the configuration file after the WAL scanner has been started. It will reload the configuration file and adjust the WAL scanners accordingly. For example, if a server section allowing incremental backups is removed from the BART configuration file, then the process attached to that server will stop. Similarly, if a server allowing incremental backups is added, a new WAL scanner process will be launched to scan the WAL files of that server. | -| `STOP` | Stops the WAL scanner. The keyword `STOP` is not case-sensitive. | diff --git a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/index.mdx b/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/index.mdx deleted file mode 100644 index a076b82b5e9..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/03_using_bart/index.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Using BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_bart.html" ---- - - - -After installing and configuring the BART host and the database servers, you can start using BART. - -This section describes how to perform backup and recovery management operations using BART. Review the sections that follow before proceeding with any BART operation. - -
- -bart_management_overview managing_backups_using_a_retention_policy basic_bart_subcommand_usage running_the_bart_wal_scanner - -
diff --git a/product_docs/docs/bart/2.5.9/bart_user/04_using_tablespaces.mdx b/product_docs/docs/bart/2.5.9/bart_user/04_using_tablespaces.mdx deleted file mode 100644 index 94d5450778a..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/04_using_tablespaces.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Using Tablespaces" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_tablespaces.html" ---- - - - -If the database cluster contains user-defined tablespaces (that is, tablespaces created with the `CREATE TABLESPACE` command): - -- You can take full backups with the `BACKUP` subcommand in either tar (`-Ft`) or plain text (`-Fp`) backup file format. -- You must take incremental backups in the plain text (`-Fp`) backup file format. -- You can take full backups using the transaction log streaming method (xlog_method = stream in the BART configuration file) `--with-pg_basebackup` and the `BACKUP` subcommand in either tar (`-Ft`) or plain text (`-Fp`) backup file format. - -!!! Note - If the particular database cluster you plan to back up contains tablespaces created by the `CREATE TABLESPACE` command, then you must set the `tablespace_path` parameter in the BART configuration file before you perform a BART `RESTORE` operation. - -The `tablespace_path` parameter specifies the directory paths to which you want the tablespaces to be restored. It takes the following format: - - `OID_1=tablespace_path_1;OID_2=tablespace_path_2 ...` - -Where `OID_1`, `OID_2`, … are the Object Identifiers of the tablespaces. You can find the OIDs of the tablespaces and their corresponding soft links to the directories by listing the contents of the `POSTGRES_INSTALL_HOME/data/pg_tblspc` subdirectory as shown in the following example: - -```text -[root@localhost pg_tblspc ]# pwd -/opt/PostgresPlus/9.6AS/data/pg_tblspc -[root@localhost pg_tblspc]# ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Aug 22 16:38 16644 -> /mnt/tablespace_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Aug 22 16:38 16645 -> /mnt/tablespace_2 -``` - -The OIDs are `16644` and `16645` to directories `/mnt/tablespace_1` and `/mnt/tablespace_2`, respectively. - -If you later wish to restore the tablespaces to the same locations as indicated in the preceding example, the BART configuration file must contain the following entry: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -tablespace_path = 16644=/mnt/tablespace_1;16645=/mnt/tablespace_2 -description = "Accounting" -``` - -If you later wish to restore the tablespaces to different locations, specify the new directory locations in the `tablespace_path` parameter. - -In either case, the directories specified in the `tablespace_path` parameter must exist and be empty at the time you perform the `BART RESTORE` operation. - -If the database server is running on a remote host (in other words you are also using the `remote_host` configuration parameter or will specify the `--remote-host` option with the `RESTORE` subcommand), the specified tablespace directories must exist on the specified remote host. - -To view example of backing up and restoring a database cluster on a remote host containing tablespaces, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -The directories must be owned by the user account with which you intend to start the database server (typically the Postgres user account) with no access by other users or groups as is required for the directory path to which the main full backup is to be restored. - -To view a sample BART managed backup and recovery system consisting of both local and remote database servers, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.5.9/bart_user/images/EDB_logo.png b/product_docs/docs/bart/2.5.9/bart_user/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.5.9/bart_user/images/copy_1.png b/product_docs/docs/bart/2.5.9/bart_user/images/copy_1.png deleted file mode 100644 index e08d97827fb..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/images/copy_1.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:c2b13e1623222f77bce5a2d1be4027a9032c878b05bed7ba1a0873be45257d8c -size 10470 diff --git a/product_docs/docs/bart/2.5.9/bart_user/images/edb.png b/product_docs/docs/bart/2.5.9/bart_user/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.5.9/bart_user/images/edb_logo.svg b/product_docs/docs/bart/2.5.9/bart_user/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.5.9/bart_user/index.mdx b/product_docs/docs/bart/2.5.9/bart_user/index.mdx deleted file mode 100644 index 50504d9e3db..00000000000 --- a/product_docs/docs/bart/2.5.9/bart_user/index.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -navTitle: Backup and Recovery Guide -title: "EDB Postgres Backup and Recovery User Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/index.html" ---- - -
- -introduction overview using_bart using_tablespaces conclusion - -
diff --git a/product_docs/docs/bart/2.5.9/index.mdx b/product_docs/docs/bart/2.5.9/index.mdx deleted file mode 100644 index 5a4e4fd6cc0..00000000000 --- a/product_docs/docs/bart/2.5.9/index.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Backup and Recovery Tool -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5.9 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." -navigation: - - "#Getting Started" - - bart_inst - - bart_qs_7 - - bart_qs_8 - - "#Guides" - - bart_user - - bart_ref ---- - - - - diff --git a/product_docs/docs/bart/2.5/bart_inst/02_installing_bart.mdx b/product_docs/docs/bart/2.5/bart_inst/02_installing_bart.mdx index ae888987e6e..f4e2ef84cbd 100644 --- a/product_docs/docs/bart/2.5/bart_inst/02_installing_bart.mdx +++ b/product_docs/docs/bart/2.5/bart_inst/02_installing_bart.mdx @@ -110,7 +110,7 @@ The following section demonstrates installing BART on a CentOS host using an RPM The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). + - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). Upon successful installation, BART is installed in the `BART_HOME` directory: @@ -231,7 +231,7 @@ The following section demonstrates installing BART on a RHEL host using an RPM p The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). + - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). Upon successful installation, BART is installed in the `BART_HOME` directory: diff --git a/product_docs/docs/bart/2.5/bart_inst/03_configuring_bart.mdx b/product_docs/docs/bart/2.5/bart_inst/03_configuring_bart.mdx index 95395d5cef9..0201f230692 100644 --- a/product_docs/docs/bart/2.5/bart_inst/03_configuring_bart.mdx +++ b/product_docs/docs/bart/2.5/bart_inst/03_configuring_bart.mdx @@ -124,11 +124,11 @@ The following table describes the `[BART]` host parameters. | `[BART}` | Mandatory | Identifies the global section of the configuration file. It must be named BART. | | `bart_host` | Mandatory | Specify the bart user name and the IP address of the bart host on which the BART utility resides. You must specify it in the form of <bart_user>@<bart_host_address>. | | `backup_path` | Mandatory | Specify the path to the file system parent directory where all BART backups are stored. | -| `pg_basebackup_path` | Mandatory | Specify the path to the `pg_basebackup` program that you installed on the BART host. For information about `pg_basebackup` version-specific restrictions, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). | +| `pg_basebackup_path` | Mandatory | Specify the path to the `pg_basebackup` program that you installed on the BART host. For information about `pg_basebackup` version-specific restrictions, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | | `wal_compression` | Optional | Set this parameter to `enabled` to compress the archived WAL files in gzip format in the BART backup catalog when the `MANAGE` subcommand is invoked. By default it is set to `disabled`. The gzip compression program must be in the BART user account’s `PATH` and the WAL compression setting must not be enabled for those database servers where you need to take incremental backups. | | `copy_wals_during_restore` | Optional | Set this parameter to `enabled` to copy the archived WAL files from the BART backup catalog to the `restore_path/archived_wals` directory prior to the database server archive recovery. Enabling this option helps you save time during the restore operation. Set this parameter to `disabled` (default) to retrieve the archived WAL files directly from the BART backup catalog during the database server archive recovery. During the restore operation, recovery settings will be saved in the `postgresql.auto.conf` file. The `restore_command` in the `postgresql.auto.conf` file will be determined by the value specified in the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked with the `-c` option, the archived WAL files are copied from the BART backup catalog to the `restore_path/archived_wals` directory, thus overriding any setting of the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked without the `-c` option, the value specified by the `copy_wals_during_restore` parameter is used. | | `xlog_method` | Optional | Specify how the transaction log is collected during the execution of `pg_basebackup` through the `BACKUP` subcommand. Set `xlog_method` to `fetch` (default) to collect the transaction log files after the backup is completed. Set to `stream` to stream the transaction log in parallel with the full backup creation. | -| `retention_policy` | Optional | Set this parameter to determine when an active backup should be marked as `obsolete` when the `MANAGE` subcommand is used. You can specify the retention policy either in terms of number of backups or duration (days, weeks, or months). ` BACKUPS` (default), ` DAYS`, ` WEEKS`, or ` MONTHS` where `` is a positive integer. For information about managing backups using a retention policy, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). | +| `retention_policy` | Optional | Set this parameter to determine when an active backup should be marked as `obsolete` when the `MANAGE` subcommand is used. You can specify the retention policy either in terms of number of backups or duration (days, weeks, or months). ` BACKUPS` (default), ` DAYS`, ` WEEKS`, or ` MONTHS` where `` is a positive integer. For information about managing backups using a retention policy, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | | `logfile` | Optional | Use this parameter to specify the path to the BART log file. The default log file location is `/tmp/bart.log`. The log file will be created the first time you invoke the `bart` command line program using the sample configuration file value. To change the default setting, you must delete the `bart.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a log file. | | `scanner_logfile` | Optional | Use this parameter to specify the path to the XLOG/WAL scanner log file. The default location is `/tmp/bart_scanner.log`. The scanner log file will be created the first time you invoke the `bart_scanner` program using the sample configuration file value. To change the default setting, you must delete the `bart_scanner.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a WAL scanner log file. | | `` | Optional | Specify the socket directory path where all BART sockets will be stored. The default directory is `/tmp`. While specifying the `bart_socket_directory` path, you must ensure that the directory exists and the BART user has the required access permissions to the directory. | @@ -199,7 +199,7 @@ For BART usage, there are two scenarios that require a passwordless SSH/SCP conn - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the database server host. The `authorized_keys` file is in the home directory of the user account that owns the directory where the database backup is to be restored. - If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. -See the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/2.5/bart_ref/) to view examples of creating a passwordless connection. +See the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/) to view examples of creating a passwordless connection. **Enabling Public Key Authentication** @@ -362,7 +362,7 @@ The following table describes the database server parameters. | `` | Mandatory | Specify the Linux operating system user account that owns the database cluster. This is typically `enterprisedb` for Advanced Server database clusters installed in the Oracle compatible mode, or `postgres` for Advanced Server database clusters installed in the PostgreSQL compatible mode and PostgreSQL database clusters. | | `` | Optional | Specify the IP address of the remote server to which a backup is to be restored. Specify this parameter in the form of `@`. `` is the user account on the target database server host that accepts a passwordless SSH/SCP login connection and owns the directory where the backup is to be restored. `` is the IP address of the remote host. For restoring a backup to a remote host or for restoring any backup where `` and the BART user account are not the same users, either this parameter must be set or it may be specified with the `-r` option with the BART `RESTORE` subcommand. | | `` | Optional | Specify path to which tablespaces are to be restored in the format `OID = `; If the backup is to be restored to a remote host specified by the `` parameter, then the tablespace paths must exist on the remote host. | -| `allow_incremental_backups` | Optional | Set this parameter to `enabled` to enable use of the WAL scanner and permit taking incremental backups when the `BACKUP` subcommand is invoked with the `--parent` option. Set it to `disabled` (default) to disallow incremental backups and thus permit only full backups. For information about using the `BACKUP` subcommand and running the WAL scanner, please see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). | +| `allow_incremental_backups` | Optional | Set this parameter to `enabled` to enable use of the WAL scanner and permit taking incremental backups when the `BACKUP` subcommand is invoked with the `--parent` option. Set it to `disabled` (default) to disallow incremental backups and thus permit only full backups. For information about using the `BACKUP` subcommand and running the WAL scanner, please see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | | `Description` | Optional | Specify the description that will be used to identify the database server. | For information regarding the following parameters, see [configuring the BART host](#configuring-the-bart-host). @@ -447,7 +447,7 @@ Set the following configuration parameters in the `postgresql.conf` file to enab - Set the PostgreSQL `archive_command` parameter to copy the WAL files to the `archive_path`. The `archive_command` configuration parameter mentioned here is located in the `postgresql.conf` file; the PostgreSQL `archive_command` parameter is used in a different manner than the BART [archive_command](#archive_command). - Set `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (the setting must be a minimum of 2). See [Configuring the BART host](#configuring-the-bart-host) for information about the `xlog_method` parameter. -For detailed information about WAL archiving, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/12/static/continuous-archiving.html). +For detailed information about WAL archiving, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). The `ARCHIVE PATH` field displayed by the BART `SHOW-SERVERS` subcommand displays the full directory path where the WAL files should be copied as specified in the `archive_command` configuration parameter in the `postgresql.conf` file: @@ -501,7 +501,7 @@ To enable WAL archiving: - In the `postgresql.conf` file, set the `wal_level` to `replica` or higher, `archive_mode` to `on`, and `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server as determined in the BART configuration file, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (that is, the setting must be a minimum of `2`). See [Configuring the BART host](#configuring-the-bart-host) for information on the `xlog_method` parameter. -- Configure the Postgres `archive_command` parameter automatically with the `INIT` subcommand and restart the database server when you are ready to initiate WAL archiving. The `INIT` subcommand invokes the Postgres `ALTER SYSTEM` command to set the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME data directory`. For additional information about the `INIT` subcommand, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +- Configure the Postgres `archive_command` parameter automatically with the `INIT` subcommand and restart the database server when you are ready to initiate WAL archiving. The `INIT` subcommand invokes the Postgres `ALTER SYSTEM` command to set the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME data directory`. For additional information about the `INIT` subcommand, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The archive command string that the `INIT` subcommand generates into the `postgresql.auto.conf` file is determined by the parameter setting of the BART `archive_command` parameter in the server section of the BART configuration file. If the BART `archive_command` parameter is not set in the server section for a given database server, the command string that is configured uses the following default format: @@ -640,4 +640,4 @@ The `CHECK-CONFIG` subcommand confirms the following: - Archiving of WAL files to the `archive_path` is in process. - The WAL scanner program is running. -After configuring the BART host and the database server(s), you can start using BART. For information about using BART, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +After configuring the BART host and the database server(s), you can start using BART. For information about using BART, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). diff --git a/product_docs/docs/bart/2.5/bart_inst/04_upgrading_bart.mdx b/product_docs/docs/bart/2.5/bart_inst/04_upgrading_bart.mdx index 4115c975dcf..4ea97b87ab6 100644 --- a/product_docs/docs/bart/2.5/bart_inst/04_upgrading_bart.mdx +++ b/product_docs/docs/bart/2.5/bart_inst/04_upgrading_bart.mdx @@ -62,12 +62,12 @@ bart-scanner STOP **Step 3:** Repeat the process described in this section to upgrade to the latest BART version on each remote hosts where an incremental backup will be restored. -For additional information about restoration of incremental backups on remote hosts, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +For additional information about restoration of incremental backups on remote hosts, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). **Step 4:** If the `bart --version` command returns an error stating the `PATH` is not available after switching from `root` user to another BART user account, adjust the setting of the `PATH` environment variable to include the location of the BART x.y.z executable (the `bin` subdirectory) in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - The BART user account on the BART host. -- The remote user account on the remote host to which incremental backups are to be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +- The remote user account on the remote host to which incremental backups are to be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The `PATH` setting should be the same as set for BART x.y.z since all versions use `/usr/edb/bart/bin`. diff --git a/product_docs/docs/bart/2.5/bart_inst/05_uninstalling_bart.mdx b/product_docs/docs/bart/2.5/bart_inst/05_uninstalling_bart.mdx index de8c1c0d00b..8374221ef88 100644 --- a/product_docs/docs/bart/2.5/bart_inst/05_uninstalling_bart.mdx +++ b/product_docs/docs/bart/2.5/bart_inst/05_uninstalling_bart.mdx @@ -31,7 +31,7 @@ Uninstalling BART does not delete the backup files and archived WAL files that r - `rm –rf /opt/backup` - BART `DELETE` subcommand -For information about the BART `DELETE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). +For information about the BART `DELETE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). ## Uninstalling BART on an SLES 12 Host diff --git a/product_docs/docs/bart/2.5/bart_qs_7/index.mdx b/product_docs/docs/bart/2.5/bart_qs_7/index.mdx index bf35c868fc3..1d54bf90879 100644 --- a/product_docs/docs/bart/2.5/bart_qs_7/index.mdx +++ b/product_docs/docs/bart/2.5/bart_qs_7/index.mdx @@ -9,7 +9,7 @@ legacyRedirectsGenerated: This tutorial demonstrates using `yum` to [install](#installing) and [configure](../bart_qs_8/#configuring) Backup and Recovery Tool (BART) 2.5 on a CentOS 7 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/2.5/bart_inst/). +For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - BART is tested with the following database versions: @@ -113,7 +113,7 @@ Before configuring BART, establish the BART user account (the operating system u cp bart.cfg.sample bart.cfg ``` -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/2.5/bart_inst/). +3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. @@ -188,7 +188,7 @@ The following table describes only mandatory parameters: bart CHECK-CONFIG [ -s ] ``` - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide*, available at the [EDB website](/bart/2.5/bart_user/). + BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide*, available at the [EDB website](/bart/latest/bart_user/). @@ -254,7 +254,7 @@ The following example enables SSH/SCP access on a CentOS 7.x host; similar (plat If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/2.5/bart_ref/). +An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. @@ -316,6 +316,6 @@ If an `authorized_keys` file does not exist, create a new file, but do not compl 2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. -3. The [pg_hba.conf](https://www.postgresql.org/docs/12/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. +3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. 4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.5/bart_qs_8/index.mdx b/product_docs/docs/bart/2.5/bart_qs_8/index.mdx index 008295fcc1d..7dc447abfb2 100644 --- a/product_docs/docs/bart/2.5/bart_qs_8/index.mdx +++ b/product_docs/docs/bart/2.5/bart_qs_8/index.mdx @@ -9,7 +9,7 @@ legacyRedirectsGenerated: This tutorial demonstrates using the `dnf` command to install and configure the EDB Backup and Recovery Tool (BART) 2.5 on a CentOS 8 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures and has administrative privileges on the host. -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/). +For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - BART is tested with the following database versions: @@ -109,7 +109,7 @@ Before configuring BART, establish the BART user account (the operating system u cp bart.cfg.sample bart.cfg ``` -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/2.5/bart_inst/). +3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. @@ -184,7 +184,7 @@ The following table describes only mandatory parameters: bart CHECK-CONFIG [ -s ] ``` - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide* available at the [EDB website](/bart/2.5/bart_user/). + BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide* available at the [EDB website](/bart/latest/bart_user/). @@ -250,7 +250,7 @@ The following example enables SSH/SCP access on a CentOS 8.x host; similar (plat If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/2.5/bart_ref/). +An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. @@ -312,6 +312,6 @@ If the `authorized_keys file` does not exist, create a new file, but do not comp 2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. -3. The [pg_hba.conf](https://www.postgresql.org/docs/12/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. +3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. 4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/01_backup.mdx b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/01_backup.mdx index 97172dd9b88..2649c676929 100644 --- a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/01_backup.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/01_backup.mdx @@ -35,7 +35,7 @@ bart BACKUP –s [-Fp] ``` -Before performing an incremental backup, you must take a full backup. For more details about incremental backup, refer to *Block-Level Incremental Backup* in the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). +Before performing an incremental backup, you must take a full backup. For more details about incremental backup, refer to *Block-Level Incremental Backup* in the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). The following table describes the `BACKUP` options: @@ -45,8 +45,8 @@ The following table describes the `BACKUP` options: | `-F { p \| t }`
`--format { p \| t }` | Use this option to specify the backup file format.
Specify `p` option to take backup in plain text format and specify `t` option to take backup in tar format. If the `p` or `t` option is omitted, the default is tar format.
Use `p` option with the `BACKUP` subcommand when streaming is used as a backup method.
An incremental backup can only be taken in plain text format (`p`). | | `-z`
`(--gzip)` | This option is applicable only for full backup and `tar` format. Use this option to enable gzip compression of tar files using the default compression level (typically 6). | | `-c `
`--compress-level ` | This is applicable only for full backup and tar format. Use this option to specify the gzip compression level on the tar file output. `` is a digit from 1 through 9, with 9 being the best compression. | -| `--backup-name ` | Use this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
For detailed information about this parameter, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/).
If the option `--backup-name` is not specified and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to specify the number of worker threads to run in parallel to copy blocks for a backup.
For detailed information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/). | +| `--backup-name ` | Use this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
For detailed information about this parameter, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/).
If the option `--backup-name` is not specified and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | +| `--thread-count ` | Use this option to specify the number of worker threads to run in parallel to copy blocks for a backup.
For detailed information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | | `--with-pg_basebackup` | This is applicable only for full backup. Use this option to specify the use of `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the `--with-pg_basebackup` option is specified with the `BACKUP` subcommand. | | `--no-pg_basebackup` | This is applicable only for full backup. Use this option to specify that `pg_basebackup` is not to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. | | `--parent { \| }` | Use this option to take an incremental backup. The parent backup is a backup taken prior to the incremental backup; it can be either a full backup or an incremental backup. `` is the backup identifier of a parent backup and `` is the user-defined alphanumeric name of a parent backup. | diff --git a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/03_delete.mdx b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/03_delete.mdx index 14940d188ca..a148c571880 100644 --- a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/03_delete.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/03_delete.mdx @@ -18,7 +18,7 @@ bart DELETE –s Note that when invoking the `DELETE` subcommand, you must specify a database server. -For database servers under a retention policy, there are conditions where certain backups may not be deleted. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +For database servers under a retention policy, there are conditions where certain backups may not be deleted. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The following table describes the `DELETE` options: diff --git a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/05_manage.mdx b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/05_manage.mdx index 467ff8b393c..75e63130a8e 100644 --- a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/05_manage.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/05_manage.mdx @@ -21,7 +21,7 @@ bart MANAGE [ –s { | all} ] [ -n ] ``` -To view detailed information about the `MANAGE` subcommand and retention policy management, see *the EDB Backup and Recovery User Guide*. For information about setting the `wal_compression` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide*. These guides are available at the [EDB website](/bart/2.5/bart_user/). +To view detailed information about the `MANAGE` subcommand and retention policy management, see *the EDB Backup and Recovery User Guide*. For information about setting the `wal_compression` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide*. These guides are available at the [EDB website](/bart/latest/bart_user/). The following table describes the `MANAGE` options: diff --git a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/06_restore.mdx b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/06_restore.mdx index e93ca1fb605..b0399e9d3e4 100644 --- a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/06_restore.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/06_restore.mdx @@ -20,11 +20,11 @@ bart RESTORE –s -p [ -c ] ``` -To view detailed information about the `RESTORE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). +To view detailed information about the `RESTORE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). If the backup is restored to a different database cluster directory than where the original database cluster resided, then some operations dependent upon the database cluster location may fail. This happens if the supporting service scripts are not updated to reflect the new directory location of restored backup. -For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide. +For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). The following table describes the `RESTORE` options: @@ -33,12 +33,12 @@ The following table describes the `RESTORE` options: | `-s `
`--server ` | `` is the name of the database server to be restored. | | `-p --restore-path `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | | `-i { \| }`

`--backupid { \| }` | `backup_id` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the latest backup is restored by default. | -| `-r `

`--remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored.
`` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `remote_host` parameter for this database server is not set in the BART configuration file.
For information about the `remote_host` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/). | +| `-r `

`--remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored.
`` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `remote_host` parameter for this database server is not set in the BART configuration file.
For information about the `remote_host` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). | | `-w `
`--workers ` | `` is the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location. If the `-w` option is omitted, the default is `1` worker process.
For example, if four worker processes are specified, four receiver processes on the restore host and four streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process.
When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. | | `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | | `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. | | `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. | -| `-c`

`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
The `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, then the `restore_command` in the `postgresql.conf` retrieves the archived WAL files directly from the BART backup catalog.
For information about the `copy_wals_during_restore` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/). | +| `-c`

`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
The `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, then the `restore_command` in the `postgresql.conf` retrieves the archived WAL files directly from the BART backup catalog.
For information about the `copy_wals_during_restore` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | **Examples** diff --git a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx index cda813f49a8..e28e5954347 100644 --- a/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx @@ -8,7 +8,7 @@ legacyRedirectsGenerated: The BART WAL scanner is used to process each WAL file to find and record modified blocks in a corresponding MBM file. As a BART account user, use the BART WAL scanner to invoke the `bart-scanner` program located in the `/bin` directory. -For detailed information about the WAL scanner and its usage, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +For detailed information about the WAL scanner and its usage, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). **Syntax:** diff --git a/product_docs/docs/bart/2.5/bart_ref/02_additional_examples.mdx b/product_docs/docs/bart/2.5/bart_ref/02_additional_examples.mdx index faea13bbb52..38a519f727d 100644 --- a/product_docs/docs/bart/2.5/bart_ref/02_additional_examples.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/02_additional_examples.mdx @@ -17,7 +17,7 @@ This section lists examples of the following BART operations. ## Restoring a Database Cluster with Tablespaces -The following code sample illustrates taking a backup and restoring a database cluster on a remote host containing tablespaces. For detailed information regarding using tablespaces, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +The following code sample illustrates taking a backup and restoring a database cluster on a remote host containing tablespaces. For detailed information regarding using tablespaces, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). On an Advanced Server database running on a remote host, the following tablespaces are created for use by two tables: @@ -264,7 +264,7 @@ tblspc_2 | enterprisedb | /opt/restore_tblspc_2 ## Restoring an Incremental Backup -Restoring an incremental backup may require additional setup steps depending upon the host on which the incremental backup is to be restored. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +Restoring an incremental backup may require additional setup steps depending upon the host on which the incremental backup is to be restored. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). This section provides an example of creating backup chains and then restoring an incremental backup. @@ -453,7 +453,7 @@ Restoring incremental backup `incr_1-b` as shown by the preceding example result ## Managing Backups -This section illustrates evaluating, marking, and deleting backups using the `MANAGE` subcommand using a redundancy retention policy and a recovery window retention policy. For detailed information about the `MANAGE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). +This section illustrates evaluating, marking, and deleting backups using the `MANAGE` subcommand using a redundancy retention policy and a recovery window retention policy. For detailed information about the `MANAGE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). @@ -1065,7 +1065,7 @@ dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB ## Managing Incremental Backups -This section illustrates evaluating, marking, and deleting incremental backups using the `MANAGE` and `DELETE` subcommands utilizing redundancy retention policy and recovery window retention policy. For detailed information about the `MANAGE` and `DELETE` subcommands, as well as the redundancy retention and recovery window retention policy, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). +This section illustrates evaluating, marking, and deleting incremental backups using the `MANAGE` and `DELETE` subcommands utilizing redundancy retention policy and recovery window retention policy. For detailed information about the `MANAGE` and `DELETE` subcommands, as well as the redundancy retention and recovery window retention policy, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - [Using a Redundancy Retention Policy](#redundancy_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 3 backup redundancy retention policy is in effect. - [Using a Recovery Window Retention Policy](#recovery_window_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 1-day recovery window retention policy is in effect. diff --git a/product_docs/docs/bart/2.5/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx b/product_docs/docs/bart/2.5/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx index a383fec90bf..b1527216806 100644 --- a/product_docs/docs/bart/2.5/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx @@ -10,7 +10,7 @@ legacyRedirectsGenerated: This section describes a sample BART managed backup and recovery system consisting of both local and remote database servers. The complete steps to configure and operate the system are provided. -For detailed information about configuring a BART system, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/). For detailed information about the operational procedures and BART subcommands, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.5/bart_user/). +For detailed information about configuring a BART system, see the *EDB Backup and Recovery Installation and Upgrade Guide*. For detailed information about the operational procedures and BART subcommands, see the *EDB Backup and Recovery User Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). The environment for this sample system is as follows: @@ -591,7 +591,7 @@ Add entries to the `.pgpass` file on each server to allow the BART user account 192.168.2.24:5432:*:postgres:password ``` -For more information about using a `.pgpass` file, please see the [PostgreSQL documentation](https://www.postgresql.org/docs/12/libpq-pgpass.html). +For more information about using a `.pgpass` file, please see the [PostgreSQL documentation](https://www.postgresql.org/docs/current/libpq-pgpass.html). While connected to `MKTG` on 192.168.2.24, execute the following `CREATE ROLE` command to create the replication database superuser: @@ -848,7 +848,7 @@ drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 15:36 backup Use the BART `INIT` subcommand to complete the directory structure and set the Postgres `archive_command` configuration parameter. -Before invoking any BART subcommands, set up a profile under the BART user account’s home directory to set the `LD_LIBRARY_PATH` and `PATH` environment variables. For more information regarding setting this variable, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/). +Before invoking any BART subcommands, set up a profile under the BART user account’s home directory to set the `LD_LIBRARY_PATH` and `PATH` environment variables. For more information regarding setting this variable, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). The `-o` option is specified with the `INIT` subcommand to force the setting of the Postgres `archive_command` configuration parameter when `archive_mode` is `off` or if the Postgres `archive_command` parameter is already set and needs to be overridden. diff --git a/product_docs/docs/bart/2.5/bart_ref/images/EDB_logo.png b/product_docs/docs/bart/2.5/bart_ref/images/EDB_logo.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/bart/2.5/bart_ref/images/edb.png b/product_docs/docs/bart/2.5/bart_ref/images/edb.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/bart/2.5/bart_ref/images/edb_logo.svg b/product_docs/docs/bart/2.5/bart_ref/images/edb_logo.svg old mode 100755 new mode 100644 diff --git a/product_docs/docs/bart/2.5/bart_ref/images/image2.png b/product_docs/docs/bart/2.5/bart_ref/images/image2.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/bart/2.5/bart_ref/index.mdx b/product_docs/docs/bart/2.5/bart_ref/index.mdx index 2f5c5504dcf..6a8817bd039 100644 --- a/product_docs/docs/bart/2.5/bart_ref/index.mdx +++ b/product_docs/docs/bart/2.5/bart_ref/index.mdx @@ -18,7 +18,7 @@ This guide acts as a quick reference for BART subcommands and provides comprehen - Evaluating, marking, and deleting backups and incremental backups - Configuring and operating local and remote database servers -For detailed information about BART subcommands and operations, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.5/bart_user/). +For detailed information about BART subcommands and operations, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The document is organized as follows: diff --git a/product_docs/docs/bart/2.5/bart_user/01_introduction.mdx b/product_docs/docs/bart/2.5/bart_user/01_introduction.mdx index 4e6b92da76a..1212b2847bf 100644 --- a/product_docs/docs/bart/2.5/bart_user/01_introduction.mdx +++ b/product_docs/docs/bart/2.5/bart_user/01_introduction.mdx @@ -26,7 +26,7 @@ This guide provides the following information about using BART: - [backup and recovery management process](03_using_bart/#using_bart). - [using tablespaces](04_using_tablespaces/#using_tablespaces). -For information about installing BART, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/). For examples of BART operations and subcommand usage, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/). +For information about installing BART, see the *EDB Backup and Recovery Installation and Upgrade Guide*; for examples of BART operations and subcommand usage, see the *EDB Backup and Recovery Reference Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). @@ -50,6 +50,6 @@ BART takes full backups using the `pg_basebackup` utility program under the foll - The number of thread count in effect is 1, and the `with-pg_basebackup` option is not specified with the `BACKUP` subcommand. - Database servers can only be backed up using `pg_basebackup` utility program of the same or later version than the database server version. -In the global section of the BART configuration file, the `pg_basebackup_path` parameter specifies the complete directory path to the `pg_basebackup` program. For information about the `pg_basebackup_path` parameter and the `thread_count`, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/). +In the global section of the BART configuration file, the `pg_basebackup_path` parameter specifies the complete directory path to the `pg_basebackup` program. For information about the `pg_basebackup_path` parameter and the `thread_count`, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). -For information about `pg_basebackup`, see the [PostgreSQL Core Documentation](https://postgresql.org/docs/12/static/app-pgbasebackup.html). +For information about `pg_basebackup`, see the [PostgreSQL Core Documentation](https://postgresql.org/docs/current/static/app-pgbasebackup.html). diff --git a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx index 54629dd07b9..a3fe8894d09 100644 --- a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx +++ b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx @@ -37,6 +37,6 @@ You must meet the following requirements before implementing incremental backup: - The incremental backup must be on the same timeline as the parent backup. The timeline changes after each recovery operation so an incremental backup cannot use a parent backup from an earlier timeline. -For information about configuring these requirements, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/). +For information about configuring these requirements, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). The following section provides an overview of the basic incremental backup concepts. diff --git a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx index b433ff411af..8183d4802bd 100644 --- a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx +++ b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx @@ -14,7 +14,7 @@ Using incremental backups involves the following sequence of steps: The default `archive_path` is the BART backup catalog (`//archived_wals`). Using the `` parameter in the server section of the BART configuration file, you can specify the location where WAL files will be archived. - For more information about the `archive_path` parameter and configuring BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/). + For more information about the `archive_path` parameter and configuring BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). 2. Take an initial full backup with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. @@ -26,7 +26,7 @@ Using incremental backups involves the following sequence of steps: 5. The incremental backup process identifies which WAL files may contain changes from when the parent backup was taken to the starting point of the incremental backup. The corresponding MBM files are used to locate and copy the modified blocks to the incremental backup directory along with other database cluster directories and files. Instead of backing up all, full relation files, only the modified blocks are copied and saved. In addition, the relevant MBM files are condensed into one consolidated block map (CBM) file that is stored with the incremental backup. - Multiple block copier threads can be used to copy the modified blocks to the incremental backup directory. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for information about setting the `thread_count` parameter in the BART configuration file. See [Backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for information about using the `--thread-count` option with the `BACKUP` subcommand. + Multiple block copier threads can be used to copy the modified blocks to the incremental backup directory. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting the `thread_count` parameter in the BART configuration file. See [Backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for information about using the `--thread-count` option with the `BACKUP` subcommand. 6. Invoke the restore process for an incremental backup using the `RESTORE` subcommand in the same manner as restoring a full backup. The `-i` option specifies the backup identifier or name of the incremental backup to restore. The restore process begins by going back through the chain of past, parent incremental backups until the initial full backup starting the chain is identified. This full backup provides the initial set of directories and files to be restored to the location specified with the `-p` option. Each subsequent incremental backup in the chain is then restored. Restoration of an incremental backup uses its CBM file to restore the modified blocks from the incremental backup. diff --git a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx index b62fd717336..5264499e13e 100644 --- a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx +++ b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx @@ -49,6 +49,6 @@ MBM files have the suffix, `.mbm`. In preparation for any incremental backup, the WAL files should be scanned as soon as they are copied to the `archive_path`. Thus, the WAL scanner should be running as soon as the WAL files from the database cluster are archived to the `archive_path`. If the `archive_path` contains WAL files that have not yet been scanned, starting the WAL scanner begins scanning these files. If WAL file fails to be scanned (resulting in a missing MBM file), you can use the WAL scanner to specify an individual WAL file. -Under certain conditions such as when the Network File System (NFS) is used to copy WAL files to the `archive_path`, the WAL files may have been missed by the WAL scanner program for scanning and creation of MBM files. Use the `scan_interval` parameter in the BART configuration file to initiate force scanning of WAL files in the `archive_path` to ensure MBM files are generated. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for more information about the `scan_interval` parameter. +Under certain conditions such as when the Network File System (NFS) is used to copy WAL files to the `archive_path`, the WAL files may have been missed by the WAL scanner program for scanning and creation of MBM files. Use the `scan_interval` parameter in the BART configuration file to initiate force scanning of WAL files in the `archive_path` to ensure MBM files are generated. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about the `scan_interval` parameter. See [Running the BART WAL Scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) for information about using the WAL scanner. diff --git a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx index a511a1938fe..c86914aa329 100644 --- a/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx +++ b/product_docs/docs/bart/2.5/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx @@ -37,6 +37,6 @@ No editing is needed in the `bart.cfg` file installed on the remote host. **Step 2:** Determine the Linux operating system user account on the remote host to be used as the remote user. This user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup. The remote user must be the owner of the directory where the incremental backup is to be restored on the remote host. By default, the user account is `enterprisedb` for Advanced Server or `postgres` for PostgreSQL. -**Step 3:** Ensure a passwordless SSH/SCP connection is established from the BART user on the BART host to the remote user on the remote host. For information about creating a passwordless SSH/SCP connection, see the *EDB Backup and Recovery Installation and Upgrade Guide*, available at the [EDB website](/bart/2.5/bart_inst/). +**Step 3:** Ensure a passwordless SSH/SCP connection is established from the BART user on the BART host to the remote user on the remote host. For information about creating a passwordless SSH/SCP connection, see the *EDB Backup and Recovery Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). -When restoring an incremental backup, specify the backup identifier or name of the incremental backup that will be restored. See the [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) documentation for more details. To view an example of restoring an incremental backup, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/). +When restoring an incremental backup, specify the backup identifier or name of the incremental backup that will be restored. See the [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) documentation for more details. To view an example of restoring an incremental backup, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.5/bart_user/02_overview/02_creating_a_backup_chain.mdx b/product_docs/docs/bart/2.5/bart_user/02_overview/02_creating_a_backup_chain.mdx index d45de3e33ab..644040d87f1 100644 --- a/product_docs/docs/bart/2.5/bart_user/02_overview/02_creating_a_backup_chain.mdx +++ b/product_docs/docs/bart/2.5/bart_user/02_overview/02_creating_a_backup_chain.mdx @@ -19,4 +19,4 @@ Since restoration of an incremental backup is dependent upon first restoring the The actions of retention policy management are applied to the full backup and all of its successive incremental backups within the chain in an identical manner as if they were one backup. Thus, use of retention policy management does not result in the breakup of a backup chain. -See the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/2.5/bart_ref/) for examples of creating a backup chain and restoring an incremental backup. +See the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/) for examples of creating a backup chain and restoring an incremental backup. diff --git a/product_docs/docs/bart/2.5/bart_user/02_overview/index.mdx b/product_docs/docs/bart/2.5/bart_user/02_overview/index.mdx index 8a5e6c69b66..7b5b7e92fb3 100644 --- a/product_docs/docs/bart/2.5/bart_user/02_overview/index.mdx +++ b/product_docs/docs/bart/2.5/bart_user/02_overview/index.mdx @@ -15,11 +15,11 @@ BART provides a simplified interface for the continuous archiving and point-in-t - Archiving the `Write-Ahead Log segments` (WAL files), which continuously record changes to be made to the database files. - Performing *Point-In-Time Recovery* (PITR) to a specified transaction ID or timestamp with respect to a timeline using a full backup along with successive, [block-level incremental backups](01_block-level_incremental_backup/#block-level_incremental_backup) that reside in the same backup chain, and the WAL files. -Detailed information regarding WAL files and point-in-time recovery is documented in the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/12/static/continuous-archiving.html). +Detailed information regarding WAL files and point-in-time recovery is documented in the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). The general term *backup* refers to both full backups and incremental backups. -When taking a full backup of a standby server, BART uses the PostgreSQL `pg_basebackup` utility program. However, it must be noted that for standby servers, you can only take a full backup, but cannot take an incremental or parallel backups. For information about standby servers, see the [PostgreSQL Documentation](https://www.postgresql.org/docs/12/static/high-availability.html). +When taking a full backup of a standby server, BART uses the PostgreSQL `pg_basebackup` utility program. However, it must be noted that for standby servers, you can only take a full backup, but cannot take an incremental or parallel backups. For information about standby servers, see the [PostgreSQL Documentation](https://www.postgresql.org/docs/current/static/high-availability.html). BART uses a centralized backup catalog, a single configuration file, and a command line interface controlling the necessary operations to simplify the management process. Reasonable defaults are automatically used for various backup and restore options. BART also performs the necessary recovery file configuration required for point-in-time recovery using its command line interface. @@ -59,7 +59,7 @@ Other concepts and terms referred to in this document include the following: - **Secure Shell (SSH)/Secure Copy (SCP).** Linux utility programs used to log into hosts (SSH) and copy files (SCP) between hosts. A valid user account must be specified that exists on the target host and in fact is the user account under which the SSH or SCP operations occur. -For information on how all of these components are configured and used with BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/). +For information on how all of these components are configured and used with BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). **Supported BART Operations** diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx index f6daf08042c..8b5fdec0c09 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx @@ -18,7 +18,7 @@ The following steps describe the process of restoring a backup: If you want to restore to a new, empty directory, create the directory on which you want to restore the backed up database cluster. Ensure the data directory can be written to by the BART user account or by the user account specified by the `remote_host` configuration parameter, or by the `--remote-host` option of the `RESTORE` subcommand (if these are to be used). -**Step 4:** Perform the same process for tablespaces as described in Step 3. The `tablespace_path` parameter in the BART configuration file must contain the tablespace directory paths to which the tablespace data files are to be restored. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for more information about this parameter. +**Step 4:** Perform the same process for tablespaces as described in Step 3. The `tablespace_path` parameter in the BART configuration file must contain the tablespace directory paths to which the tablespace data files are to be restored. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about this parameter. **Step 5:** Identify the backup to use for the restore operation and obtain the backup ID or backup name. @@ -50,8 +50,8 @@ All files and directories must be owned by the user account that you intend to u **Step 11:** Start the database server to initiate recovery. After completion, check the database server log file to ensure the recovery was successful. -If the backup is restored to a different location than where the original database cluster resided, operations dependent upon the database cluster location may fail if supporting service scripts are not updated to reflect the location where the backup has been restored. For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide. +If the backup is restored to a different location than where the original database cluster resided, operations dependent upon the database cluster location may fail if supporting service scripts are not updated to reflect the location where the backup has been restored. For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the BART `Restore` subcommand. -An example of a restore operation is documented in the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/2.5/bart_ref/). +An example of a restore operation is documented in the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx index ffd0aa13bf7..caaaa89e7c0 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx @@ -48,4 +48,4 @@ The following steps outline how to perform a point-in-time recovery operation fo 9. Start the database server, which will then perform the point-in-time recovery operation if recovery settings are saved in the `postgresql.auto.conf` file. -For a detailed description of the `RESTORE` subcommand, see [Basic BART Subcommand Usage](../03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage). An example of a Point-in-Time Recovery operation is documented in the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the `Restore` subcommand. +For a detailed description of the `RESTORE` subcommand, see [Basic BART Subcommand Usage](../03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage). An example of a Point-in-Time Recovery operation is documented in the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the `Restore` subcommand. diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx index f30524d0e69..a4396239bfe 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx @@ -8,7 +8,7 @@ legacyRedirectsGenerated: -The retention policy is determined by the `retention_policy` parameter in the BART configuration file. It can be applied globally to all servers, but each server can override the global retention policy with its own. For information about creating a global retention policy and an individual database server retention policy, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/). +The retention policy is determined by the `retention_policy` parameter in the BART configuration file. It can be applied globally to all servers, but each server can override the global retention policy with its own. For information about creating a global retention policy and an individual database server retention policy, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). There are two types of retention policies - redundancy retention policy and the recovery window retention policy as described in the following sections. diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx index 2a744e416e8..def779a4026 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx @@ -144,4 +144,4 @@ When the `MANAGE` subcommand is invoked, BART evaluates active backups: !!! Note The status of backups currently marked as `obsolete` or `keep` is not changed. To re-evaluate such backups and then classify them, their status must first be reset to `active` with the `MANAGE -c nokeep` option. See [Marking the Backup Status](02_marking_the_backup_status/#marking_the_backup_status) for more information. -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/) to review examples of how to evaluate, mark, and delete backups using a redundancy retention policy and recovery window retention policy, as well as examples of `MANAGE` subcommand. +See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) to review examples of how to evaluate, mark, and delete backups using a redundancy retention policy and recovery window retention policy, as well as examples of `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx index 7b25ea009fe..c69f6b09086 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx @@ -37,7 +37,7 @@ When a [redundancy retention policy](03_setting_the_retention_policy/#redundancy When determining the number of backups that exceeds the number specified by the `retention_policy` parameter, only full backups are counted for the comparison. Incremental backups are not included in the count for the comparison against the `retention_policy` parameter setting. -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a redundancy retention policy is in effect. +See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a redundancy retention policy is in effect. ## Using a Recovery Window Retention Policy with Incremental Backups @@ -48,4 +48,4 @@ If the `MANAGE` command is invoked when BART is configured to use a [recovery wi The status of an incremental backup is changed to `obsolete` regardless of whether or not the date/time of when the incremental backup was taken still lies within the recovery window. -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a recovery window retention policy is in effect. +See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a recovery window retention policy is in effect. diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx index 6bb4215ed62..aa12cd957e2 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx @@ -48,9 +48,9 @@ bart BACKUP –s { | all } [ -F p] - Before performing the backup, BART checks to ensure if there is enough disk space to completely store the backup in the BART backup catalog. -- In the `postgresql.conf` file, ensure the `wal_keep_segments` configuration parameter is set to a sufficiently large value. A low setting of the `wal_keep_segments` configuration parameter may result in the deletion of some WAL files before the BART `BACKUP` subcommand saves them to the `archive_path`. For information about the `wal_keep_segments` parameter, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/12/static/runtime-config-replication.html). +- In the `postgresql.conf` file, ensure the `wal_keep_segments` configuration parameter is set to a sufficiently large value. A low setting of the `wal_keep_segments` configuration parameter may result in the deletion of some WAL files before the BART `BACKUP` subcommand saves them to the `archive_path`. For information about the `wal_keep_segments` parameter, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/runtime-config-replication.html). -- In the BART configuration file, setting `xlog_method=stream` will instruct the server to stream the transaction log in parallel with creation of the backup for a specific database server; otherwise the transaction log files are collected upon completion of the backup. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for details about database server setting. +- In the BART configuration file, setting `xlog_method=stream` will instruct the server to stream the transaction log in parallel with creation of the backup for a specific database server; otherwise the transaction log files are collected upon completion of the backup. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details about database server setting. !!! Note If the transaction log streaming method is used, the `-Fp` option for a plain text backup format must be specified with the `BACKUP` subcommand. @@ -74,7 +74,7 @@ Specify the following options as required. If you do not specify any of the foll | `-c `
`--compress-level ` | This is applicable only for full backup. Specify this option to use the gzip compression level on the tar file output. `compression_level` is a digit from 1 through 9, with 9 being the best compression. This option is applicable only for the tar format. | | `--parent { backup_id \| backup_name }` | Specify this option to take an incremental backup. `` is the backup identifier of a parent backup. `` is the user-defined alphanumeric name of a parent backup.
The parent is a backup taken prior to the incremental backup. The parent backup can be either a full backup or an incremental backup.
The option `–Fp` must be specified since an incremental backup can only be taken in plain text format.
An incremental backup cannot be taken on a standby database server. See [Block-Level Incremental Backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup) for additional information on incremental backups. | | `--backup-name ` | Specify this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
The backup name may include the following variables to be substituted by the timestamp values when the backup is taken: 1) `%year` – 4-digit year, 2) `%month` – 2-digit month, 3) `%day` – 2-digit day, 4) `%hour` 2-digit hour, 5) `%minute` – 2-digit minute, and 6) `%second` – 2-digit second.
To include the percent sign (`%`) as a character in the backup name, specify `%%` in the alphanumeric string.
If the backup name contains space characters (i.e. more than one word) or when referenced with the option `-i` by other subcommands (such as `restore`), enclose the string in single quotes or double quotes. See [backup name examples](#backup_name_examples).
If the `--backup-name` option is not specified, and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to use the number of worker threads to run in parallel to copy blocks for a backup.
If the option `--thread-count` is omitted, then the `thread_count` parameter in the BART configuration file applicable to this database server is used.
If the option `--thread-count` is not enabled for this database server, then the `thread_count` setting in the global section of the BART configuration file is used.
If the option `--thread-count` is not set in the global section as well, the default number of threads is 1.
If parallel backup is run with N number of worker threads, then it will initiate N+ 1 concurrent connections with the server.
Thread count will not be effective if backup is taken on a standby server.
For more information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.5/bart_inst/) | +| `--thread-count ` | Use this option to use the number of worker threads to run in parallel to copy blocks for a backup.
If the option `--thread-count` is omitted, then the `thread_count` parameter in the BART configuration file applicable to this database server is used.
If the option `--thread-count` is not enabled for this database server, then the `thread_count` setting in the global section of the BART configuration file is used.
If the option `--thread-count` is not set in the global section as well, the default number of threads is 1.
If parallel backup is run with N number of worker threads, then it will initiate N+ 1 concurrent connections with the server.
Thread count will not be effective if backup is taken on a standby server.
For more information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/) | | `--with-pg_basebackup` | This is applicable only for full backup. Specify this option to use `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the option `--with-pg_basebackup` is specified with the `BACKUP` subcommand. | | `--no-pg_basebackup` | This is applicable only for full backup. Specify this option if you do not want `pg_basebackup` to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the option `--no-pg_basebackup` is specified with the `BACKUP` subcommand. | | `--check` | This is applicable only for incremental backup. Specify this option to verify if the required MBM files are present in the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file before taking an incremental backup. The option `--parent` must be specified when the option `--check` is used. An actual incremental backup is not taken when the option `--check` is specified. | diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx index 17424fed04b..52a74badaa7 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx @@ -12,7 +12,7 @@ The `MANAGE` subcommand can be invoked to: - Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file (See [Managing Backups Using a Retention Policy](../02_managing_backups_using_a_retention_policy/#managing_backups_using_a_retention_policy) for information about retention policy management). -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file (See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for information about setting this parameter). +- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file (See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting this parameter). **Syntax:** diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx index 0d9b25e4fbd..d74a4d1f5d6 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx @@ -22,14 +22,14 @@ bart RESTORE –s -p [ -c ] ``` -For information about using a continuous archive backup for recovery, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/12/static/continuous-archiving.html). This reference material provides detailed information about the underlying point-in-time recovery process and the meaning and usage of the restore options that are generated into the `postgresql.auto.conf` file by BART. +For information about using a continuous archive backup for recovery, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/13/static/continuous-archiving.html). This reference material provides detailed information about the underlying point-in-time recovery process and the meaning and usage of the restore options that are generated into the `postgresql.auto.conf` file by BART. **Please note**: - For special requirements when restoring an incremental backup to a remote database server, see [Restoring an Incremental Backup on a Remote Host](../../02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup/#restoring_an_incremental_backup_on_a_remote_host). - Check to ensure that the host where the backup is to be restored contains enough disk space for the backup and its archived WAL files. The `RESTORE` subcommand may result in an error while copying files if there is not enough disk space available. - See [Performing a Restore Operation](../01_bart_management_overview/01_performing_a_restore_operation/#performing_a_restore_operation) to view steps on how to perform a restore operation and see [Point-In-Time Recovery Operation](../01_bart_management_overview/02_point_in_time_recovery_operation/#point_in_time_recovery_operation) to view steps on how to perform a point-in-time recovery operation. -- If the backup is restored to a different database cluster directory than where the original database cluster resided, certain operations dependent upon the database cluster location may fail. This happens if their supporting service scripts are not updated to reflect the new directory location of restored backup. For information about the usage and modification of service scripts, see the *EDB Advanced Server Installation Guide*. +- If the backup is restored to a different database cluster directory than where the original database cluster resided, certain operations dependent upon the database cluster location may fail. This happens if their supporting service scripts are not updated to reflect the new directory location of restored backup. For information about the usage and modification of service scripts, see the *EDB Advanced Server Installation Guide* available at the [EDB website](/epas/latest/). The following table describes the command options: @@ -38,9 +38,9 @@ The following table describes the command options: | `-s `
`--server ` | `` is the name of the database server to be restored. | | `-p `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | | `-i { \| }`

`--backupid { \| }` | `` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the default is to use the latest backup. | -| `-r or --remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored and `` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `` parameter for this database server is not set in the BART configuration file.
If the BART user account is not the same as the operating system account owning the `` directory given with the `-p` option, use the `` BART configuration parameter or the `RESTORE` subcommand `-r` option to specify the `` directory owner even when restoring to a directory on the same host as the BART host.
See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for information about the `` parameter. | +| `-r or --remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored and `` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `` parameter for this database server is not set in the BART configuration file.
If the BART user account is not the same as the operating system account owning the `` directory given with the `-p` option, use the `` BART configuration parameter or the `RESTORE` subcommand `-r` option to specify the `` directory owner even when restoring to a directory on the same host as the BART host.
See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `` parameter. | | `-w `
`--workers ` | `` is the specification of the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location.
For example, if 4 worker processes are specified, 4 receiver processes on the restore host and 4 streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process. When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. If the `-w` option is omitted, the default is `1` \| worker process. | | `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | | `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. Include either the `-x ` or the `--target-xid ` option if point-in-time recovery is desired. | | `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. Include either the `--target-timestamp ` or the `-g ` option if point-in-time recovery is desired. | -| `-c`
`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
If recovery settings are saved in the `postgresql.auto.conf` file for point-in-time recovery, the `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, the `restore_command` in the `postgresql.auto.conf` file is generated by default to retrieve the archived WAL files directly from the BART backup catalog. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for information about the `copy_wals_during_restore` parameter. | \ No newline at end of file +| `-c`
`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
If recovery settings are saved in the `postgresql.auto.conf` file for point-in-time recovery, the `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, the `restore_command` in the `postgresql.auto.conf` file is generated by default to retrieve the archived WAL files directly from the BART backup catalog. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `copy_wals_during_restore` parameter. | \ No newline at end of file diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx index 8dc5080fcef..379dd137082 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx @@ -10,7 +10,7 @@ legacyRedirectsGenerated: This section briefly describes the BART subcommands and options. You can invoke the `bart` program (located in the `/bin` directory) with the desired options and subcommands to manage your BART installation. -To view examples of BART subcommands, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/). +To view examples of BART subcommands, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). **Syntax for invoking BART**: @@ -39,7 +39,7 @@ If execution of BART subcommands fails with the following error message, then yo **Workaround:** Set the `LD_LIBRARY_PATH` environment variable for the BART user account to include the directory containing the `libpq` library. This directory is `POSTGRES_INSTALL_HOME/lib`. -It is suggested that the `PATH` and the `LD_LIBRARY_PATH` environment variable settings be placed in the BART user account’s profile. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for details. +It is suggested that the `PATH` and the `LD_LIBRARY_PATH` environment variable settings be placed in the BART user account’s profile. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details. In the following sections, the `help` option is omitted from the syntax diagrams for the purpose of providing readability for the subcommand options. diff --git a/product_docs/docs/bart/2.5/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.5/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx index 9b111c3ba0e..b047505556e 100644 --- a/product_docs/docs/bart/2.5/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx +++ b/product_docs/docs/bart/2.5/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx @@ -30,13 +30,13 @@ bart-scanner The WAL scanner processes each WAL file to find and record modified blocks in a corresponding modified block map (MBM) file. The default approach is that the WAL scanner gets notified whenever a new WAL file is added to the `archived_wals` directory specified in the `archive_path` parameter of the configuration file. It then scans the WAL file and produces the MBM file. -The default approach does not work in some cases; for example when the WAL files are shipped to the `archive_path` using the Network File System (NFS) and also in case of some specific platforms. This results in the WAL files being copied to the `archived_wals` directory, but the WAL scanner does not scan them (as WAL scanner is not aware of WAL file) and produce the MBM files. This results in the failure of an incremental backup. This can be avoided by using the timer-based WAL scanning approach, which is done by using the `scan_interval` parameter in the BART configuration file. The value for `scan_interval` is the number of seconds after which the WAL scanner will initiate force scanning of the new WAL files. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for more information about `scan_interval` parameter. +The default approach does not work in some cases; for example when the WAL files are shipped to the `archive_path` using the Network File System (NFS) and also in case of some specific platforms. This results in the WAL files being copied to the `archived_wals` directory, but the WAL scanner does not scan them (as WAL scanner is not aware of WAL file) and produce the MBM files. This results in the failure of an incremental backup. This can be avoided by using the timer-based WAL scanning approach, which is done by using the `scan_interval` parameter in the BART configuration file. The value for `scan_interval` is the number of seconds after which the WAL scanner will initiate force scanning of the new WAL files. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about `scan_interval` parameter. When the `bart-scanner` program is invoked, it forks a separate process for each database server enabled with the `allow_incremental_backups` parameter. The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option. Use the `--daemon` option to run the WAL scanner process in the background so that all output messages can be viewed in the BART log file. If the `--daemon` option is omitted, the WAL scanner process runs in the foreground and all output messages can be viewed from the terminal running the program as well as in the BART log file. -See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.5/bart_inst/) for additional information about WAL scanning, `allow_incremental_backups`, and `logfile` parameters. +See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for additional information about WAL scanning, `allow_incremental_backups`, and `logfile` parameters. !!! Note The BART user account’s `LD_LIBRARY_PATH` environment variable may need to be set to include the directory containing the `libpq` library if invocation of the WAL scanner program fails. See [Basic BART Subcommand Usage](03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage) for information about setting the `LD_LIBRARY_PATH` environment variable. diff --git a/product_docs/docs/bart/2.5/bart_user/04_using_tablespaces.mdx b/product_docs/docs/bart/2.5/bart_user/04_using_tablespaces.mdx index 1615d140aef..94d5450778a 100644 --- a/product_docs/docs/bart/2.5/bart_user/04_using_tablespaces.mdx +++ b/product_docs/docs/bart/2.5/bart_user/04_using_tablespaces.mdx @@ -52,8 +52,8 @@ In either case, the directories specified in the `tablespace_path` parameter mus If the database server is running on a remote host (in other words you are also using the `remote_host` configuration parameter or will specify the `--remote-host` option with the `RESTORE` subcommand), the specified tablespace directories must exist on the specified remote host. -To view example of backing up and restoring a database cluster on a remote host containing tablespaces, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/). +To view example of backing up and restoring a database cluster on a remote host containing tablespaces, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). The directories must be owned by the user account with which you intend to start the database server (typically the Postgres user account) with no access by other users or groups as is required for the directory path to which the main full backup is to be restored. -To view a sample BART managed backup and recovery system consisting of both local and remote database servers, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.5/bart_ref/). +To view a sample BART managed backup and recovery system consisting of both local and remote database servers, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.5/index.mdx b/product_docs/docs/bart/2.5/index.mdx index 478643cec40..5a4e4fd6cc0 100644 --- a/product_docs/docs/bart/2.5/index.mdx +++ b/product_docs/docs/bart/2.5/index.mdx @@ -1,7 +1,7 @@ --- title: Backup and Recovery Tool directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.5 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." + description: "EDB Backup and Recovery Tool Version 2.5.9 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." navigation: - "#Getting Started" - bart_inst @@ -10,9 +10,8 @@ navigation: - "#Guides" - bart_user - bart_ref -#legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.5" --- + + diff --git a/product_docs/docs/bart/2.6.1/bart_inst/02_installing_bart.mdx b/product_docs/docs/bart/2.6.1/bart_inst/02_installing_bart.mdx deleted file mode 100644 index 20b4b7e19e5..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/02_installing_bart.mdx +++ /dev/null @@ -1,429 +0,0 @@ ---- -title: 'Installing BART' - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/installing_bart.html" ---- - -This section will walk you through performing a fresh installation of BART on a host. Installation instructions are organized into the following platform/installer specific sections: - -- [Installing BART on a CentOS](#installing-bart-on-a-centos-host) -- [Installing BART on a RHEL Host](#installing-bart-on-a-rhel-host) -- [Installing BART on a CentOS or RHEL Host](#installing-bart-on-a-rhelcentos-7-ppcle-host) -- [Installing BART on a Debian or Ubuntu Host](#installing-bart-on-a-debian-or-ubuntu-host) -- [Installing BART on an SLES 12 Host](#installing-bart-on-an-sles-12-host) - -!!! Note - If you are using the pdf version of this document, using cut/paste to copy command may result in extra spaces or carriage returns in the pasted command. If a command fails, check the command carefully for additional characters. - -## Installing BART on a CentOS Host - -The following section demonstrates installing BART on a CentOS host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. To install the repository configuration, assume superuser privileges and invoke one of the following platform-specific commands: - - On CentOS 7: - - ```text - yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - - On CentOS 8: - - ```text - dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Replace the `USERNAME:PASSWORD` in the following command with the username and password of a registered EnterpriseDB user: - - ```text - sed -i "s@:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -3. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - On CentOS 7: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - - On CentOS 8: - - ```text - dnf -y install epel-release - ``` - -4. For CentOS 8, enable the PowerTools repository to satisfy EPEL package dependencies: - - ```text - dnf config-manager --set-enabled PowerTools - ``` - -5. For CentOS 8, disable the built-in PostgreSQL module: - - ```text - dnf -qy module disable postgresql - ``` - -6. Optionally, install the `pg_basebackup` utility program using the server client package. If you do not already have the `pg_basebackup` program installed on the BART host, you can install a limited number of files that include the `pg_basebackup` program by invoking the following command: - - On CentOS 7: - - ```text - yum install edb-as-server-client - ``` - - On CentOS 8: - - ```text - dnf install edb-as-server-client - ``` - - In the above command, replace `` with the required Advanced Server version. The `pg_basebackup` version must be the same or more recent than the database server to be backed up. For example, `pg_basebackup` version 10 can be used to back up database server version 10, but cannot be used to back up database server version 11. - -7. Use the following command to install BART: - - On CentOS 7: - - ```text - yum -y install edb-bart - ``` - - On CentOS 8: - - ```text - dnf -y install edb-bart - ``` - - Repeat the installation process described in this section to install BART on each remote host on which an incremental backup is to be restored. - - To verify the BART installation, navigate to the `/usr/edb/bart/bin` directory and execute the following command: - - ```text - bart --version - ``` - - The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - - - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - Upon successful installation, BART is installed in the `BART_HOME` directory: - - `/usr/edb/bart` - - The installation includes the following files: - -| File Name | Location | Description | -| ------------------- | ----------------- | ------------------------------------- | -| bart | ``/bin | BART command line, executable program | -| bart-scanner | ``/bin | BART WAL scanner program | -| bart.cfg.sample | ``/etc | Sample BART configuration file | -| xlogreader_ident.so | ``/lib | Libraries supporting WAL versions | -| bart_license.txt | `` | License agreement | - -After BART is installed successfully, you need to [configure the installation](03_configuring_bart/#configuration). - -## Installing BART on a RHEL Host - -The following section demonstrates installing BART on a RHEL host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. To install the repository configuration, assume superuser privileges and invoke one of the following platform-specific commands: - - On RHEL 7: - - ```text - yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - - On RHEL 8: - - ```text - dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Replace the `USERNAME:PASSWORD` in the following command with the username and password of a registered EnterpriseDB user: - - ```text - sed -i "s@:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -3. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - On RHEL 7: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - - On RHEL 8: - - ```text - dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - ``` - -4. Enable the repository: - - On RHEL 7, enable the `optional, extras`, and `HA` repositories to satisfy EPEL package dependencies: - - ```text - subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms" - ``` - - On RHEL 8, enable the `codeready-builder-for-rhel-8-*-rpms` repository to satisfy EPEL packages dependency: - - ```text - ARCH=$( /bin/arch ) - - subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms" - ``` - -5. For RHEL 8, disable the built-in PostgreSQL module: - - ```text - dnf -qy module disable postgresql - ``` - -6. Optionally, install the `pg_basebackup` utility program using the server client package. If you do not already have the `pg_basebackup` program installed on the BART host, you can install a limited number of files that include the `pg_basebackup` program by invoking the following command: - - On RHEL 7: - - ```text - yum install edb-as-server-client - ``` - - On RHEL 8: - - ```text - dnf install edb-as-server-client - ``` - - In the above command, replace `` with the required Advanced Server version. The `pg_basebackup` version must be the same or more recent than the database server to be backed up. For example, `pg_basebackup` version 10 can be used to back up database server version 10, but cannot be used to back up database server version 11. - -7. Use the following command to install the BART: - - On RHEL 7: - - ```text - yum -y install edb-bart - ``` - - On RHEL 8: - - ```text - dnf -y install edb-bart - ``` - - Repeat the installation process described in this section to install BART on each remote host on which an incremental backup is to be restored. - - To verify the BART installation, navigate to the `/usr/edb/bart/bin` directory and execute the following command: - - ```text - bart --version - ``` - - The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - - - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - Upon successful installation, BART is installed in the `BART_HOME` directory: - - `/usr/edb/bart` - - The installation includes the following files: - -| File Name | Location | Description | -| ------------------- | ----------------- | ------------------------------------- | -| bart | ``/bin | BART command line, executable program | -| bart-scanner | ``/bin | BART WAL scanner program | -| bart.cfg.sample | ``/etc | Sample BART configuration file | -| xlogreader_ident.so | ``/lib | Libraries supporting WAL versions | -| bart_license.txt | `` | License agreement | - -After BART is installed successfully, you need to [configure the installation](03_configuring_bart/#configuration). - - - -## Installing BART on a RHEL/CentOS 7 PPCLE Host - -The following section demonstrates installing BART on a RHEL host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. Install Advance Toolchain: - - ```text - rpm --import https://public.dhe.ibm.com/software/server/POWER/Linux/toolchain/at/redhat/RHEL7/gpg-pubkey-6976a827-5164221b - - cat > /etc/yum.repos.d/advance-toolchain.repo <:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -4. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - -5. On RHEL 7, enable the `optional, extras`, and `HA` repositories to satisfy EPEL package dependencies: - - ```text - subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms" - ``` - -6. Invoke the following command to install BART: - - ```text - yum -y install edb-bart - ``` - - - -## Installing BART on a Debian or Ubuntu Host - -Perform the following steps to install a Debian package using the EnterpriseDB apt repository. - -To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/repository-access-request). - -1. Assume the superuser privileges. - - ```text - sudo su - - ``` - -2. To configure the EnterpriseDB repository on Debian 9, Ubuntu 18, and Ubuntu 20: - - ```text - sh -c 'echo "deb https://username:password@apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' - ``` - - On Debian 10: - - a. Set up the EnterpriseDB repository: - - ```text - sh -c 'echo "deb [arch=amd64] https://apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' - ``` - - b. Substitute your EnterpriseDB credentials for the `username` and `password` placeholders in the following command: - - ```text - sh -c 'echo "machine apt.enterprisedb.com login password " > /etc/apt/auth.conf.d/edb.conf' - ``` - -3. Add support to your system for secure APT repositories. - - ```text - apt-get install apt-transport-https - ``` - -4. Add the EDB signing key; When invoking the command, replace the `username` and `password` with the credentials provided by EnterpriseDB. - - ```text - wget -q -O - https://apt.enterprisedb.com/edb-deb.gpg.key | apt-key add – - ``` - -5. Update the repository metadata. - - ```text - apt-get update - ``` - -6. Install the Debian package. - - ```text - apt-get install edb-bart - ``` - - - -## Installing BART on an SLES 12 Host - -This section provides instructions for installing BART on an SLES 12 SP4 host using the zypper package manager. BART is supported on SLES SP4 and SP5 versions. - -1. Assume superuser privileges. - - ```text - sudo su - - ``` - -2. Use the following command to add the EDB repository to your SLES host: - - ```text - zypper addrepo https://zypp.enterprisedb.com/suse/edb-sles.repo - ``` - -3. Invoke the following command to refresh the metadata: - - ```text - zypper refresh - ``` - -4. Install `SUSEConnect` to register the host with SUSE to allow access to SUSE repositories: - - ```text - zypper install SUSEConnect - ``` - -5. Register the host with SUSE to allow access to SUSE repositories and replace `'REGISTRATION_CODE'` and `'EMAIL'` with your SUSE registration information: - - ```text - SUSEConnect -r 'REGISTRATION_CODE' -e 'EMAIL' - ``` - - ```text - SUSEConnect -p PackageHub/12.4/x86_64 - ``` - - ```text - SUSEConnect -p sle-sdk/12.4/x86_64 - ``` - -6. Install the following repository for PEM dependencies: - - ```text - zypper addrepo https://download.opensuse.org/repositories/Apache:/Modules/SLE_12_SP4/Apache:Modules.repo - ``` - -7. Refresh the metadata: - - ```text - zypper refresh - ``` - -8. Then, use the zypper utility to install BART: - - ```text - zypper -n install edb-bart - ``` diff --git a/product_docs/docs/bart/2.6.1/bart_inst/03_configuring_bart.mdx b/product_docs/docs/bart/2.6.1/bart_inst/03_configuring_bart.mdx deleted file mode 100644 index e9b3a129f84..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/03_configuring_bart.mdx +++ /dev/null @@ -1,641 +0,0 @@ ---- -title: "Configuring BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/configuring_bart.html" ---- - - - -To configure BART, you must establish the BART user account, [configure the BART host](#configuring-the-bart-host), and [configure the database server](#configuring_database_server) that will be backed up. - - - -## Establishing the BART User Account - -The BART user account is an operating system user that will run the BART command line program. The BART user account must: - -- own the BART backup catalog. -- be able to run the `bart` program and the `bart-scanner` program. -- be able to establish a SSH/SCP connection to and from each database server managed by BART. - -You can optionally use the `enterprisedb` database user as the BART user account for an Advanced Server database and `postgres` database user as the BART user account for a PostgreSQL server. If you do not wish to use an existing database user as the BART user account, you must create an operating system user to assume the role. - - - -## Configuring BART and Database Server - -As stated earlier, to configure BART, you must [configure the BART host](#configuring-the-bart-host) as well as the [database server](#configuring_database_server). The following table acts as a configuration parameter reference listing the mandatory and optional parameters with default values for `[SERVER]` as well as `[BART]` sections. - -- Parameters set in the `[BART]` section are applicable to all BART managed database servers. -- Parameters set in the `Server` section are applicable only to the specific server; the `Server` parameter setting overrides the `[BART]` section setting. - -For information about configuring BART host parameters, see the [BART Host Parameter Reference](#bart) and for information about configuring the database server parameters, see the [Database Server Parameter Reference](#server). - -| **Parameter** | **Type** | **Default** | **\[SERVER]** | **\[BART]** | -| -------------------------- | --------- | ------------------------------------------------------------ | ------------- | ----------- | -| `[BART]` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `retention_policy` | Optional | `BACKUPS` | Yes | Yes | -| `wal_compression` | Optional | `Disabled` | Yes | Yes | -| `copy_wals_during_restore` | Optional | `Disabled` | Yes | Yes | -| `xlog_method` | Optional | `fetch` | Yes | Yes | -| `logfile` | Optional | `/tmp/bart.log` | N/A | Yes | -| `scanner_logfile` | Optional | `/tmp/bart_scanner.log` | N/A | Yes | -| `` | Optional | `/tmp` | N/A | Yes | -| `` | Optional | `1` | Yes | Yes | -| `` | Optional | `49152` | Yes | Yes | -| `` | Optional | `0` | Yes | Yes | -| `` | Optional | `20 seconds` | Yes | Yes | -| `` | Optional | `1` | Yes | Yes | -| `[Server Name]` | Mandatory | N/A | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `host` | Mandatory | N/A | Yes | N/A | -| `port` | Mandatory | `5444` for EPAS; `5432` for Postgres | Yes | N/A | -| `user` | Mandatory | N/A | Yes | N/A | -| `` | Optional | `BART backup catalog` | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `` | Mandatory | `enterprisedb` for EPAS

`postgres` for PostgreSQL | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `allow_incremental_backup` | Optional | `Disabled` | Yes | N/A | -| `description` | Optional | N/A | Yes | N/A | - - - -### Configuring the BART Host - -To configure the BART host, perform the following steps on the BART host as a root user: - -**Step 1.** Navigate to the `usr/edb/bart/etc` directory and make a copy of the `bart.cfg.sample` file to create the `bart.cfg` file that will contain the parameter settings. - -**Step 2.** Confirm that the Postgres `pg_basebackup` utility program is installed on the BART host. The `pg_basebackup` utility resides in the `bin` directory under your Postgres installation. - - - -**Step 3.** Ensure the `LD_LIBRARY_PATH` environment variable includes the location of the `libpq` library. If your `libpq` library does not reside in the default location (`POSTGRES_INSTALL_HOME/lib`), you must add the library path to the `LD_LIBRARY_PATH` environment variable in the BART user account’s profile (`bash_profile`) located in `/home/`: - -```text -# .bash_profile -# Get the aliases and functions -if [ -f ~/.bashrc ]; then -. ~/.bashrc -fi -# User specific environment and startup programs -export LD_LIBRARY_PATH=/usr/edb/as11/lib:$LD_LIBRARY_PATH -``` - -**Step 4.** Create the BART backup catalog and ensure the BART user account holds privileges on the BART backup catalog. In the following example, the BART configuration file specifies `/opt/backup` as the parent directory for the BART backup catalog in the `` parameter: - -```text -[BART] - -bart_host = bartuser@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -``` - -In the following example, `bartuser` is the BART user account. The example creates and sets the ownership and permissions on the BART backup catalog: - -```text -su root -mkdir /opt/backup -chown bartuser /opt/backup -chgrp bartuser /opt/backup -chmod 700 /opt/backup -``` - -If the subdirectory does not exist, BART creates a subdirectory for each database server listed in the configuration file when you invoke the `bart` command line program. - -**Step 5.** Use your choice of editor to open the BART configuration file (located in the `usr/edb/bart/etc` directory) and edit the configuration as required. You must add the mandatory parameters to the `[BART]` section. Default values may be used for optional parameters. - -The following table describes the `[BART]` host parameters. - - - -| **Parameters/Placeholder** | **Type** | **Description** | -| -------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `[BART}` | Mandatory | Identifies the global section of the configuration file. It must be named BART. | -| `bart_host` | Mandatory | Specify the bart user name and the IP address of the bart host on which the BART utility resides. You must specify it in the form of <bart_user>@<bart_host_address>. | -| `backup_path` | Mandatory | Specify the path to the file system parent directory where all BART backups are stored. | -| `pg_basebackup_path` | Mandatory | Specify the path to the `pg_basebackup` program that you installed on the BART host. For information about `pg_basebackup` version-specific restrictions, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `wal_compression` | Optional | Set this parameter to `enabled` to compress the archived WAL files in gzip format in the BART backup catalog when the `MANAGE` subcommand is invoked. By default it is set to `disabled`. The gzip compression program must be in the BART user account’s `PATH` and the WAL compression setting must not be enabled for those database servers where you need to take incremental backups. | -| `copy_wals_during_restore` | Optional | Set this parameter to `enabled` to copy the archived WAL files from the BART backup catalog to the `restore_path/archived_wals` directory prior to the database server archive recovery. Enabling this option helps you save time during the restore operation. Set this parameter to `disabled` (default) to retrieve the archived WAL files directly from the BART backup catalog during the database server archive recovery. During the restore operation, recovery settings will be saved in the `postgresql.auto.conf` file. The `restore_command` in the `postgresql.auto.conf` file will be determined by the value specified in the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked with the `-c` option, the archived WAL files are copied from the BART backup catalog to the `restore_path/archived_wals` directory, thus overriding any setting of the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked without the `-c` option, the value specified by the `copy_wals_during_restore` parameter is used. | -| `xlog_method` | Optional | Specify how the transaction log is collected during the execution of `pg_basebackup` through the `BACKUP` subcommand. Set `xlog_method` to `fetch` (default) to collect the transaction log files after the backup is completed. Set to `stream` to stream the transaction log in parallel with the full backup creation. | -| `retention_policy` | Optional | Set this parameter to determine when an active backup should be marked as `obsolete` when the `MANAGE` subcommand is used. You can specify the retention policy either in terms of number of backups or duration (days, weeks, or months). ` BACKUPS` (default), ` DAYS`, ` WEEKS`, or ` MONTHS` where `` is a positive integer. For information about managing backups using a retention policy, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `logfile` | Optional | Use this parameter to specify the path to the BART log file. The default log file location is `/tmp/bart.log`. The log file will be created the first time you invoke the `bart` command line program using the sample configuration file value. To change the default setting, you must delete the `bart.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a log file. | -| `scanner_logfile` | Optional | Use this parameter to specify the path to the XLOG/WAL scanner log file. The default location is `/tmp/bart_scanner.log`. The scanner log file will be created the first time you invoke the `bart_scanner` program using the sample configuration file value. To change the default setting, you must delete the `bart_scanner.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a WAL scanner log file. | -| `` | Optional | Specify the socket directory path where all BART sockets will be stored. The default directory is `/tmp`. While specifying the `bart_socket_directory` path, you must ensure that the directory exists and the BART user has the required access permissions to the directory. | -| `` | Optional | Specify the number of worker threads for copying blocks (for incremental backups) or data files (for full backup) from the database server to the `archive_path` when the `BACKUP` subcommand is invoked. The default value is `1`. The same set of worker threads are used for the compression operation when taking full backups in order to provide parallel, compressed backups when the `BACKUP` subcommand is specified with the `-z` or `-c` options. The compression operation does not apply to incremental backups. See [thread count](#thread_count) for more information. | -| `` | Optional | Specify the number of blocks of memory used for copying modified blocks from the database server to the `archive_path` when the `BACKUP` subcommand is invoked for incremental backups. The default value is 49152 blocks; each block is 8192 bytes. The maximum permitted value is 131072 blocks and the minimum permitted value is 1 block. Reduce the `` setting if the server runs out of memory while executing the `pg_read_binary_file()`. | -| `` | Optional | Specify the number of seconds after which the WAL scanner should initiate force scanning of the new WAL files. The default value is 0, which means no brute-force scanning will be started. After upgrading to the latest version of BART, users who have set this parameter to a non-default value may see increased CPU consumption on the part of bart-scanner. If this is an issue, consider increasing the configured value of `scan_interval` parameter, or removing the setting if it is not required. | -| `` | Optional | Specify the number of seconds to wait for MBM files before timing out; this parameter is applicable only for incremental backup. You must set the `scan_interval` to a value significantly less than the MBM scan timeout. The default value is 20 seconds. The `mbm_scan_timeout` parameter value must be greater than 0. If the value is 0 or negative, then an error will be displayed during an incremental backup. | -| `` | Optional | Specify the number of parallel worker processes required to stream the modified blocks of an incremental backup to the restore host. The default value is 1. | - - - -**Thread Count** - -If the `BACKUP` subcommand is invoked with the `--thread-count` option, then the number of worker threads specified by this option overrides any setting of the `thread_count` parameter in the BART configuration file. If the `BACKUP` subcommand is invoked without the `--thread-count` option, then the following determines the number of worker threads used: - -- The setting of the `thread_count` parameter in the server section of the BART configuration file overrides the setting of `thread_count` in the global section for that particular database server. -- If omitted in the server section, the setting of `thread_count` in the global section is used. -- If the `thread_count` parameter is not specified in either section, the default is 1. -- When taking a full backup, if the `thread count` in effect is only 1, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. - -`` will not be effective if the backup is taken on a standby server. - -If parallel backup is run with `N` number of worker threads, then it will initiate `N + 1` concurrent connections with the server. - -**Step 6** Invoke the `CHECK-CONFIG` subcommand, omitting the `-s` option to check the parameter settings in the BART configuration file. It should return the current BART version. - -```text -bart CHECK-CONFIG -``` - -The `CHECK-CONFIG` subcommand displays an error message if the required configuration is not properly set. You need to check the logfile to fix this. - - - -### Configuring the Database Server - -To configure the database server, you must: - -1. [Authorize SSH/SCP access without a password prompt](#authorizing_ssh_scp_access). -2. [Create and configure a replication database user](#setting_up_a_replication_database_user). -3. [Adding the database server to the configuration file (server section)](#adding_a_database_server). -4. [Enable WAL archiving of the server](#enabling_wal_archiving). -5. [Verify the server configuration settings](#verifying_configuration_settings). - -The following section will walk you through the configuration process. - -!!! Note - You must authorize SSH/SCP access and set up a replication database user before restarting the database server with WAL archiving enabled. - - - -**Authorizing SSH/SCP Access** - -BART uses the Secure Shell (`ssh`) and Secure Copy (`scp`) Linux utility programs to copy the backup and WAL files from the BART managed database servers to the BART host as well as to restore backups. - -- The client/server `ssh` and `scp` commands must not prompt for a password when establishing a connection with the target server (the server to which a passwordless connection is being made). -- A passwordless connection uses *authorized public keys* (public key of a client user account) to authenticate with the target server. -- You must add the public key of each client user account to the target user account’s authorized public keys list on the target server. - -For BART usage, there are two scenarios that require a passwordless SSH/SCP connection: - -- When connecting from each BART managed database server (SSH/SCP client) to the BART host (target SSH/SCP server) to support WAL archiving as implemented by the `archive_command` parameter. - - In this case, the database server user account should generate the public key file (`id_rsa.pub`) with the `ssh-keygen –t rsa` command on the database server host. - - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the BART host. The `authorized_keys` file is in the BART user account’s home directory. -- When connecting from the BART host (SSH/SCP client) to each BART managed database server (target SSH/SCP server) for taking incremental backups and for supporting restoration of the full backup, the archived WAL files, and the modified blocks, which occurs when the BART `RESTORE` subcommand is given. - - In this case, the BART user account should generate the public key file (`id_rsa.pub`) with the `ssh-keygen –t rsa` command on the BART host. - - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the database server host. The `authorized_keys` file is in the home directory of the user account that owns the directory where the database backup is to be restored. -- If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -See the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/) to view examples of creating a passwordless connection. - -**Enabling Public Key Authentication** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. - -1. In the SSH server daemon configuration file (`sshd_config`) located in the `/etc/ssh`, set the `PubkeyAuthentication` parameter to `yes`. -2. Reload the configuration file: - -```text -service sshd reload -``` - -If you get any SSH or SCP errors, examine the `/var/log/secure` log file. - -**Creating a Passwordless Connection** - -The following general instructions will walk you through generating a client’s public key file, creating the target server’s authorized public keys file, and creating a passwordless connection. - -**Step 1.** On the client system, log in as the user account that will be initiating the SSH or SCP connection. - -**Step 2.** Navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one and assign the required privileges to the user. - -**Step 3.** Generate the public key file with the following command. Accept all prompted defaults and do not specify a passphrase when prompted for one. - -```text -ssh-keygen –t rsa -``` - -The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -**Step 4.** While logged into the client where you just generated the public key file, use `SCP` to make a temporary copy of it on the target server: - -```text -scp ~/.ssh/id_rsa.pub @:tmp.pub -``` - -**Step 5.** Navigate into the target user account’s home directory and check for an existing `.ssh` subdirectory. If it does not exist, create one and assign the required privileges to the user. - -**Step 6.** Append the temporary, client’s public key file, `tmp.pub`, to the `authorized_keys` file. If an `authorized keys` file does not exist, create a new file, but do not completely replace any existing `authorized keys` file. - -```text -cat tmp.pub >> ~/.ssh/authorized_keys -``` - -Make sure the `authorized_keys` file is only accessible by the file owner and not by groups or other users. If the `authorized_keys` file does not have the required permission setting or it was newly created, change the file permissions as follows: - -```text -chmod 600 ~/.ssh/authorized_keys -``` - -**Step 7.** Delete the temporary public key file: - -```text -rm tmp.pub -``` - -Now, when logged into the client system as `user` there should be no prompt for a password when commands such as the following is given: - -```text -ssh target_user@host_address -``` - - - -**Setting up a Replication Database User** - -For each database server that is to be managed by BART, a database user must be chosen to serve as the *replication database user*. The replication database user sets the Postgres `archive_command` configuration parameter when the `INIT` subcommand in invoked and creates backups when the `BACKUP` subcommand is invoked. The replication database user must be a `superuser`. - -When executed with the PSQL client, the following PostgreSQL command creates a superuser to be the replication database user: - -`CREATE ROLE repuser WITH LOGIN SUPERUSER PASSWORD 'password';` - -The `pg_hba.conf` file must minimally permit the replication database user to have access to the database. - -In the following example, the `pg_hba.conf` file permits the `repuser` (replication database user) to have access to the `template1` database. The IP address from which `repuser` has access to `template1` database is the location of the BART host: - -**For pg_basebackup only:** If `pg_basebackup` is to be used for taking any backups (such as for standby servers), the replication database user must also be included in the `pg_hba.conf` file as a `replication` database connection as shown by the last entry in the following example. - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 repuser 192.168.2.22/32 md5 -host all enterprisedb 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -host replication repuser 192.168.2.22/32 md5 -``` - -The replication database user must be specified for the `user` parameter in the BART configuration file for the database server as shown in the following example: - -```text -[ACCTG] -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -description = "Accounting" -``` - -There must be no password prompt when connecting to the database server with the replication database user. There are several ways to permit this; one recommended method is to use a `.pgpass` file located in the BART user account’s home directory. - -For example, if `bartuser` is the BART user account, then the `.pgpass` file located in the `/home/bartuser` directory must contain the following entry: - -`192.168.2.24:5444::repuser:password` - -When `bartuser` invokes a BART backup, the password for the replication database user, `repuser`, is obtained from the `.pgpass` file of `bartuser` to connect to the database server running at `192.168.2.24` on `port 5444`. - -The `.pgpass` file must contain an entry for each BART managed database server and its corresponding replication database user and password. - - - -**Adding a Database Server to the BART Configuration File** - -To manage the backup and recovery of a database server, you must add entries to the `[SERVER]` section of the BART configuration file, which is located in `/etc` directory. - - - -*Database Server Parameter Reference* - -Set the following parameters in the \[`SERVER`] section of the BART configuration file. The parameter setting in the \[`SERVER`] section overrides the setting in the global \[`BART`] section for that particular database server. If omitted, the default value will be used. - -For each cluster serviced by BART, the following parameters are mandatory: - -```text -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -``` - -!!! Note - The port parameter setting is required only if the database server listens on a port other than the default (for example if Postgres listens on a port other than 5432). - -The following table describes the database server parameters. - - - - - - - - - -| **Parameters/Placeholder** | Type | **Description** | -| --------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `[ServerName]` | Mandatory | Specify the server name that you want to backup using BART. It is not case-sensitive when referenced with BART subcommand options. A lowercase conversion of this name is used to create a subdirectory in the BART backup catalog for storing the backups and WAL files for this database server (for eg., epas12). | -| `` | Optional | Specify a [template](#backup_name_template) for user-defined, friendly names that will be assigned to the backups of the database server. The maximum permitted length of backup name is 49 characters. The `` parameter can be overridden by the `--backup-name` option of the `BACKUP` subcommand. If this parameter is omitted from the BART configuration file, and the `--backup-name` option with a user-defined name is not specified with the `BACKUP` subcommand, then the backup can only be referenced in BART subcommands by the BART assigned, integer backup identifier. | -| `host` | Mandatory | Specify the IP address of the database server to be configured for backup. | -| `port` | Mandatory | Specify the port number identifying the database server instance (that is, the relevant database cluster) to be backed up. The default port number for EPAS is `5444` and for Postgres it is `5432`. The port parameter setting is only required if the database server listens on a port other than the default value. | -| `User` | Mandatory | Specify the replication database user name used by BART to establish the connection to the database server for full backups. See [Setting up a Replication Database User](#setting_up_a_replication_database_user) for more information. | -| `` | Optional | Specify the path where archived WAL files will be stored. The default location is the BART backup catalog (`//archived_wals`). | -| `` | Optional | When the `INIT` subcommand is used, the content and variables specified in the BART `` result in the archive command string to be generated into the `Postgres archive_command` parameter in the `postgresql.auto.conf` file. To configure the BART `` parameter, enclose the command string within single quotes ('). If you do not specify the `` parameter in the configuration file, the default setting is taken as `'scp %p %h:%a/%f'`. See [Archive Command Auto Configuration](#archive_command_auto_configuration) for information about variables. The BART `` parameter in the BART configuration file, and the Postgres `` parameter in the `postgresql.conf` file (or the `postgresql.auto.conf` file) refer to two different parameters that are to be set in different manner. | -| `` | Mandatory | Specify the Linux operating system user account that owns the database cluster. This is typically `enterprisedb` for Advanced Server database clusters installed in the Oracle compatible mode, or `postgres` for Advanced Server database clusters installed in the PostgreSQL compatible mode and PostgreSQL database clusters. | -| `` | Optional | Specify the IP address of the remote server to which a backup is to be restored. Specify this parameter in the form of `@`. `` is the user account on the target database server host that accepts a passwordless SSH/SCP login connection and owns the directory where the backup is to be restored. `` is the IP address of the remote host. For restoring a backup to a remote host or for restoring any backup where `` and the BART user account are not the same users, either this parameter must be set or it may be specified with the `-r` option with the BART `RESTORE` subcommand. | -| `` | Optional | Specify path to which tablespaces are to be restored in the format `OID = `; If the backup is to be restored to a remote host specified by the `` parameter, then the tablespace paths must exist on the remote host. | -| `allow_incremental_backups` | Optional | Set this parameter to `enabled` to enable use of the WAL scanner and permit taking incremental backups when the `BACKUP` subcommand is invoked with the `--parent` option. Set it to `disabled` (default) to disallow incremental backups and thus permit only full backups. For information about using the `BACKUP` subcommand and running the WAL scanner, please see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `Description` | Optional | Specify the description that will be used to identify the database server. | - -For information regarding the following parameters, see [configuring the BART host](#configuring-the-bart-host). - -- `retention_policy` -- `xlog_method` -- `wal_compression` -- `copy_wals_during_restore`. -- `thread_count`. -- `batch_size`. -- `scan_interval`. -- `mbm_scan_timeout`. -- `workers` - - - -**Backup Name Template** - -- The template is an alphanumeric string that may include the following variables that will be replaced with the timestamp values when the backup is taken: - - - `%year` to be replaced by 4-digit year - - `%month` to be replaced by 2-digit month - - `%day` to be replaced by 2-digit day - - `%hour` to be replaced by 2-digit hour - - `%minute` to be replaced by 2-digit minute - - `%second` to be replaced by 2-digit second - -- To include a percent sign (`%`) as a character in the backup name, specify `%%` in the template. - -- Do not enclose the template string in quotes even if you want the template to include space characters, otherwise the enclosing quotes are stored as part of the backup name. However, when referenced with the `-i` option by BART subcommands use of space characters in the backup name requires enclosing the backup name in quotes. - -The following example shows the configuration settings of three database servers: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute:%second -archive_command = 'cp %p %a/%f' -allow_incremental_backups = enabled -retention_policy = 8 BACKUPS -description = "Accounting" - -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -description = "Marketing" - -[HR] - -host = 127.0.0.1 -port = 5432 -user = postgres -cluster_owner = postgres -retention_policy = 4 DAYS -description = "Human Resources" -``` - - - -**Enabling WAL Archiving** - -WAL archiving must be enabled for the database server for which BART is to perform backup and recovery management. - -- The WAL Archiving Configuration section describes the manual WAL archiving configuration process. -- The Archive Command Auto Configuration section describes an automated WAL archiving process. - -*WAL Archiving Configuration* - -Set the following configuration parameters in the `postgresql.conf` file to enable WAL archiving - -- Set `wal_level` to `replica` or higher. -- Set `archive_mode` to `on`. -- Set the PostgreSQL `archive_command` parameter to copy the WAL files to the `archive_path`. The `archive_command` configuration parameter mentioned here is located in the `postgresql.conf` file; the PostgreSQL `archive_command` parameter is used in a different manner than the BART [archive_command](#archive_command). -- Set `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (the setting must be a minimum of 2). See [Configuring the BART host](#configuring-the-bart-host) for information about the `xlog_method` parameter. - -For detailed information about WAL archiving, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). - -The `ARCHIVE PATH` field displayed by the BART `SHOW-SERVERS` subcommand displays the full directory path where the WAL files should be copied as specified in the `archive_command` configuration parameter in the `postgresql.conf` file: - -```text --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : none -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -``` - -The parameter settings in the following example will copy the WAL files to a directory named `/opt/backup/acctg/archived_wals` on the BART host located at `192.168.2.22` as the `bartuser` user account. Using the `bartuser` account ensures that the operation will have sufficient permissions to copy to the BART backup catalog owned by `bartuser`. - -```text -archive_mode = on # allows archiving to be done - # (change requires restart) -archive_command = 'scp %p bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f' - # command to use to archive a logfile segment - # placeholders: %p = path of file to archive - # %f = file name only -... - -max_wal_senders = 1 # max number of walsender processes - # (change requires restart) -``` - -The database server must be restarted in order to initiate WAL archiving, but do not do so until you have verified that the full path of the BART backup catalog has been created by a prior BART subcommand or the archive operation will fail. - -Start the WAL scanner by executing the following command: - -```text -./bart-scanner -``` - - - -*Archive Command Auto Configuration* - -To enable WAL archiving: - -- In the `postgresql.conf` file, set the `wal_level` to `replica` or higher, `archive_mode` to `on`, and `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server as determined in the BART configuration file, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (that is, the setting must be a minimum of `2`). See [Configuring the BART host](#configuring-the-bart-host) for information on the `xlog_method` parameter. - -- Configure the Postgres `archive_command` parameter automatically with the `INIT` subcommand and restart the database server when you are ready to initiate WAL archiving. The `INIT` subcommand invokes the Postgres `ALTER SYSTEM` command to set the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME data directory`. For additional information about the `INIT` subcommand, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - - The archive command string that the `INIT` subcommand generates into the `postgresql.auto.conf` file is determined by the parameter setting of the BART `archive_command` parameter in the server section of the BART configuration file. If the BART `archive_command` parameter is not set in the server section for a given database server, the command string that is configured uses the following default format: - - `'scp %p %h:%a/%f'` - - The following table describes these variables: - -| **Variable** | **Description** | -| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `%p` | The path of the file to archive used by the Postgres archiving process. | -| `%h` | Will be replaced by the `@` as specified in the <bart_host> parameter setting. | -| `%a` | Will be replaced by the BART `archived_wals` directory as specified in the [archive path](#archive_path) parameter setting. If the `` is not specified, then the default directory is `//archived_wals`. `` is the lowercase conversion of the database server name. | -| `%f` | The archived file name used by the Postgres archiving process. | - -The placeholders `%h` and `%a` are replaced by the `INIT` subcommand when creating the archive command string. The placeholders `%p` and `%f` are not replaced by the `INIT` subcommand, but are kept as given to be used by the Postgres archiving process. - -For example, to use the default archive command format, the BART configuration file contains the following settings where the BART `archive_command` parameter is omitted from the server section for `ACCTG`: - -```text -[BART] - -bart_host= bartuser@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -description = "Accounting" -``` - -The `INIT` subcommand is invoked by BART user account `bartuser` as follows: - -```text -[bartuser@localhost ~]$ bart INIT -s acctg -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -``` - -If the BART backup catalog directory is not already complete, it will be completed. - -The resulting archive command string in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME/data directory` appears as follows: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f' -``` - -Run the `INIT` subcommand with the `-o` option to override any existing `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file. In addition, the `-o` option must be used to generate the command string if the `archive_mode` is set to off even if there are no existing settings of the `archive_command` in the `postgresql.conf` or `postgresql.auto.conf` files. - -In this example, the following BART configuration file is used with an explicit setting of the BART `archive_command` parameter: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -The `INIT` subcommand is invoked by BART user account `enterprisedb` as follows: - -```text --bash-4.1$ bart INIT -s acctg -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -``` - -The resulting Postgres `archive_command` parameter in the `postgresql.auto.conf` file appears as follows: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup/acctg/archived_wals/%f' -``` - -When the database server has been restarted, the `ARCHIVE COMMAND` field of the `SHOW-SERVERS` subcommand displays the active Postgres archive command as shown by the following example: - -```text --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : none -DISK UTILIZATION : 48.00 MB -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE SCOMMAND : `cp %p /opt/backup/acctg/archived_wals/%f` -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -``` - - - -**Verifying Configuration Settings** - -To verify the parameter settings of the database server specified, execute tthe `CHECK-CONFIG` subcommand with the `–s` option: - -```text -bart CHECK-CONFIG [ –s server_name ] -``` - -The `CHECK-CONFIG` subcommand confirms the following: - -- The `cluster_owner` parameter is set to the user account owning the database cluster directory. -- A passwordless SSH/SCP connection is set between the BART user and the user account specified by the `cluster_owner` parameter. -- The BART `user` parameter specifies a database superuser. -- The BART `user` has access to the backup directory catalog. -- The `pg_hba.conf` file contains a replication entry for the database superuser specified by the BART `user` parameter. -- The `archive_mode` parameter in the `postgresql.conf` file is enabled. -- The `archive_command` parameter in the `postgresql.auto.conf` or the `postgresql.conf` file is set. -- The `allow_incremental_backups` parameter in the BART configuration file is enabled for database servers for which incremental backups are to be taken. -- Archiving of WAL files to the `archive_path` is in process. -- The WAL scanner program is running. - -After configuring the BART host and the database server(s), you can start using BART. For information about using BART, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). diff --git a/product_docs/docs/bart/2.6.1/bart_inst/04_upgrading_bart.mdx b/product_docs/docs/bart/2.6.1/bart_inst/04_upgrading_bart.mdx deleted file mode 100644 index 587f13c4aaa..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/04_upgrading_bart.mdx +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: "Upgrading BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/upgrading_bart.html" ---- - - - -This section outlines the process of upgrading BART from an existing version to the latest version. - -- [Upgrading from BART 2.0](#upgrading-from-bart-20) describes the upgrade process from BART 2.0 to the latest version. -- [Upgrading from Older Versions of BART (except 2.0)](#upgrading_from_older_versions_except_2_0_to_latest_versions_of_bart) describes the upgrade process from previous BART versions (except 2.0) to the latest version. - -**Upgrade Restrictions** - -The following restrictions apply with regard to previous BART versions. - -- You can take incremental backups using the latest version only when the parent backup (full or incremental backup) has also been taken with the latest version. -- Using the latest version, you can restore incremental backups that are taken only with the latest version of BART. However, using the latest version you can restore full backups that were taken with older versions. - - - -## Upgrading from Older Versions of BART (except 2.0) - -Perform the following steps to upgrade from older versions of BART (except 2.0) to the latest version: - -**Step 1:** Assume the identity of the BART user account and invoke the following command to stop the BART WAL scanner program (`bart-scanner`): - -```text -bart-scanner STOP -``` - -**Step 2:** As the `root` user, upgrade to the latest BART version with the `yum upgrade` command. - -- To upgrade the BART RPM package directly from the *EDB Yum Repository* website, specify only the package name: - - On CentOS 7: - - ```text - yum upgrade edb-bart - ``` - - You can also use a downloaded RPM package file to upgrade. To use a downloaded BART RPM package file to upgrade, use the `yum` command, specifying the complete RPM package file name: - - ```text - yum upgrade edb-bart-2.6.1 rhel7.x86_64.rpm - ``` - -**Step 3:** Repeat the process described in this section to upgrade to the latest BART version on each remote hosts where an incremental backup will be restored. - -For additional information about restoration of incremental backups on remote hosts, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -**Step 4:** If the `bart --version` command returns an error stating the `PATH` is not available after switching from `root` user to another BART user account, adjust the setting of the `PATH` environment variable to include the location of the BART 2.6.1 executable (the `bin` subdirectory) in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - -- The BART user account on the BART host. -- The remote user account on the remote host to which incremental backups are to be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The `PATH` setting should be the same as set for BART 2.6.1 since all versions use `/usr/edb/bart/bin`. - -!!! Note - After upgrading to the latest BART version, you must take a new full backup of your system before performing an incremental backup. - - - -## Upgrading from BART 2.0 - -Perform the following steps to upgrade BART 2.0 to the latest version of BART: - -**Step 1:** Install the latest version of BART. For information about how to install, see [installing BART](02_installing_bart/#installing-bart). - -**Step 2:** Save a copy of your BART 2.0 configuration file. The default location of the BART 2.0 configuration file is `/usr/edb/bart2.0/etc/bart.cfg`. - -**Step 3:** Invoke the following command to remove BART 2.0: - - On CentOS 7: - -```text -yum remove edb-bart20 -``` - -**Step 4:** Place the BART 2.0 configuration file (`bart.cfg`) that you saved in Step 2 in the newly created `/usr/edb/bart/etc` directory. You can use many of the same configuration parameters for BART 2.6.1, but note that you must use a new directory for the BART backup catalog. A new set of full backups and incremental backups taken using BART 2.6.1 must be stored in a new BART backup catalog. - -To specify an alternative configuration file name or location, use the `-c` option with BART subcommands. For more information about the `-c` option, see the EDB Backup and Recovery Us available at the [EDB website](/bart/latest/bart_user/). - -!!! Note - The `bart.cfg` configuration file is only required on the BART 2.6.1 host from which you will invoke BART subcommands. BART does not require the `bart.cfg` file on hosts on which an incremental backup will be restored. - -**Step 5:** Adjust the setting of the `PATH` environment variable to include the location of the BART 2.6.1 executable (the `bin` subdirectory) in the `~/.bashrc` or `~/.bash_profile` files for the following user accounts: - -- The BART user account on the BART host. -- The user account on the remote host to which incremental backups will be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -**Step 6:** Perform the BART 2.6.1 installation and BART 2.0 removal process on each remote host on which an incremental backup was restored using BART 2.0. - -!!! Note - After upgrading to the latest BART version, you must take a new full backup of your system before performing an incremental backup. diff --git a/product_docs/docs/bart/2.6.1/bart_inst/05_uninstalling_bart.mdx b/product_docs/docs/bart/2.6.1/bart_inst/05_uninstalling_bart.mdx deleted file mode 100644 index 8374221ef88..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/05_uninstalling_bart.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Uninstalling BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/uninstalling_bart.html" ---- - - - -This section walks you through uninstalling BART. - -## Uninstalling BART on a RHEL/CentOS Host - -To uninstall BART on a RHEL/CentOS host, assume the identity of the `root` user and invoke the following command: - -On RHEL/CentOS 7: - -```text -yum remove edb-bart -``` - -On RHEL/CentOS 8: - -```text -dnf remove edb-bart -``` - -Uninstalling BART does not delete the backup files and archived WAL files that reside in the BART backup catalog. To permanently delete the backup files and archived WAL files in the BART backup catalog (`/opt/backup`), use one of the following commands: - -- `rm –rf /opt/backup` -- BART `DELETE` subcommand - -For information about the BART `DELETE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -## Uninstalling BART on an SLES 12 Host - -To uninstall BART on an SLES 12 host, assume the identity of the `root` user and invoke the following command: - -```text -zypper remove edb-bart -``` - -## Uninstalling BART on a Debian/Ubuntu Host - -To uninstall BART on a Debian or Ubuntu host, invoke the following command: - -```text -apt-get remove edb-bart -``` diff --git a/product_docs/docs/bart/2.6.1/bart_inst/images/EDB_logo.png b/product_docs/docs/bart/2.6.1/bart_inst/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.1/bart_inst/images/edb.png b/product_docs/docs/bart/2.6.1/bart_inst/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.1/bart_inst/images/edb_logo.svg b/product_docs/docs/bart/2.6.1/bart_inst/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.1/bart_inst/images/edblogo.png b/product_docs/docs/bart/2.6.1/bart_inst/images/edblogo.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/images/edblogo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.1/bart_inst/index.mdx b/product_docs/docs/bart/2.6.1/bart_inst/index.mdx deleted file mode 100644 index 84027aa9a38..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_inst/index.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -navTitle: Installation Guide -title: "EDB Postgres Backup and Recovery Installation Guide" -legacyRedirects: - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/requirements_overview.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/index.html" ---- - -This guide provides information about how to install and configure the EDB Backup and Recovery Tool (BART) 2.6.1. - - - -## Requirements Overview - -### Supported Platforms and Database Versions - -- To view a complete list of supported platforms, visit the [EDB website.](https://www.enterprisedb.com/services-support/edb-supported-products-and-platforms) - -!!! Note - BART 2.6.1 is no longer supported on CentOS/RHEL/OEL 6.x platforms. It is strongly recommended that EDB products running on these platforms be migrated to a supported platform. - -- BART supports the following database versions: - - - Advanced Server versions 9.6, 10, 11, 12, and 13. - - PostgreSQL versions 9.6, 10, 11, 12, and 13. - -### Software Requirements - -The following components are required for BART installation. - -- BART Host Components - Use EDB packages to add BART host components; see [Installing BART](02_installing_bart/#installing-bart) for information about how to install these components. - -- Additional Components - In addition to the BART host components, the following components are required: - - - The [Secure Shell (SSH) server daemon and Secure Copy (SCP) client programs](03_configuring_bart/#authorizing_ssh_scp_access) must be enabled and activated on the BART host as well as on the remote database server hosts on which BART will be managing backup and recovery. - - BART uses the `pg_basebackup` utility program when taking full backups. - -### Limitation - -BART supports taking only a full backup of standby servers; it does not support taking incremental or parallel backups of standby servers. diff --git a/product_docs/docs/bart/2.6.1/bart_qs_7/images/EDB_logo.png b/product_docs/docs/bart/2.6.1/bart_qs_7/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_7/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.1/bart_qs_7/images/edb.png b/product_docs/docs/bart/2.6.1/bart_qs_7/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_7/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.1/bart_qs_7/images/edb_logo.svg b/product_docs/docs/bart/2.6.1/bart_qs_7/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_7/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.1/bart_qs_7/images/image2.png b/product_docs/docs/bart/2.6.1/bart_qs_7/images/image2.png deleted file mode 100644 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_7/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.6.1/bart_qs_7/index.mdx b/product_docs/docs/bart/2.6.1/bart_qs_7/index.mdx deleted file mode 100644 index 14253b7d52e..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_7/index.mdx +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: "Quick Start Guide for RHEL/CentOS 7" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/index.html" ---- - -This tutorial demonstrates using `yum` to [install](#installing) and [configure](../bart_qs_8/#configuring) Backup and Recovery Tool (BART) 2.6.1 on a CentOS 7 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - -- BART is tested with the following database versions: - - - Advanced Server - 9.6, 10, 11, 12, and 13. - - PostgreSQL - 9.6, 10, 11, 12, and 13. - - - -**Installing BART** - -The following steps describe installing BART on CentOS 7.x OS using `yum`. - -1. Assume superuser privileges and use `yum` to create the repository configuration file: - - ```text - yum install -y https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Create an EDB user account to request credentials to the EDB repository; for a user account visit the [EnterpriseDB website](https://www.enterprisedb.com/repository-access-request). - -3. Use your choice of editor to open the repository configuration file (named `edb.repo`, located in `/etc/yum.repos.d`), and set the `enabled` parameter value to `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the username and password of a registered EnterpriseDB user. - -4. Update the cache: - - ```text - yum makecache - ``` - -5. Install an Advanced Server or PostgreSQL database server. - - To install Advanced Server, execute the following command: - - ```text - yum -y install edb-as12-server - ``` - - Use sudo to assume the identity of the `enterprisedb` database superuser - - ```text - sudo su - enterprisedb - ``` - - Create an Advanced Server cluster named `acctg` on listener port `5444`: - - ```text - /usr/edb/as12/bin/initdb -D /var/lib/edb/as12/acctg - ``` - - As the `enterprisedb` user, start the cluster: - - ```text - /usr/edb/as12/bin/pg_ctl start -D /var/lib/edb/as12/acctg - ``` - - You can check the status of the cluster with the following command: - - ```text - /usr/edb/as12/bin/pg_ctl status -D /var/lib/edb/as12/acctg - ``` - - !!! Note - The BART host server is not required to have an Advanced Server or PostgreSQL installation, but must include a copy of the Postgres `libpq` library, the `pg_basebackup` utility program, and Boost Libraries 1.53 version for CentOS 7. - -6. If you do not already have the `pg_basebackup` program installed on the BART host, you can use the following command to install a limited number of files that include the `pg_basebackup` program: - - ```text - yum install edb-as-server-client - ``` - - Where <xx> is the Advanced Server version. - -7. As a root user, execute the following command to install BART: - - ```text - yum install edb-bart - ``` - -BART (the bart program and bart-scanner) is installed in the `/usr/edb/bart/bin` directory, referred to as ``. Repeat the installation process described in this section to install BART on all remote hosts where incremental backups are to be restored. - - - -**Configuring BART** - -Before configuring BART, establish the BART user account (the operating system user) that will run the BART command line program. Then, to configure the BART host and each database server that is to be managed by BART, perform the following steps: - -1. Assume superuser privileges, create the directory that will hold the BART backup catalog, and assign its ownership (with restrictive privileges) to the BART user account: - - In this example, `bartuser` is the BART user account and `/opt/backup` is the BART backup catalog. - - ```text - su root - mkdir /opt/backup - chown bartuser /opt/backup - chgrp bartuser /opt/backup - chmod 700 /opt/backup - ``` - -2. Navigate to the `/usr/edb/bart/etc` directory and copy the `bart.cfg.sample` file to create the BART configuration file (`bart.cfg`): - - ```text - cp bart.cfg.sample bart.cfg - ``` - -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - - Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. - - In the following example, only mandatory parameters are set: - - ```text - [BART] - bart_host= bartuser@192.168.169.199 - backup_path = /opt/backup - pg_basebackup_path = /usr/edb/as12/bin/pg_basebackup - - [EPAS12] - host = 127.0.0.1 - user = repuser - cluster_owner = enterprisedb - ``` - -The following table describes only mandatory parameters: - -| **Parameters/Placeholder** | **Section** | **Description** | -| -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bart_host` | `[BART]` | Use this field to specify the BART user and the IP address of the host on which the BART utility is installed. Specify the value in the form of `@`. | -| `backup_path` | `[BART]` | Use this field to specify the path where all BART backups and archived WAL files will be stored. Ensure the BART user account holds privileges to create subdirectories and files within the location specified in the `backup_path` parameter. The default `backup_path` is BART backup catalog (`/opt/backup`). | -| `pg_basebackup_path` | `[BART]` | Use this field to specify the path to the pg_basebackup utility (`/usr/edb/as/bin/pg_basebackup`). | -| `[ServerName]` | `[ServerName]` | Specify the name of the database server to be backed up (for example, \[EPAS12]). | -| `host` | `[ServerName]` | Specify the IP address of the database server to be configured for backup. | -| `user` | `[ServerName]` | Specify the replication database user name used by BART to establish the connection to the database server for full backups. | -| `cluster_owner` | `[ServerName]` | Specify the Linux operating system user account that owns the database cluster. | - -4. As a BART user, navigate to `/usr/edb/bart/bin` and invoke the following subcommand (omitting the `-s` option) to verify the \[BART] section parameter settings: - - ```text - bart CHECK-CONFIG - ``` - -5. Authorize [SSH/SCP access](../bart_qs_8/#passwordless) between the server and the BART host without a password prompt. - -6. Create a [replication database user](../bart_qs_8/#replication) for each database server that BART manages. - -7. To enable continuous WAL archiving for any database server for which BART is to perform a backup, modify the `postgresql.conf` file, setting: - - - `wal_level` to `replica` or higher (for Postgres 9.6 or later) - - `archive_mode` to `on` - - `archive_command` (if it is not set in the `bart.cfg` file) - - `max_wal_senders` to a value high enough to leave at least one session available for the backup. - - After setting the parameters, restart the database server. - -8. To start the WAL scanner, navigate to `/usr/edb/bart/bin` as a BART user and execute the following command: - - ```text - ./bart-scanner - ``` - -9. If you are using the default `archive_command`, then navigate to `/usr/edb/bart/bin` as a BART user, run the `INIT` subcommand without the `-o` option, and restart the database server: - - ```text - bart INIT [ -s { | all } ] - ``` - - Where `` is the name of the database server to be backed up. - - If you have customized the `archive_command` setting in the `bart.cfg` file, run the `INIT` subcommand with the `-o` option to override any existing Postgresql `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file, and restart the database server. - - ```text - bart INIT [ -s { | all } ] [ -o ] - ``` - -10. To verify the database server parameter settings, as a BART user navigate to `/usr/edb/bart/bin` and invoke the `CHECK-CONFIG` subcommand with the -s option: - - ```text - bart CHECK-CONFIG [ -s ] - ``` - - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide*, available at the [EDB website](/bart/latest/bart_user/). - - - -**Creating a Passwordless Connection** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. You must create a passwordless connection between the BART host (SSH/SCP client) and the database server (target SSH/SCP server), as well as a passwordless connection between the database server (SSH/SCP client) and the BART host (target SSH/SCP server). - -1. Log in as the user account on the BART host that will be initiating the SSH or SCP connection and navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one with the required privileges. - -2. As a root user navigate to `/usr/edb/bart`, open the `/etc/ssh/sshd_config` file and set the `PubkeyAuthentication` parameter to `yes`. - -3. Reload the configuration file: - - ```text - service sshd reload - ``` - - If you get any SSH or SCP errors, examine the log file (`/var/log/secure`). - -4. As a BART user, use the following command to generate the public key file; you can accept the default responses: - - ```text - ssh-keygen -t rsa - ``` - - The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -5. Use `SCP` to make a temporary copy of the public key file on the target server: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -6. As a `target_user`, log into the target server using `ssh target_user@host_address` command and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges. - -7. Append the client’s temporary public key file, `tmp.pub`, to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - - If an `authorized_keys` file does not exist, create a new file, but be careful not to completely replace any existing `authorized_keys` file. - -8. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -9. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the BART host as a user, there should be no prompt for a password when you are connecting to the target database server: - - ```text - ssh target_user@database_server_address - ``` - -**Creating a Passwordless Connection Between the Database Server and the BART Host** - -If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). - -Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. - -1. On the database server, navigate into the target user account’s home directory to check for an existing `.ssh` subdirectory. If it does does not exist, create one in the user account’s home directory with the required privileges. - -2. As a database server user, generate the public key file: - - ```text - ssh-keygen -t rsa - ``` - -3. Create a temporary copy of the public key file: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -4. As a target user, log into the BART host and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges: - - ```text - ssh target_user@host_address - ``` - -5. Append the temporary, client’s public key file to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - -If an `authorized_keys` file does not exist, create a new file, but do not completely replace any existing `authorized_keys` file. - -6. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -7. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the database server as a user, there should be no prompt for a password when you are connecting to the BART host: - - ```text - ssh bart_user@bartip_address - ``` - - - -**Creating a Replication Database User** - -1. To create a replication database user (a superuser), connect to the database server with the psql client, and invoke the following PostgreSQL command: - - ```text - CREATE ROLE WITH LOGIN SUPERUSER PASSWORD ''; - ``` - -2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. - -3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. - -4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.6.1/bart_qs_8/images/EDB_logo.png b/product_docs/docs/bart/2.6.1/bart_qs_8/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_8/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.1/bart_qs_8/images/edb.png b/product_docs/docs/bart/2.6.1/bart_qs_8/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_8/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.1/bart_qs_8/images/edb_logo.svg b/product_docs/docs/bart/2.6.1/bart_qs_8/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_8/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.1/bart_qs_8/images/image2.png b/product_docs/docs/bart/2.6.1/bart_qs_8/images/image2.png deleted file mode 100644 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_8/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.6.1/bart_qs_8/index.mdx b/product_docs/docs/bart/2.6.1/bart_qs_8/index.mdx deleted file mode 100644 index 0067c183210..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_qs_8/index.mdx +++ /dev/null @@ -1,317 +0,0 @@ ---- -title: "Quick Start Guide for RHEL/CentOS 8" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/index.html" ---- - -This tutorial demonstrates using the `dnf` command to install and configure the EDB Backup and Recovery Tool (BART) 2.6.1 on a CentOS 8 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - -- BART is tested with the following database versions: - - - Advanced Server - 9.6, 10, 11, 12, and 13. - - PostgreSQL - 9.6, 10, 11, 12, and 13. - -**Installing BART** - -The following steps describe installing BART on CentOS 8.x OS. - -1. Assume superuser privileges and use `dnf` to create the repository configuration file: - - ```text - dnf install -y https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Create an EDB user account to request credentials to the EDB repository; for a user account visit the [EnterpriseDB website](https://www.enterprisedb.com/repository-access-request). - -3. Use your choice of editor to open the repository configuration file (named `edb.repo`, located in `/etc/yum.repos.d`) and set the value of the `enabled` parameter to `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the username and password of a registered EnterpriseDB user. - -4. Update the cache: - - ```text - dnf makecache - ``` - -5. Install an Advanced Server or PostgreSQL database server. - - To install Advanced Server, execute the following command: - - ```text - dnf -y install edb-as12-server - ``` - - Use sudo to assume the identity of the `enterprisedb` database superuser: - - ```text - sudo su - enterprisedb - ``` - - Create an Advanced Server cluster named `acctg` on listener port `5444`: - - ```text - /usr/edb/as12/bin/initdb -D /var/lib/edb/as12/acctg - ``` - - As the `enterprisedb` user, start the cluster: - - ```text - /usr/edb/as12/bin/pg_ctl start -D /var/lib/edb/as12/acctg - ``` - - You can check the status of the cluster with the following command: - - ```text - /usr/edb/as12/bin/pg_ctl status -D /var/lib/edb/as12/acctg - ``` - - !!! Note - The BART host server is not required to have an Advanced Server or PostgreSQL installation, but must include a copy of the Postgres `libpq` library, the `pg_basebackup` utility program, and Boost Libraries 1.66 version for CentOS 8. - -6. If you do not already have the `pg_basebackup` program installed on the BART host, you can use the following command to install a limited number of files that include the `pg_basebackup` program: - - ```text - dnf install edb-asxx-server-client - ``` - -7. As a root user, use the following command to install the BART RPM package: - - ```text - dnf install edb-bart - ``` - -BART (the `bart` program and `bart-scanner`) is installed in the `/usr/edb/bart/bin` directory, referred to as ``. Repeat the installation process described in this section to install BART on all remote hosts where incremental backups are to be restored. - - - -**Configuring BART** - -Before configuring BART, establish the BART user account (the operating system user) that will run the BART command line program. Then, to configure the BART host and each database server that is to be managed by BART, perform the following steps: - -1. Assume superuser privileges, create the directory that will hold the BART backup catalog, and assign its ownership (with restrictive privileges) to the BART user account: - - In this example, `bartuser` is the BART user account and `/opt/backup` is the BART backup catalog. - - ```text - su root - mkdir /opt/backup - chown bartuser /opt/backup - chgrp bartuser /opt/backup - chmod 700 /opt/backup - ``` - -2. Navigate to the `/usr/edb/bart/etc` directory and copy the `bart.cfg.sample` file to create the BART configuration file (`bart.cfg`): - - ```text - cp bart.cfg.sample bart.cfg - ``` - -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - - Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. - - In the following example, only mandatory parameters are set: - - ```text - [BART] - bart_host= bartuser@192.168.169.199 - backup_path = /opt/backup - pg_basebackup_path = /usr/edb/as12/bin/pg_basebackup - - [EPAS12] - host = 127.0.0.1 - user = repuser - cluster_owner = enterprisedb - ``` - -The following table describes only mandatory parameters: - -| **Parameters/Placeholder** | **Section** | **Description** | -| -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bart_host` | `[BART]` | Use this field to specify the BART user and the IP address of the host on which the BART utility is installed. Specify the value in the form of `@`. | -| `backup_path` | `[BART]` | Use this field to specify the path where all BART backups and archived WAL files will be stored. Ensure the BART user account holds privileges to create subdirectories and files within the location specified in the `backup_path` parameter. The default `backup_path` is BART backup catalog (`/opt/backup`). | -| `pg_basebackup_path` | `[BART]` | Use this field to specify the path to the pg_basebackup utility (`/usr/edb/as/bin/pg_basebackup`). | -| `[ServerName]` | `[ServerName]` | Specify the name of the database server to be backed up (for example, \[EPAS12]). | -| `host` | `[ServerName]` | Specify the IP address of the database server to be configured for backup. | -| `user` | `[ServerName]` | Specify the replication database user name used by BART to establish the connection to the database server for full backups. | -| `cluster_owner` | `[ServerName]` | Specify the Linux operating system user account that owns the database cluster. | - -4. As a BART user, navigate to `/usr/edb/bart/bin` and invoke the following subcommand (omitting the `-s` option) to verify the \[BART] section parameter settings: - - ```text - bart CHECK-CONFIG - ``` - -5. Authorize [SSH/SCP access](#passwordless) between the server and the BART host without a password prompt. - -6. Create a [replication database user](#replication) for each database server that BART manages. - -7. To enable continuous WAL archiving for any database server for which BART is to perform a backup, modify the `postgresql.conf` file, setting: - - - `wal_level` to `replica` or higher (for Postgres 9.6 or later) - - `archive_mode` to `on` - - `archive_command` (if it is not set in the `bart.cfg` file) - - `max_wal_senders` to a value high enough to leave at least one session available for the backup. - - After setting the parameters, restart the database server. - -8. To start the WAL scanner, navigate to `/usr/edb/bart/bin` as a BART user and execute the following command: - - ```text - ./bart-scanner - ``` - -9. If you are using the default `archive_command`, then navigate to `/usr/edb/bart/bin` as a BART user, run the `INIT` subcommand without the `-o` option, and restart the database server: - - ```text - bart INIT [ -s { | all } ] - ``` - - Where `` is the name of the database server to be backed up. - - If you have customized the `archive_command` setting in the `bart.cfg` file, run the `INIT` subcommand with the `-o` option to override any existing Postgresql `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file, and restart the database server. - - ```text - bart INIT [ -s { | all } ] [ -o ] - ``` - -10. To verify the database server parameter settings, as a BART user navigate to `/usr/edb/bart/bin` and invoke the `CHECK-CONFIG` subcommand with the -s option: - - ```text - bart CHECK-CONFIG [ -s ] - ``` - - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide* available at the [EDB website](/bart/latest/bart_user/). - - - -**Creating a Passwordless Connection** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. You must create a passwordless connection between the BART host (SSH/SCP client) and the database server (target SSH/SCP server), as well as a passwordless connection between the database server (SSH/SCP client) and the BART host (target SSH/SCP server). - -1. Log in as the user account on the BART host that will be initiating the SSH or SCP connection and navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one with the required privileges. - -2. As a root user navigate to `/usr/edb/bart`, open the `/etc/ssh/sshd_config` file and set the `PubkeyAuthentication` parameter to `yes`. - -3. Reload the configuration file: - - ```text - service sshd reload - ``` - - If you get any SSH or SCP errors, examine the log file (`/var/log/secure`). - -4. As a BART user, use the following command to generate the public key file; you can accept the default responses: - - ```text - ssh-keygen -t rsa - ``` - - The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -5. Use `SCP` to make a temporary copy of the public key file on the target server: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -6. As a `target_user`, log into the target server using `ssh target_user@host_address` command and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges. - -7. Append the temporary client’s public key file, `tmp.pub`, to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - - If an `authorized_keys` file does not exist, create a new file, but be careful not to completely replace any existing `authorized_keys` file. - -8. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -9. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the BART host as a user, there should be no prompt for a password when you are connecting to the target database server: - - ```text - ssh target_user@database_server_address - ``` - -**Creating a Passwordless Connection Between the Database Server and the BART Host** - -If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). - -Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. - -1. On the database server, navigate into the target user account’s home directory to check for an existing `.ssh` subdirectory. If it does does not exist, create one in the user account’s home directory with the required privileges. - -2. As a database server user, generate the public key file: - - ```text - ssh-keygen -t rsa - ``` - -3. Create a temporary copy of the public key file: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -4. As a target user, log into the BART host and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges: - - ```text - ssh target_user@host_address - ``` - -5. Append the client’s temporary public key file to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - -If the `authorized_keys file` does not exist, create a new file, but do not completely replace any existing `authorized_keys` file. - -6. Ensure that only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -7. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the database server as a user, there should be no prompt for a password when you are connecting to the BART host: - - ```text - ssh bart_user@bartip_address - ``` - - - -**Creating a Replication Database User** - -1. To create a replication database user (a superuser), connect to the database server with the psql client, and invoke the following PostgreSQL command: - - ```text - CREATE ROLE WITH LOGIN SUPERUSER PASSWORD ''; - ``` - -2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. - -3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. - -4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/01_backup.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/01_backup.mdx deleted file mode 100644 index 8b8f85eb4d0..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/01_backup.mdx +++ /dev/null @@ -1,271 +0,0 @@ ---- -title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/backup.html" ---- - -Use the `BACKUP` subcommand to create a full or incremental backup. - -**Syntax for a Full Backup:** - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - -[ -z ] [ –c ] - -[ --backup-name ] - -[ --thread-count ] - -[ { --with-pg_basebackup | --no-pg_basebackup } ] -``` - -**Syntax for an Incremental Backup:** - -```text -bart BACKUP –s [-Fp] - -[ --parent { | } ] - -[ --backup-name ] - -[ --thread-count ] - -[ { --checksum-algorithm } ] -``` - -Before performing an incremental backup, you must take a full backup. For more details about incremental backup, refer to *Block-Level Incremental Backup* in the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `BACKUP` options: - -| Options | Description | -| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | Use this option to specify the database server to be backed up.
Specify `` to take a backup of the database server (as specified in the BART configuration file).
Specify `all` to take a backup of all servers. | -| `-F { p \| t }`
`--format { p \| t }` | Use this option to specify the backup file format.
Specify `p` option to take backup in plain text format and specify `t` option to take backup in tar format. If the `p` or `t` option is omitted, the default is tar format.
Use `p` option with the `BACKUP` subcommand when streaming is used as a backup method.
An incremental backup can only be taken in plain text format (`p`). | -| `-z`
`(--gzip)` | This option is applicable only for full backup and `tar` format. Use this option to enable gzip compression of tar files using the default compression level (typically 6). | -| `-c `
`--compress-level ` | This is applicable only for full backup and tar format. Use this option to specify the gzip compression level on the tar file output. `` is a digit from 1 through 9, with 9 being the best compression. | -| `--backup-name ` | Use this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
For detailed information about this parameter, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/).
If the option `--backup-name` is not specified and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to specify the number of worker threads to run in parallel to copy blocks for a backup.
For detailed information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | -| `--with-pg_basebackup` | This is applicable only for full backup. Use this option to specify the use of `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the `--with-pg_basebackup` option is specified with the `BACKUP` subcommand. | -| `--no-pg_basebackup` | This is applicable only for full backup. Use this option to specify that `pg_basebackup` is not to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. | -| `--parent { \| }` | Use this option to take an incremental backup. The parent backup is a backup taken prior to the incremental backup; it can be either a full backup or an incremental backup. `` is the backup identifier of a parent backup and `` is the user-defined alphanumeric name of a parent backup. | -| `--check` | This is applicable only for incremental backup. Use this option to verify if the required MBM files are present in the BART backup catalog before taking an incremental backup. However, an actual incremental backup is not taken when the `--check` option is specified.
The `--parent` option must be used along with the `--check` option. | -| `--checksum-algorithm` | While taking a backup, you can specify one of the following values with the `--checksum-algorithm` option:
`--checksum-algorithm=MD5` (default) to generate MD5 checksum files.
`--checksum-algorithm=SHA256` to generate SHA256 checksum files.
`--checksum-algorithm=NONE` to skip generating checksum files. | - -**Examples** - -The following code sample demonstrates using variables with the `BACKUP` subcommand: - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year MONTH = -%month DAY = %day" -``` - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year MONTH = -%month DAY = %day %%" -``` - -```text -./bart show-backups -s ppas12 -i "test backup" -``` - -The following code sample displays the result of creating a full backup in the default tar format with gzip compression when the `BACKUP` subcommand was invoked. Note that checksums are generated for the full backup and user-defined tablespaces for the tar format backup: - -```text -[edb@localhost bin]$ ./bart BACKUP -s hr -z -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1567591909098 -INFO: creating 5 harvester threads -NOTICE: all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1567591909098 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/hr/1567591909098 -BACKUP SIZE: 13.91 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: America/New_York -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 3 -Oid Name Location -16387 test1 /home/edb/tbl1 -16388 test2 /home/edb/tbl2 -16389 test3 /home/edb/tbl3 - -START WAL LOCATION: 000000010000000000000025 -STOP WAL LOCATION: 000000010000000000000026 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-09-04 06:11:49 EDT -STOP TIME: 2019-09-04 06:11:53 EDT -TOTAL DURATION: 4 sec(s) -``` - -The following code sample displays information about the directory containing the full backup: - -```text -[edb@localhost bin]$number_of_threads> -[edb@localhost bin]$ ls -l /home/edb/bkup_new/hr/ -total 8 -drwxrwxr-x. 3 edb edb 34 Aug 27 05:57 1566899819709 -drwxrwxr-x. 3 edb edb 58 Aug 27 05:57 1566899827751 -drwxrwxr-x. 3 edb edb 4096 Sep 4 06:11 1567591909098 -drwxrwxr-x. 2 edb edb 4096 Sep 4 06:11 archived_wals -[edb@localhost bin]$ -``` - -The following code sample displays information about the creation of a full backup while streaming the transaction log. Note that the `-Fp` option must be specified with the `BACKUP` subcommand when streaming is used as a backup method. - -```text -[edb@localhost bin]$ ./bart BACKUP -s ACCTG -Fp -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1566898964200 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566898964200 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/acctg/1566898964200 -BACKUP SIZE: 46.03 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000017 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:42:44 EDT -STOP TIME: 2019-08-27 05:42:46 EDT -TOTAL DURATION: 2 sec(s) -``` - -The following code sample displays the assignment of a user-defined backup name with the `--backup-name` option: - -```text -[edb@localhost bin]$ ./bart BACKUP -s acctg --backup-name acctg_%year-%month-%day -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1566899004804 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566899004804 -BACKUP NAME: acctg_2019-08-27 -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/acctg/1566899004804 -BACKUP SIZE: 46.86 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 00000001000000000000001A -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:43:24 EDT -STOP TIME: 2019-08-27 05:43:24 EDT -TOTAL DURATION: 0 sec(s) -``` - -The following code sample displays an incremental backup taken by specifying the `--parent` option. The option `-Fp` must be specified while taking an incremental backup as incremental backup can be taken only in plain text format. - -```text -[edb@localhost bin]$ ./bart BACKUP -s hr -Fp --parent hr_full_1 --backup-name -hr_incr_1 -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: checking /home/edb/bkup_new/hr/archived_wals for MBM files from 0/20000028 to -0/22000000 -INFO: new backup identifier generated 1566899827751 -INFO: creating 5 harvester threads -NOTICE: all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566899827751 -BACKUP NAME: hr_incr_1 -BACKUP PARENT: 1566899819709 -BACKUP LOCATION: /home/edb/bkup_new/hr/1566899827751 -BACKUP SIZE: 7.19 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: America/New_York -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000022 -STOP WAL LOCATION: 000000010000000000000023 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:57:07 EDT -STOP TIME: 2019-08-27 05:57:08 EDT -TOTAL DURATION: 1 sec(s) -``` - - - -The following code sample displays an incremental backup taken by specifying the `--checksum-algorithm=NONE` option to skip generating checksum files. - -First, the bart-scanner is started. - -```text -edb@localhost bin]$ -[edb@localhost bin]$ ./bart-scanner -d --checksum-algorithm=NONE -DEBUG: sockPath = /tmp/fc557c1c8853d75f1cb52a8a578f371a -INFO: process created for server 'ppas11', pid = 19012 -DEBUG: could not load XLogReaderLibrary at this time, archived_wals is empty -``` - -Then, an incremental backup is taken with the `--checksum-algorithm=NONE` option to skip generating checksum files. - -```text -[edb@localhost bin]$ ./bart backup -s ppas11 -Fp --parent 1593506709152 --checksum-algorithm=NONE -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: checking /home/edb/bkup/ppas11/archived_wals for MBM files from 1/D3000028 to 1/D9000000 -INFO: new backup identifier generated 1593507779811 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.6devel -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1593507779811 -BACKUP NAME: none -BACKUP PARENT: 1593506709152 -BACKUP LOCATION: /home/edb/bkup/ppas11/1593507779811 -BACKUP SIZE: 7.30 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 0000000100000001000000D9 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2020-06-30 05:02:59 EDT -STOP TIME: 2020-06-30 05:03:05 EDT -TOTAL DURATION: 6 sec(s) -``` - -!!! Note - To restore an incremental backup taken with the `--checksum-algorithm=NONE` option, you must specify [--disable-checksum while restoring](06_restore/#restoring_an_incremental_backup_using_disable_checksum). - -Similarly, you can specify `--checksum-algorithm=MD5` or `--checksum-algorithm=SHA256` while taking an incremental backup if you want to generate MD5 or SHAD256 checksum files. diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/02_check_config.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/02_check_config.mdx deleted file mode 100644 index 69c51d5249e..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/02_check_config.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/check_config.html" ---- - -The `CHECK-CONFIG` subcommand checks the global parameter settings as well as the database server configuration in the BART configuration file. - -The following syntax is used to check the BART configuration file global section settings. - -```text -bart CHECK-CONFIG -``` - -The following syntax is used to check the database server configuration settings. - -```text -bart CHECK-CONFIG [ –s ] -``` - -The following table describes the `CHECK-CONFIG` option: - -| Option | Description | -| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -| `-s ` `--server ` | `` is the name of the database server whose configuration parameter settings are to be checked. | - -**Example** - -The following code sample demonstrates successfully checking the BART configuration file global parameters with the `bart CHECK-CONFIG` command: - -```text -bash-4.1$ bart CHECK-CONFIG -INFO: Verifying that pg_basebackup is executable -INFO: success - -INFO: success - pg_basebackup(/usr/edb/as11/bin/pg_basebackup) returns -version 11.400000 -``` - -The following code sample demonstrates successfully checking the BART configuration file database server parameters with the `bart CHECK-CONFIG` command with the `–s` option: - -```text -[edb@localhost bin]$ ./bart check-config -s hr -INFO: Checking server hr -INFO: Verifying cluster_owner and ssh/scp connectivity -INFO: success -INFO: Verifying user, host, and replication connectivity -INFO: success -INFO: Verifying that user is a database superuser -INFO: success -INFO: Verifying that cluster_owner can read cluster data files -INFO: success -INFO: Verifying that you have permission to write to vault -INFO: success -INFO: /home/edb/bkup_new/hr -INFO: Verifying database server configuration -INFO: success -INFO: Verifying that WAL archiving is working -INFO: waiting 30 seconds for -/home/edb/bkup_new/hr/archived_wals/00000001000000000000001E -INFO: success -INFO: Verifying that bart-scanner is configured and running -INFO: success -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/03_delete.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/03_delete.mdx deleted file mode 100644 index a148c571880..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/03_delete.mdx +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/delete.html" ---- - -The `DELETE` subcommand removes the subdirectory and data files from the BART backup catalog for the specified backups along with archived WAL files. - -**Syntax:** - -```text -bart DELETE –s --i { all | [']{ | },... }['] } -[ -n ] -``` - -Note that when invoking the `DELETE` subcommand, you must specify a database server. - -For database servers under a retention policy, there are conditions where certain backups may not be deleted. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `DELETE` options: - -| Options | Description | -| -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server whose backups are to be deleted. | -| ``-i { all \| [']{ \| }',... }[`] }``

``--backupid { all \| [']{ \| }',... }[`] }`` | `` is the backup identifier of the backup to be deleted. `` is the user-defined alphanumeric name for the backup.
Multiple backup identifiers and backup names may be specified in a comma-separated list. The list must be enclosed within single quotes if there is any white space appearing before or after each comma (see [Example](#deleting_multiple_backups_with_space_characters)).
If `all` is specified, all backups and their archived WAL files for the specified database server are deleted. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to physically removing files; no files are actually deleted. | - -**Example** - -The following code sample demonstrates deleting a backup from the specified database server: - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i acctg_2019-08-27 -INFO: deleting backup 'acctg_2019-08-27' of server 'acctg' -INFO: deleting backup '1566900093665' -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -'/home/edb/bkup_new/acctg/archived_wals/000000010000000000000025' -is required, yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -``` - -After the deletion, the BART backup catalog for the database server no longer contains the corresponding directory for the deleted `backup ID`. The following code sample displays information about `archived_wals` subdirectory that no longer contains the backup WAL files: - -```text -[edb@localhost acctg]$ ls -l -total 16 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900199604 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900204377 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900209087 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:05 1566900321228 -drwxrwxr-x. 2 edb edb 6 Aug 27 06:01 archived_wals -``` - -The following code sample demonstrates deleting multiple backups from the database server. - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i `1566988095633,1566988100760, -acctg_2019-08-28` -INFO: deleting backup `1566988095633` of server `acctg` -INFO: deleting backup `1566988095633` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000037` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566988100760` of server `acctg` -INFO: deleting backup `1566988100760` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000039` is -required, yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `acctg_2019-08-28` of server `acctg` -INFO: deleting backup `1566988115512` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000003C` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost acctg]$ -[edb@localhost acctg]$ ls -l -total 8 -drwxrwxr-x. 3 edb edb 4096 Aug 28 06:28 1566988105086 -drwxrwxr-x. 3 edb edb 4096 Aug 28 06:28 1566988109477 -drwxrwxr-x. 2 edb edb 6 Aug 28 06:09 archived_wals -[edb@localhost acctg]$ -``` - - - -**Deleting Multiple Backups with Space Characters** - -The following code sample demonstrates deleting multiple backups; since there are space characters in the comma-separated list, the entire list must be enclosed within single quotes: - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i -`1566900199604,1566900204377,1566900209087`; -INFO: deleting backup `1566900199604` of server `acctg` -INFO: deleting backup `1566900199604` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000028` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566900204377` of server `acctg` -INFO: deleting backup `1566900204377` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000002A` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566900209087` of server `acctg` -INFO: deleting backup `1566900209087` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000002C` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost acctg]$ ls -l -total 4 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:05 1566900321228 -drwxrwxr-x. 2 edb edb 6 Aug 27 06:01 archived_wals -[edb@localhost acctg]$ -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/04_init.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/04_init.mdx deleted file mode 100644 index 9f8b020ac03..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/04_init.mdx +++ /dev/null @@ -1,276 +0,0 @@ ---- -title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/init.html" ---- - - - -The `INIT` subcommand is used to create the BART backup catalog directory, rebuild the BART `backupinfo` file, and set the `archive_command` in the server based on the `archive_command` setting in the `bart.cfg` file. - -**Syntax:** - -```text -bart INIT [ –s { | all } ] [ -o ] - -[ -r [ -i { | | all } ] ] - -[--no-configure] -``` - -The following table describes the `INIT` options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server to which the `INIT` actions are to be applied. If `all` is specified or if the option is omitted, actions are applied to all servers. | -| `-o`
`--override` | Overrides the existing Postgres `archive_command` configuration parameter setting in the `postgresql.conf` file or the `postgresql.auto.conf` file using the BART `archive_command` parameter in the BART configuration file. The `INIT` generated `archive command` string is written to the `postgresql.auto.conf` file. | -| `-r`
`--rebuild` | Rebuilds the `backupinfo` file located in each backup subdirectory. If `all` is specified or if the option is omitted, the `backupinfo` files of all backups for the database servers specified by the `-s` option are recreated. This option is only intended for recovering from a situation where the backupinfo file has become corrupt.
If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild that `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. | -| `-i { \| \| all }`
`--backupid { \| \| all }` | `` is an integer, backup identifier and `` is the user-defined alphanumeric name for the backup. The `-i` option can only be used with the `-r` option. | -| `--no-configure` | Prevents the `archive_command` from being set in the PostgreSQL server. | - -**Examples** - -In the following code sample, you can see that `archive_mode = off` and `archive_command` is not set. After invoking the BART `INIT` subcommand, `archive_mode` is set to `on` and `archive_command` is set: - -```text -archive_mode = off # enables archiving; off, on, or always -# (change requires restart) -archive_command = '' -# command to use to archive a logfile segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_mode/archive_command is set. Restart the PostgreSQL -server using 'pg_ctl restart' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_mode = 'on' -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample, you can see that `archive_mode = on`, and `archive_command` is not set. After invoking the `INIT` subcommand, `archive_command` is set: - -```text -archive_mode = on # enables archiving; off, on, or always -# (change requires restart) -archive_command = '' # command to use to archive a logfile segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_command is set. Reload the configuration in the -PostgreSQL server using pg_reload_conf() or 'pg_ctl reload' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample, you can see that `archive_mode = on` and `archive_command` are already set. After invoking the `INIT` subcommand, there is no change in their settings. Note that to override the existing `archive_command`, you must include the `-o` option. - -```text -archive_mode = on # enables archiving; off, on, or always -# (change requires restart) -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' # command to use -to archive a logfile segment -# placeholders: %p = path of file to archive -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_command is not set for server 'ppas11' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -``` - -In the following code sample, you can see that `archive_mode = off` and `archive_command` is already set. After invoking the `INIT` subcommand `archive_mode` is set to `on`: - -```text -archive_mode = off # enables archiving; off, on, or always -# (change requires restart) -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' # command to use -to archive a log file segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_mode/archive_command is set. Restart the PostgreSQL -server using 'pg_ctl restart' -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_mode = 'on' -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample an existing `archive command` setting is overridden by resetting the `archive_command` in the PostgreSQL server with the `archive_command = 'cp %p %a/%f'` parameter from the `bart.cfg` file: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup_edb -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -The `archive_mode` and `archive_command` parameters in the database server are set as follows: - -```text -edb=# SHOW archive_mode; -archive_mode --------------- -on -(1 row) -edb=# SHOW archive_command; -archive_command ------------------------------------------------------------------- -scp %p bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f - -(1 row) -``` - -Invoke the `INIT` subcommand with the `-o` option to override the current `archive_command` setting in the PostgreSQL server: - -```text --bash-4.1$ bart INIT -s acctg -o -INFO: setting archive_mode/archive_command for server 'acctg' -WARNING: archive_command is set. Reload the configuration in the -PostgreSQL server using pg_reload_conf() or 'pg_ctl reload' -``` - -Reload the database server configuration; a restart of the database server is not necessary to reset only the `archive_command` parameter: - -```text -[root@localhost tmp]# service ppas11 reload -``` - -The `archive_command` in the PostgreSQL server is now set as follows: - -```text -edb=# SHOW archive_command; - archive_command ------------------------------------------------ -cp %p /opt/backup_edb/acctg/archived_wals/%f -(1 row) -``` - -The new command string is written to the `postgresql.auto.conf` file: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup_edb/acctg/archived_wals/%f' -``` - -When you invoke the BART `INIT` command with the `-r` option, BART rebuilds the `backupinfo` file using the content of the backup directory for the server specified or for all servers. The BART `backupinfo` file is initially created by the `BACKUP` subcommand and contains the backup information used by BART. - -!!! Note - If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild the `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. - -The following code sample shows the `backupinfo` file location in a backup subdirectory: - -```text -[root@localhost acctg]# pwd -/opt/backup/acctg -[root@localhost acctg]# ls -l -total 4 -drwx------ 2 enterprisedb enterprisedb 38 Oct 26 10:21 1477491569966 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Oct 26 10:19 archived_wals -[root@localhost acctg]# ls -l 1477491569966 -total 61144 --rw-rw-r-- 1 enterprisedb enterprisedb 703 Oct 26 10:19 backupinfo --rw-rw-r-- 1 enterprisedb enterprisedb 62603776 Oct 26 10:19 base.tar -``` - -The following code sample displays the `backupinfo` file content: - -```text -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1477491569966 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1477491569966 -BACKUP SIZE: 59.70 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -84b3eeb1e3f7b3e75c2f689570d04f10 base.tar -TABLESPACE(s): 0 -START WAL LOCATION: 2/A5000028 (file 0000000100000002000000A5) -STOP WAL LOCATION: 2/A50000C0 (file 0000000100000002000000A5) -CHECKPOINT LOCATION: 2/A5000028 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2016-10-26 10:19:30 EDT -LABEL: pg_basebackup base backup -STOP TIME: 2016-10-26 10:19:30 EDT -TOTAL DURATION: 0 sec(s) -``` - -The following code sample displays an error message if the `backupinfo` file is missing when invoking a BART subcommand: - -```text --bash-4.2$ bart SHOW-BACKUPS -ERROR: 'backupinfo' file does not exist for backup '1477491569966' -please use 'INIT -r' to generate the file -``` - -The `backupinfo` file may be missing if the `BACKUP` subcommand did not complete successfully. - -The following code sample displays information about rebuilding the `backupinfo` file of the specified backup for database server `acctg`: - -```text --bash-4.1$ bart INIT -s acctg -r -i 1428346620427 -INFO: rebuilding BACKUPINFO for backup '1428346620427' of server 'acctg' -INFO: backup checksum: ced59b72a7846ff8fb8afb6922c70649 of base.tar -``` - -The following code sample displays information about how the `backupinfo` files of all backups are rebuilt for all database servers: - -```text --bash-4.1$ bart INIT -r - -INFO: rebuilding BACKUPINFO for backup '1428347191544' of server 'acctg' -INFO: backup checksum: 1ac5c61f055c910db314783212f2544f of base.tar -INFO: rebuilding BACKUPINFO for backup '1428346620427' of server 'acctg' -INFO: backup checksum: ced59b72a7846ff8fb8afb6922c70649 of base.tar -INFO: rebuilding BACKUPINFO for backup '1428347198335' of server 'dev' -INFO: backup checksum: a8890dd8ab7e6be5d5bc0f38028a237b of base.tar -INFO: rebuilding BACKUPINFO for backup '1428346957515' of server 'dev' -INFO: backup checksum: ea62549cf090573625d4adeb7d919700 of base.tar -``` - -The following code sample displays information about invoking `BART INIT` with the `-r - i` option: - -```text -edb@localhost bin]$ ./bart init -s ppas11 -i 1551778898392 -r -INFO: rebuilding BACKUPINFO for backup '1551778898392' of server -'ppas11' -[edb@localhost bin]$ ls /home/edb/bkup/ppas11/1551778898392/ -backupinfo backup_label base base-1.tar base-2.tar base-3.tar -base-4.tar base-5.tar base.tar -``` - -The following code sample displays information about invoking the `BART INIT` command with the `--no-configure` option. You can use the `--no-configure` option with the `INIT` subcommand to prevent the `archive_command` option from being set in the PostgreSQL server. - -```text -[edb@localhost bin]$ ./bart init -s ppas11 -o --no-configure -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/05_manage.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/05_manage.mdx deleted file mode 100644 index 75e63130a8e..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/05_manage.mdx +++ /dev/null @@ -1,228 +0,0 @@ ---- -title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/manage.html" ---- - -The `MANAGE` subcommand can be invoked to: - -- Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file. -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file. - -**Syntax:** - -```text -bart MANAGE [ –s { | all} ] -[ -l ] [ -d ] -[ -c { keep | nokeep } --i { | | all } ] -[ -n ] -``` - -To view detailed information about the `MANAGE` subcommand and retention policy management, see *the EDB Backup and Recovery User Guide*. For information about setting the `wal_compression` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide*. These guides are available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `MANAGE` options: - -| Options | Description | -| ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `-s [ \| all ]`
`--server [ \| all ]` | `` is the name of the database server to which the `MANAGE` actions are to be applied.
If `all` is specified or if the `-s` option is omitted, actions are applied to all database servers. | -| `-l`
`--list-obsolete` | Lists the backups marked as obsolete. | -| `-d`
`--delete-obsolete` | Deletes the backups marked as obsolete. This action physically deletes the backup along with its archived WAL files and any MBM files for incremental backups. | -| `-c { keep \| nokeep }`
`--change-status { keep \| nokeep }` | Specify `keep` to change the backup status to `keep` to retain the backup indefinitely.

Specify `nokeep` to change the backup status back to `active`. You can then re-evaluate and possibly mark the backup as `obsolete` (according to the retention policy) using the `MANAGE` subcommand.

The `-c` option can only be used with the `-i` option. | -| `-i { \| \| all` }

`--backupid { \| \| all` } | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified, actions are applied to all backups.
The `-i` option can only be used with the `-c` option. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to actually implementing the actions as if the operation was performed, however, no changes are actually made.
If you specify `-n` with the `-d` option, it displays which backups would be deleted, but does not actually delete the backups.
If you specify `-n` with the `-c` option, it displays the keep or nokeep action, but does not actually change the backup status.
If you specify `-n` alone with no other options or if you specify `-n` with only the `-s` option, it displays which active backups would be marked as obsolete, but does not actually change the backup status. In addition, no compression is performed on uncompressed, archived WAL files even if WAL compression is enabled for the database server. | - -**Example** - -The following code sample performs a dry run for the specified database server displaying which active backups are evaluated as obsolete according to the retention policy, but does not actually change the backup status: - -```text --bash-4.2$ bart MANAGE -s acctg -n -INFO: processing server 'acctg', backup '1482770807519' -INFO: processing server 'acctg', backup '1482770803000' -INFO: marking backup '1482770803000' as obsolete -INFO: 1 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1482770735155' -INFO: marking backup '1482770735155' as obsolete -INFO: 2 incremental(s) of backup '1482770735155' will be marked obsolete -INFO: marking incremental backup '1482770780423' as obsolete -INFO: marking incremental backup '1482770763227' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample marks active backups as obsolete according to the retention policy for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1482770807519' -INFO: processing server 'acctg', backup '1482770803000' -INFO: marking backup '1482770803000' as obsolete -INFO: 1 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1482770735155' -INFO: marking backup '1482770735155' as obsolete -INFO: 2 incremental(s) of backup '1482770735155' will be marked obsolete -INFO: marking incremental backup '1482770780423' as obsolete -INFO: marking incremental backup '1482770763227' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample lists backups marked as obsolete for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -l -SERVER NAME: acctg -BACKUP ID: 1482770803000 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:46:43 EST -BACKUP SIZE: 59.52 MB -WAL FILE(s): 1 -WAL FILE: 000000010000000100000055 -SERVER NAME: acctg -BACKUP ID: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -INCREMENTAL BACKUP(s): 2 -BACKUP ID: 1482770780423 -BACKUP PARENT: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -BACKUP ID: 1482770763227 -BACKUP PARENT: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -WAL FILE(s): 3 -WAL FILE: 000000010000000100000054 -WAL FILE: 000000010000000100000053 -WAL FILE: 000000010000000100000052 -UNUSED FILE(s): 2 -UNUSED FILE: 000000010000000100000051 -UNUSED FILE: 0000000100000001510000280000000152000000.mbm -``` - -The following code sample deletes the obsolete backups for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1482770803000' -INFO: 1 WAL file(s) will be removed -INFO: removing WAL file '000000010000000100000055' -INFO: removing obsolete backup '1482770735155' -INFO: 3 WAL file(s) will be removed -INFO: 2 incremental(s) of backup '1482770735155' will be removed -INFO: removing obsolete incremental backup '1482770780423' -INFO: removing obsolete incremental backup '1482770763227' -INFO: removing WAL file '000000010000000100000054' -INFO: removing WAL file '000000010000000100000053' -INFO: removing WAL file '000000010000000100000052' -INFO: 8 Unused file(s) will be removed -INFO: removing (unused) file '000000010000000100000056.00000028.backup' -INFO: removing (unused) file '000000010000000100000056' -INFO: removing (unused) file '000000010000000100000055.00000028.backup' -INFO: removing (unused) file '000000010000000100000054.00000028.backup' -INFO: removing (unused) file '000000010000000100000053.00000028.backup' -INFO: removing (unused) file '000000010000000100000052.00000028.backup' -INFO: removing (unused) file '000000010000000100000051' -INFO: removing (unused) file -'0000000100000001510000280000000152000000.mbm' -``` - -The following code sample changes the specified backup to keep status to retain it indefinitely: - -```text --bash-4.2$ bart MANAGE -s acctg -c keep -i 1482770807519 -INFO: changing status of backup '1482770807519' of server 'acctg' from -'active' to 'keep' -INFO: 1 WAL file(s) changed --bash-4.2$ bart SHOW-BACKUPS -s acctg -i 1482770807519 -t -SERVER NAME : acctg -BACKUP ID : 1482770807519 -BACKUP NAME : none -BACKUP PARENT : none -BACKUP STATUS : keep -BACKUP TIME : 2016-12-26 11:46:47 EST -BACKUP SIZE : 59.52 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -LAST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -``` - -The following code sample resets the specified backup to active status: - -```text --bash-4.2$ bart MANAGE -s acctg -c nokeep -i 1482770807519 -INFO: changing status of backup '1482770807519' of server 'acctg' from -'keep' to 'active' -INFO: 1 WAL file(s) changed --bash-4.2$ bart SHOW-BACKUPS -s acctg -i 1482770807519 -t -SERVER NAME : acctg -BACKUP ID : 1482770807519 -BACKUP NAME : none -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-12-26 11:46:47 EST -BACKUP SIZE : 59.52 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -LAST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -``` - -The following code sample uses the enabled `wal_compression` parameter in the BART configuration file as shown by the following: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -allow_incremental_backups = disabled -wal_compression = enabled -description = "Accounting" -``` - -When the `MANAGE` subcommand is invoked, the following message is displayed indicating that WAL file compression is performed: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: 4 WAL file(s) compressed -WARNING: 'retention_policy' is not set for server 'acctg' -``` - -The following code sample shows the archived WAL files in compressed format: - -```text --bash-4.2$ pwd -/opt/backup/acctg --bash-4.2$ ls -l archived_wals -total 160 --rw------- 1 enterprisedb enterprisedb 27089 Dec 26 12:16 -00000001000000010000005B.gz --rw------- 1 enterprisedb enterprisedb 305 Dec 26 12:17 -00000001000000010000005C.00000028.backup --rw------- 1 enterprisedb enterprisedb 27112 Dec 26 12:17 -00000001000000010000005C.gz --rw------- 1 enterprisedb enterprisedb 65995 Dec 26 12:18 -00000001000000010000005D.gz --rw------- 1 enterprisedb enterprisedb 305 Dec 26 12:18 -00000001000000010000005E.00000028.backup --rw------- 1 enterprisedb enterprisedb 27117 Dec 26 12:18 -00000001000000010000005E.gz -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/06_restore.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/06_restore.mdx deleted file mode 100644 index 52490745796..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/06_restore.mdx +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/restore.html" ---- - -The `RESTORE` subcommand restores a backup and its archived WAL files for the designated database server to the specified directory location. - -**Syntax for Restore**: - -```text -bart RESTORE –s -p -[ –i { | } ] -[ -r @ ] -[ -w ] -[ -t ] -[ { -x | -g } ] -[ -c ] -[ --disable-checksum ] -``` - -To view detailed information about the `RESTORE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -If the backup is restored to a different database cluster directory than where the original database cluster resided, then some operations dependent upon the database cluster location may fail. This happens if the supporting service scripts are not updated to reflect the new directory location of restored backup. - -For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). - -The following table describes the `RESTORE` options: - -| Options | Description | -| --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server to be restored. | -| `-p --restore-path `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | -| `-i { \| }`

`--backupid { \| }` | `backup_id` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the latest backup is restored by default. | -| `-r `

`--remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored.
`` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `remote_host` parameter for this database server is not set in the BART configuration file.
For information about the `remote_host` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). | -| `-w `
`--workers ` | `` is the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location. If the `-w` option is omitted, the default is `1` worker process.
For example, if four worker processes are specified, four receiver processes on the restore host and four streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process.
When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. | -| `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | -| `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. | -| `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. | -| `-c`

`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
The `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, then the `restore_command` in the `postgresql.conf` retrieves the archived WAL files directly from the BART backup catalog.
For information about the `copy_wals_during_restore` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | -| `--disable-checksum` | While restoring a backup, specify this option to skip verifying the MD5 or SHA256 checksum files.
If you set the `--checksum-algorithm=NONE` option with the BART scanner or while taking a backup, you also need to specify the `--disable checksum` option while restoring an incremental backup. | - -**Examples** - -The following code sample restores a database server(named `mktg`) to the `/opt/restore` directory up to timestamp `2015-12-15 10:47:00`: - -```text --bash-4.1$ bart RESTORE -s mktg -i 1450194208824 -p /opt/restore -t 1 -g -'2015-12-15 10:47:00' -INFO: restoring backup '1450194208824' of server 'mktg' -INFO: restoring backup to enterprisedb@192.168.2.24:/opt/restore -INFO: base backup restored -INFO: WAL file(s) will be streamed from the BART host -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: tablespace(s) restored -``` - -The following parameters are set in the `postgresql.auto.conf` file: - -```text -restore_command = 'scp -o BatchMode=yes -o PasswordAuthentication=no -enterprisedb@192.168.2.22:/opt/backup/mktg/archived_wals/%f %p' -recovery_target_time = '2015-12-15 10:47:00' -recovery_target_timeline = 1 -``` - -The following is a list of the restored files and subdirectories: - -```text -[root@localhost restore]# pwd -/opt/restore -[root@localhost restore]# ls -l -total 108 --rw------- 1 enterprisedb enterprisedb 208 Dec 15 10:43 backup_label -drwx------ 6 enterprisedb enterprisedb 4096 Dec 2 10:38 base -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 dbms_pipe -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 global -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_clog\ --rw------- 1 enterprisedb enterprisedb 4438 Dec 2 10:38 pg_hba.conf --rw------- 1 enterprisedb enterprisedb 1636 Nov 10 15:38 pg_ident.conf -drwxr-xr-x 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_log -drwx------ 4 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_multixact -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_notify -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_serial -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_snapshots -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_stat -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:43 pg_stat_tmp -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_subtrans -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 pg_tblspc -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_twophase --rw------- 1 enterprisedb enterprisedb 4 Nov 10 15:38 PG_VERSION -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 pg_xlog --rw------- 1 enterprisedb enterprisedb 23906 Dec 15 11:00 -postgresql.conf --rw-r--r-- 1 enterprisedb enterprisedb 217 Dec 15 11:00 -postgresql.auto.conf -``` - -**Example** - -The following code sample performs a `RESTORE` operation with the `copy_wals_during_restore` parameter enabled to copy the archived WAL files to the local `/archived_wals` directory: - -```text --bash-4.1$ bart RESTORE -s hr -i hr_2017-03-29T13:50 -p -/opt/restore_pg96 -t 1 -g '2017-03-29 14:01:00' -INFO: restoring backup 'hr_2017-03-29T13:50' of server 'hr' -INFO: base backup restored -INFO: copying WAL file(s) to -postgres@192.168.2.24:/opt/restore_pg96/archived_wals -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: restore completed successfully -``` - -The following parameters are set in the `postgresql.auto.conf` file: - -```text -restore_command = 'cp archived_wals/%f %p' -recovery_target_time = '2017-03-29 14:01:00' -recovery_target_timeline = 1 -``` - -The following is a list of the restored files and subdirectories: - -```text --bash-4.1$ pwd -/opt/restore_pg96 --bash-4.1$ ls -l -total 128 -drwxr-xr-x 2 postgres postgres 4096 Mar 29 14:27 archived_wals --rw------- 1 postgres postgres 206 Mar 29 13:50 backup_label -drwx------ 5 postgres postgres 4096 Mar 29 12:25 base -drwx------ 2 postgres postgres 4096 Mar 29 14:27 global -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_clog -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_commit_ts -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_dynshmem --rw------- 1 postgres postgres 4212 Mar 29 13:18 pg_hba.conf --rw------- 1 postgres postgres 1636 Mar 29 12:25 pg_ident.conf -drwxr-xr-x 2 postgres postgres 4096 Mar 29 13:45 pg_log -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_logical -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_multixact -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_notify -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_replslot -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_serial -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_snapshots -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_stat -drwx------ 2 postgres postgres 4096 Mar 29 13:50 pg_stat_tmp -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_subtrans -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_tblspc -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_twophase --rw------- 1 postgres postgres 4 Mar 29 12:25 PG_VERSION -drwx------ 3 postgres postgres 4096 Mar 29 14:27 pg_xlog --rw------- 1 postgres postgres 169 Mar 29 13:24 postgresql.auto.conf --rw-r--r-- 1 postgres postgres 21458 Mar 29 14:27 postgresql.conf --rw-r--r-- 1 postgres postgres 118 Mar 29 14:27 postgresql.auto.conf -``` - - - -The following code sample displays restoring an [incremental backup](01_backup/#incremental_backup_using_checksum_algorithm) taken using `--checksum-algorithm=NONE` option. To restore this incremental backup, you must specify the `--disable-checksum` option to skip verifying MD5 or SHA256 checksum files. - -```text -[edb@localhost bin]$ ./bart restore -s ppas11 -i 1593507779811 -p /home/edb/RESTORE/ --disable-checksum -INFO: restoring incremental backup '1593507779811' of server 'ppas11' -INFO: base backup restored -INFO: writing recovery.conf file -INFO: WAL file(s) will be streamed from the BART host -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: incremental restore completed successfully -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx deleted file mode 100644 index 8ada69b5622..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_servers.html" ---- - -The `SHOW-SERVERS` subcommand displays information for the managed database servers listed in the BART configuration file. - -**Syntax:** - -```text -bart SHOW-SERVERS [ –s { | all } ] -``` - -The following table describes the `SHOW-SERVERS` option: - -| Option | Description | -| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all` }
`--server { \| all` } | `` is the name of the database server to which the `SHOW-SERVERS` actions are to be applied.
If `all` is specified or if the `-s` option is omitted, the actions are applied to all database servers. | - -**Example** - -The following code sample shows all the database servers managed by BART as returned by the `SHOW-SERVERS` subcommand: - -```text --bash-4.2$ bart SHOW-SERVERS -SERVER NAME : acctg -BACKUP FRIENDLY NAME: acctg_%year-%month-%dayT%hour:%minute -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -SERVER NAME : hr -BACKUP FRIENDLY NAME: hr_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : postgres@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Human Resources" -SERVER NAME : mktg -BACKUP FRIENDLY NAME: mktg_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : enterprisedb@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/mktg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED\ -DESCRIPTION : "Marketing" -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx deleted file mode 100644 index 03b7727add3..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_backups.html" ---- - -The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. - -**Syntax:** - -```text -bart SHOW-BACKUPS [ –s { | all } ] -[ -i { | | all } ] -[ -t ] -``` - -The following table describes the `SHOW-BACKUPS` options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all` }

`--server { \| all` } | `` is the name of the database server whose backup information is to be displayed.
If `all` is specified or if the option is omitted, the backup information for all database servers is displayed. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified or if the option is omitted, all backup information for the relevant database server is displayed. | -| `-t`
`--toggle` | Displays detailed backup information in list format. If the option is omitted, the default is a tabular format. | - -**Example** - -The following code sample shows the backup from database server `dev`: - -```text --bash-4.2$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -dev 1477579596637 dev_2016-10-27T10:46:36 none -2016-10-27 10:46:37 EDT 54.50 MB 96.00 MB 6 active -``` - -The following code sample shows detailed information using the `-t` option: - -```text --bash-4.2$ bart SHOW-BACKUPS -s dev -i 1477579596637 -t -SERVER NAME : dev -BACKUP ID : 1477579596637 -BACKUP NAME : dev_2016-10-27T10:46:36 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:46:37 EDT -BACKUP SIZE : 54.50 MB -WAL(S) SIZE : 80.00 MB -NO. OF WALS : 5 -FIRST WAL FILE : 0000000100000001000000EC -CREATION TIME : 2016-10-27 10:46:37 EDT -LAST WAL FILE : 0000000100000001000000F0 -CREATION TIME : 2016-10-27 11:22:01 EDT -``` - -The following code sample shows a listing of an incremental backup along with its parent backup: - -```text --bash-4.2$ bart SHOW-BACKUPS -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -acctg 1477580293193 acctg_2016-10-27 none -2016-10-27 10:58:13 EDT 16.45 MB 16.00 MB 1 active -acctg 1477580111358 acctg_2016-10-27 none 2016-10-27 10:55:11 EDT 59.71 -MB 16.00 MB 1 active -``` - -The following code sample shows the complete, detailed information of the incremental backup and the parent backup: - -```text --bash-4.2$ bart SHOW-BACKUPS -t -SERVER NAME : acctg -BACKUP ID : 1477580293193 -BACKUP NAME : none -BACKUP PARENT : acctg_2016-10-27 -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:58:13 EDT -BACKUP SIZE : 16.45 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 0000000100000002000000D9 -CREATION TIME : 2016-10-27 10:58:13 EDT -LAST WAL FILE : 0000000100000002000000D9 -CREATION TIME : 2016-10-27 10:58:13 EDT -SERVER NAME : acctg -BACKUP ID : 1477580111358 -BACKUP NAME : acctg_2016-10-27 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:55:11 EDT -BACKUP SIZE : 59.71 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 0000000100000002000000D8 -CREATION TIME : 2016-10-27 10:55:12 EDT -LAST WAL FILE : 0000000100000002000000D8 -CREATION TIME : 2016-10-27 10:55:12 EDT -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx deleted file mode 100644 index 973ae05dc7d..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/verify_chksum.html" ---- - -The `VERIFY-CHKSUM` subcommand verifies the MD5 checksums of the full backups and any user-defined tablespaces for the specified database server or for all database servers. The checksum is verified by comparing the current checksum of the backup against the checksum when the backup was taken. - -!!! Note - The `VERIFY-CHKSUM` subcommand is only used for tar format backups. - -**Syntax:** - -```text -bart VERIFY-CHKSUM -[ –s { | all } ] -[ -i { | | all } ] -``` - -The following table describes the `VERIFY-CHKSUM` options: - -| Options | Description | -| ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all` } | `` is the name of the database server whose tar backup checksums are to be verified.
If `all` is specified or if the `-s` option is omitted, the checksums of all tar backups are verified for all database servers. | -| `-i { \| \| all` }

`--backupid { \| \| all` } | `` is the backup identifier of a tar format full backup whose checksum is to be verified along with any user-defined tablespaces. `` is the user-defined alphanumeric name for the full backup.
If `all` is specified or if the `-i` option is omitted, the checksums of all tar backups for the relevant database server are verified. | - -**Example** - -The following code sample verifies the checksum of all tar format backups of the specified database server: - -```text --bash-4.1$ bart VERIFY-CHKSUM -s acctg -i all -SERVER NAME BACKUP ID VERIFY -acctg 1430239348243 OK -acctg 1430232284202 OK -acctg 1430232016284 OK -acctg 1430231949065 OK -acctg 1429821844271 OK -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx deleted file mode 100644 index 12305fb7733..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx +++ /dev/null @@ -1,168 +0,0 @@ ---- -title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/running_the_bart_wal_scanner.html" ---- - -The BART WAL scanner is used to process each WAL file to find and record modified blocks in a corresponding MBM file. As a BART account user, use the BART WAL scanner to invoke the `bart-scanner` program located in the `/bin` directory. - -For detailed information about the WAL scanner and its usage, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -**Syntax:** - -```text -bart-scanner -[ -d ] -[ -c ] -{ –h | --v | ---daemon | --p | - | -RELOAD | -STOP ---checksum-algorithm } -``` - -When the `bart-scanner` program is invoked, it forks a separate process for each database server enabled with the `allow_incremental_backups` parameter. - -The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option: - -- If the `--daemon` option is specified, the WAL scanner process runs in the background. All output messages can be viewed in the BART log file. -- If the `--daemon` option is omitted, the WAL scanner process runs in the foreground. All output messages can be viewed from the terminal running the program as well as in the BART log file. - -The following table describes the `VERIFY-CHKSUM` options. - -| Options | Description | -| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on WAL scanner usage. | -| `-v` `--version` | Displays the WAL scanner version information. | -| `-d` `--debug` | Displays debugging output while executing the WAL scanner with any of its options. | -| `-c ` `--config-path ` | Specifies `` as the full directory path to a BART configuration file. Use this option if you do not want to use the default BART configuration file `/etc/bart.cfg` | -| `--daemon` | Runs the WAL scanner as a background process. | -| `-p ` `--print ` | Specifies the full directory path to an MBM file whose content is to be printed. The `archived_wals` directory as specified in the the `archive_path` parameter in the `bart.cfg` file contains the MBM files. | -| `` | Specifies the full directory path to a WAL file to be scanned. The archive path directory contains the WAL files. Use it if a WAL file in the archive path is missing its MBM file. This option is to be used for assisting the EnterpriseDB support team for debugging problems that may have been encountered. | -| `RELOAD` | Reloads the BART configuration file. The keyword `RELOAD` is case-insensitive. The `RELOAD` option is useful if you make changes to the configuration file after the WAL scanner has been started. It will reload the configuration file and adjust the WAL scanners accordingly. For example, if a server section allowing incremental backups is removed from the BART configuration file, then the process attached to that server will stop. Similarly, if a server allowing incremental backups is added, a new WAL scanner process will be launched to scan the WAL files of that server. | -| `STOP` | Stops the WAL scanner. The keyword `STOP` is not case-sensitive. | -| `--checksum-algorithm` | While invoking the WAL scanner, you can specify one of the following values with the `--checksum-algorithm` option: `--checksum-algorithm=MD5` (default) to generate MD5 checksum files. `--checksum-algorithm=SHA256` to generate SHA256 checksum files. `--checksum-algorithm=NONE` to skip generating checksum files. | - -**Example** - -The following code sample demonstrates starting the WAL scanner to run interactively. The WAL scanner begins scanning existing WAL files in the archive path that have not yet been scanned (that is, there is no corresponding MBM file for the WAL file): - -```text --bash-4.2$ bart-scanner -INFO: process created for server 'acctg', pid = 5287 -INFO: going to parse backlog of WALs, if any. -INFO: WAL file to be processed: 0000000100000000000000ED -INFO: WAL file to be processed: 0000000100000000000000EE -INFO: WAL file to be processed: 0000000100000000000000EF -INFO: WAL file to be processed: 0000000100000000000000F0 -INFO: WAL file to be processed: 0000000100000000000000F1 -``` - -The following code sample is the content of the archive path showing the MBM files created for the WAL files. (The user name and group name of the files have been removed from the example to list the WAL files and MBM files in a more readable manner): - -```text -[root@localhost archived_wals]# pwd -/opt/backup/acctg/archived_wals -[root@localhost archived_wals]# ls -l -total 81944 --rw------- 1 ... ... 16777216 Dec 20 09:10 0000000100000000000000ED --rw------- 1 ... ... 16777216 Dec 20 09:06 0000000100000000000000EE --rw------- 1 ... ... 16777216 Dec 20 09:11 0000000100000000000000EF --rw------- 1 ... ... 16777216 Dec 20 09:15 0000000100000000000000F0 --rw------- 1 ... ... 16777216 Dec 20 09:16 0000000100000000000000F1 --rw------- 1 ... ... 305 Dec 20 09:16 0000000100000000000000F1.00000028.backup --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000ED00002800000000EE000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000EE00002800000000EF000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000EF00002800000000F0000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000F000002800000000F1000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000F100002800000000F2000000.mbm -``` - -To stop the interactively running WAL scanner, either enter `ctrl-C` at the terminal running the WAL scanner or invoke the `bart-scanner` program from another terminal with the `STOP` option: - -```text --bash-4.2$ bart-scanner STOP --bash-4.2$ -``` - -The terminal on which the WAL scanner was running interactively appears as follows after it has been stopped: - -```text --bash-4.2$ bart-scanner -INFO: process created for server 'acctg', pid = 5287 -INFO: going to parse backlog of WALs, if any. -INFO: WAL file to be processed: 0000000100000000000000ED -INFO: WAL file to be processed: 0000000100000000000000EE -INFO: WAL file to be processed: 0000000100000000000000EF -INFO: WAL file to be processed: 0000000100000000000000F0 -INFO: WAL file to be processed: 0000000100000000000000F1 -INFO: bart-scanner stopped --bash-4.2$ -``` - -The following code sample demonstrates invoking the WAL scanner to run as a background process with the `--daemon` option: - -```text --bash-4.2$ bart-scanner --daemon --bash-4.2$ -``` - -The WAL scanner runs as a background process. There is also a separate background process for each database server that has been enabled for WAL scanning with the `allow_incremental_backups` parameter in the BART configuration file: - -```text --bash-4.2$ ps -ef | grep bart - enterpr+ 4340 1 0 09:48 ? 00:00:00 bart-scanner --daemon - enterpr+ 4341 4340 0 09:48 ? 00:00:00 bart-scanner --daemon - enterpr+ 4415 3673 0 09:50 pts/0 00:00:00 grep --color=auto bart -``` - -To stop the WAL scanner processes, invoke the WAL scanner with the `STOP` option: - -```text --bash-4.2$ bart-scanner STOP --bash-4.2$ -``` - -The following command demonstrates scanning an individual WAL file: - -```text --bash-4.2$ bart-scanner /opt/backup/acctg/archived_wals/0000000100000000000000FF --bash-4.2$ -``` - -To print the content of an MBM file for assisting the EnterpriseDB support team for debugging problems that may have been encountered, use the `-p` option to specify the file as shown in the following code sample: - -```text --bash-4.2$ bart-scanner -p -/opt/backup/acctg/archived_wals/0000000100000000FF0000280000000100000000.mbm - -Header: -Version: 1.0:90500:1.2.0 -Scan Start: 2016-12-20 10:02:11 EST, Scan End: 2016-12-20 10:02:11 EST, Diff: 0 sec(s) -Start LSN: ff000028, End LSN: 100000000, TLI: 1 -flags: 0, Check Sum: f9cfe66ae2569894d6746b61503a767d - -Path: base/14845/16384 -NodeTag: BLOCK_CHANGE -Relation: relPath base/14845/16384, isTSNode 0, Blocks -*............................................................................. -First modified block: 0 -Total modified blocks: 1 - -Path: base/14845/16391 -NodeTag: BLOCK_CHANGE -Relation: relPath base/14845/16391, isTSNode 0, Blocks -*.............................................................................. -First modified block: 0 -Total modified blocks: 1 -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/index.mdx b/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/index.mdx deleted file mode 100644 index 20c71192ef2..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/01_bart_subcommands_examples/index.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: "BART Subcommand Syntax and Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/bart_subcommands_examples.html" ---- - - - -This section briefly describes each BART subcommand and provides an example. - -**Invoking BART** - -BART subcommands are invoked at the Linux command line as a BART user. You can invoke the `bart` program (located in the `/bin` directory) with the desired options to manage your BART installation. - -The following examples demonstrate ways of invoking BART. In these examples, the BART user account is named `bartuser`. - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ ./bart SHOW-SERVERS -``` - -To run BART from any current working directory: - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ bart SHOW-SERVERS -``` - -**Syntax for invoking BART** - -```text -bart [ ]... [ ] []... -``` - -You can use either abbreviated or long option forms on the command line (for example `-h` or `--help`). - -**General Options** - -You can specify the following general options with `bart`. - -`-h` or (`--help`) - -- Displays general syntax and information about BART usage. -- All subcommands support a help option (`-h, --help`). If the help option is specified, information is displayed regarding that particular subcommand. The subcommand, itself, is not executed. - -The following code sample displays the result of invoking the `--help` option for the `BACKUP` subcommand: - -```text --bash-4.2$ bart BACKUP --help -bart: backup and recovery tool - -Usage: -bart BACKUP [OPTION]... - -Options: --h, --help Show this help message and exit --s, --server Name of the server or 'all' (full backups only) to specify all servers --F, --format=p|t Backup output format (tar (default) or plain) --z, --gzip Enables gzip compression of tar files --c, --compress-level Specifies the compression level (1 through 9, 9 being - best compression) ---backup-name Specify a friendly name for the current backup ---parent Specify parent backup for incremental backup ---check Verify checksum of required mbm files -``` - -`-v` (or `--version`) - -The following code sample displays information returned by the `bart --version` subcommand: - -```text -[edb@localhost bin]$ bart --version -bart (EnterpriseDB) 2.5.2 -[edb@localhost bin]$ -``` - -`-d` (or `--debug`) - -The following code sample displays debugging output returned by the `bart MANAGE` subcommand: - -```text --bash-4.1$ bart -d MANAGE -n -DEBUG: Server: acctg, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -259200 (secs) ==> 72 hour(s) -DEBUG: Server: dev, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -1814400 (secs) ==> 504 hour(s) -DEBUG: Server: hr, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -7776000 (secs) ==> 2160 hour(s) -``` - -`-c` (or `--config-path) ` - -The following code sample demonstrates using the `-c` option to specify a non-default configuration file name and installation location: - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ bart -c /home/bartuser/bart.cfg SHOW-SERVERS -``` - -
- -backup check_config delete init manage restore show_servers show_backups verify_chksum running_the_bart_wal_scanner - -
diff --git a/product_docs/docs/bart/2.6.1/bart_ref/02_additional_examples.mdx b/product_docs/docs/bart/2.6.1/bart_ref/02_additional_examples.mdx deleted file mode 100644 index 38a519f727d..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/02_additional_examples.mdx +++ /dev/null @@ -1,1473 +0,0 @@ ---- -title: "Additional Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/additional_examples.html" ---- - - - -This section lists examples of the following BART operations. - -- Restoring a database cluster with tablespaces. -- Restoring an incremental backup. -- Managing backups. -- Managing incremental backups. - -## Restoring a Database Cluster with Tablespaces - -The following code sample illustrates taking a backup and restoring a database cluster on a remote host containing tablespaces. For detailed information regarding using tablespaces, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -On an Advanced Server database running on a remote host, the following tablespaces are created for use by two tables: - -```text -edb=# CREATE TABLESPACE tblspc_1 LOCATION '/mnt/tablespace_1'; -CREATE TABLESPACE -edb=# CREATE TABLESPACE tblspc_2 LOCATION '/mnt/tablespace_2'; -CREATE TABLESPACE -edb=# \db - List of tablespaces -Name | Owner | Location -------------+-----------------+------------------- -pg_default | enterprisedb | -pg_global | enterprisedb | -tblspc_1 | enterprisedb | /mnt/tablespace_1 -tblspc_2 | enterprisedb | /mnt/tablespace_2 -(4 rows) - -edb=# CREATE TABLE tbl_tblspc_1 (c1 TEXT) TABLESPACE tblspc_1; -CREATE TABLE -edb=# CREATE TABLE tbl_tblspc_2 (c1 TEXT) TABLESPACE tblspc_2; -CREATE TABLE -edb=# \d tbl_tblspc_1 -Table "enterprisedb.tbl_tblspc_1" -Column | Type | Modifiers --------+------+----------- -c1 | text | -Tablespace: "tblspc_1" - -edb=# \d tbl_tblspc_2 -Table "enterprisedb.tbl_tblspc_2" -Column | Type | Modifiers --------+------+----------- -c1 | text | -Tablespace: "tblspc_2" -``` - -The following code sample shows the OIDs assigned to the tablespaces and the symbolic links to the tablespace directories: - -```text --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS/data/pg_tblspc --bash-4.1$ ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Nov 16 16:17 16587 ->/mnt/tablespace_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Nov 16 16:17 16588 ->/mnt/tablespace_2 -``` - -The BART configuration file contains the following settings. Note that the `tablespace_path` parameter does not have to be set at this point. - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -tablespace_path = -description = "Accounting" -``` - -After the necessary configuration steps are performed to ensure BART manages the remote database server, a full backup is taken as shown in the following code sample: - -```text --bash-4.1$ bart BACKUP -s acctg - -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1447709811516' -54521/54521 kB (100%), 3/3 tablespaces - -INFO: backup completed successfully -INFO: backup checksum: 594f69fe7d26af991d4173d3823e174f of 16587.tar -INFO: backup checksum: 7a5507567729a21c98a15c948ff6c015 of base.tar -INFO: backup checksum: ae8c62604c409635c9d9e82b29cc0399 of 16588.tar -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1447709811516 -BACKUP NAME: none -BACKUP LOCATION: /opt/backup/acctg/1447709811516 -BACKUP SIZE: 53.25 MB -BACKUP FORMAT: tar -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 3 -ChkSum File -594f69fe7d26af991d4173d3823e174f 16587.tar -7a5507567729a21c98a15c948ff6c015 base.tar -ae8c62604c409635c9d9e82b29cc0399 16588.tar - -TABLESPACE(s): 2 -Oid Name Location -16587 tblspc_1 /mnt/tablespace_1 -16588 tblspc_2 /mnt/tablespace_2 -START WAL LOCATION: 00000001000000000000000F -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2015-11-16 16:36:51 EST -STOP TIME: 2015-11-16 16:36:52 EST -TOTAL DURATION: 1 sec(s) -``` - -Note that in the output from the preceding example, checksums are generated for the tablespaces as well as the full backup. - -Within the backup subdirectory `1447709811516` of the BART backup catalog, the tablespace data is stored with file names `16587.tar.gz` and `16588.tar.gz` as shown below: - -```text --bash-4.1$ pwd -/opt/backup/acctg --bash-4.1$ ls -l -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 16:36 1447709811516 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 16:43 archived_wals --bash-4.1$ ls -l 1447709811516 -total 54536 --rw-rw-r-- 1 enterprisedb enterprisedb 19968 Nov 16 16:36 16587.tar --rw-rw-r-- 1 enterprisedb enterprisedb 19968 Nov 16 16:36 16588.tar --rw-rw-r-- 1 enterprisedb enterprisedb 949 Nov 16 17:05 backupinfo --rw-rw-r-- 1 enterprisedb enterprisedb 55792640 Nov 16 16:36 base.tar -``` - -When you are ready to restore the backup, in addition to creating the directory to which the main database cluster is to be restored, you must prepare the directories to which the tablespaces are to be restored. - -On the remote host, directories `/opt/restore_tblspc_1` and `/opt/restore_tblspc_2` are created and assigned the proper ownership and permissions as shown by the following example. The main database cluster is to be restored to `/opt/restore`. - -```text -[root@localhost opt]# mkdir restore_tblspc_1 -[root@localhost opt]# chown enterprisedb restore_tblspc_1 -[root@localhost opt]# chgrp enterprisedb restore_tblspc_1 -[root@localhost opt]# chmod 700 restore_tblspc_1 - -[root@localhost opt]# mkdir restore_tblspc_2 -[root@localhost opt]# chown enterprisedb restore_tblspc_2 -[root@localhost opt]# chgrp enterprisedb restore_tblspc_2 -[root@localhost opt]# chmod 700 restore_tblspc_2 -[root@localhost opt]# ls -l -total 20 -drwxr-xr-x 3 root daemon 4096 Nov 10 15:38 PostgresPlus -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:40 restore -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:40 -restore_tblspc_1 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:41 -restore_tblspc_2 -drwxr-xr-x. 2 root root 4096 Nov 22 2013 rh -``` - -Set the `tablespace_path` parameter in the BART configuration file to specify the tablespace directories. The remote host user and IP address are specified by the `remote_host` configuration parameter. - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -tablespace_path = -16587=/opt/restore_tblspc_1;16588=/opt/restore_tblspc_2 - -description = "Accounting" -``` - -The following code sample demonstrates invoking the `RESTORE` subcommand: - -```text --bash-4.1$ bart RESTORE -s acctg -i 1447709811516 -p /opt/restore -INFO: restoring backup '1447709811516' of server 'acctg' -INFO: restoring backup to enterprisedb@192.168.2.24:/opt/restore -INFO: base backup restored -INFO: archiving is disabled -INFO: tablespace(s) restored -``` - -The following code sample shows the restored full backup (including the restored tablespaces): - -```text -bash-4.1$ pwd -/opt --bash-4.1$ ls -l restore -total 104 --rw------- 1 enterprisedb enterprisedb 206 Nov 16 16:36 backup_label.old -drwx------ 6 enterprisedb enterprisedb 4096 Nov 10 15:38 base -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:46 global -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_clog --rw------- 1 enterprisedb enterprisedb 4438 Nov 10 16:23 pg_hba.conf --rw------- 1 enterprisedb enterprisedb 1636 Nov 10 15:38 pg_ident.conf -drwxr-xr-x 2 enterprisedb enterprisedb 4096 Nov 16 17:45 pg_log -drwx------ 4 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_multixact -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:45 pg_notify -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_serial -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_snapshots -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_stat -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_stat_tmp -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_subtrans -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:42 pg_tblspc -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_twophase --rw------- 1 enterprisedb enterprisedb 4 Nov 10 15:38 PG_VERSION -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_xlog --rw------- 1 enterprisedb enterprisedb 23906 Nov 16 17:42 postgresql.conf --rw------- 1 enterprisedb enterprisedb 61 Nov 16 17:45 postmaster.opts --bash-4.1$ --bash-4.1$ ls -l restore_tblspc_1 -total 4 -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 16:18 -PG_9.6_201306121 --bash-4.1$ ls -l restore_tblspc_2 -total 4 -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 16:18 -PG_9.6_201306121 -``` - -The symbolic links in the `pg_tblspc` subdirectory point to the restored directory location: - -```text -bash-4.1$ pwd -/opt/restore/pg_tblspc --bash-4.1$ ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 21 Nov 16 17:42 16587 -> -/opt/restore_tblspc_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 21 Nov 16 17:42 16588 -> -/opt/restore_tblspc_2 -``` - -`psql` queries also show the restored tablespaces: - -```text -edb=# \db - - List of tablespaces -Name | Owner | Location -------------+--------------+----------------------- -pg_default | enterprisedb | -pg_global | enterprisedb | -tblspc_1 | enterprisedb | /opt/restore_tblspc_1 -tblspc_2 | enterprisedb | /opt/restore_tblspc_2 -``` - -## Restoring an Incremental Backup - -Restoring an incremental backup may require additional setup steps depending upon the host on which the incremental backup is to be restored. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -This section provides an example of creating backup chains and then restoring an incremental backup. - -**Creating a Backup Chain** - -A *backup chain* is the set of backups consisting of a full backup and all of its successive incremental backups. Tracing back on the parent backups of all incremental backups in the chain eventually leads back to that single, full backup. - -In the following example, the `allow_incremental_backups` parameter is set to `enabled` in the BART configuration file to permit incremental backups on the listed database server: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.27 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -allow_incremental_backups = enabled -description = "Accounting" -``` - -After the database server has been started with WAL archiving enabled to the BART backup catalog, the WAL scanner is started: - -```text --bash-4.2$ bart-scanner --daemon -``` - -First, a full backup is taken. - -```text --bash-4.2$ bart BACKUP -s acctg --backup-name full_1 -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1490649204327'\ -63364/63364 kB (100%), 1/1 tablespace -INFO: backup completed successfully -INFO: backup checksum: aae27d4a7c09dffc82f423221154db7e of base.tar -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490649204327 -BACKUP NAME: full_1 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1490649204327 -BACKUP SIZE: 61.88 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -aae27d4a7c09dffc82f423221154db7e base.tar -TABLESPACE(s): 0 -START WAL LOCATION: 00000001000000000000000E -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2017-03-27 17:13:24 EDT -STOP TIME: 2017-03-27 17:13:25 EDT -TOTAL DURATION: 1 sec(s) -``` - -A series of incremental backups are taken. The first incremental backup specifies the full backup as the parent. Each successive incremental backup then uses the preceding incremental backup as its parent. - -```text --bash-4.2$ bart BACKUP -s acctg -F p --parent full_1 --backup-name -incr_1-a -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649255649 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490649255649 -BACKUP NAME: incr_1-a -BACKUP PARENT: 1490649204327 -BACKUP LOCATION: /opt/backup/acctg/1490649255649 -BACKUP SIZE: 16.56 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000010 -STOP WAL LOCATION: 000000010000000000000010 -BACKUP METHOD: pg_start_backup -BACKUP FROM: master -START TIME: 2017-03-27 17:14:15 EDT -STOP TIME: 2017-03-27 17:14:16 EDT -TOTAL DURATION: 1 sec(s) --bash-4.2$ bart BACKUP -s acctg -F p --parent incr_1-a --backup-name -incr_1-b -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649336845 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -. -. -. --bash-4.2$ bart BACKUP -s acctg -F p --parent incr_1-b --backup-name -incr_1-c -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649414316 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -. -. -. -``` - -The following output of the `SHOW-BACKUPS` subcommand lists the backup chain, which are backups `full_1, incr_1-a, incr_1-b, and incr_1-c`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -For the `full backup full_1`, the `BACKUP PARENT` field contains `none`. For each incremental backup, the `BACKUP PARENT` field contains the backup identifier or name of its parent backup. - -A second backup chain is created in the same manner with the `BACKUP` subcommand. The following example shows the addition of the resulting, second backup chain consisting of full backup `full_2` and incremental backups `incr_2-a` and `incr_2-b`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649605607 incr_2-b incr_2-a 2017-03-27 17:20:06 ... -acctg 1490649587702 incr_2-a full_2 2017-03-27 17:19:48 ... -acctg 1490649528633 full_2 none 2017-03-27 17:18:49 ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -The following additional incremental backups starting with `incr_1-b-1`, which designates `incr_1-b` as the parent, results in the forking from that backup into a second line of backups in the chain consisting of `full_1, incr_1-a, incr_1-b, incr_1-b-1, incr_1-b-2`, and `incr_1-b-3` as shown in the following list: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649791430 incr_1-b-3 incr_1-b-2 2017-03-27 17:23:12 ... -acctg 1490649763929 incr_1-b-2 incr_1-b-1 2017-03-27 17:22:44 ... -acctg 1490649731672 incr_1-b-1 incr_1-b 2017-03-27 17:22:12 ... -acctg 1490649605607 incr_2-b incr_2-a 2017-03-27 17:20:06 ... -acctg 1490649587702 incr_2-a full_2 2017-03-27 17:19:48 ... -acctg 1490649528633 full_2 none 2017-03-27 17:18:49 ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -**Restoring an Incremental Backup** - -Restoring an incremental backup is done with the `RESTORE` subcommand in the same manner as for restoring a full backup. Specify the backup identifier or backup name of the incremental backup to be restored as shown in the following example. - -```text --bash-4.2$ bart RESTORE -s acctg -p /opt/restore -i incr_1-b -INFO: restoring incremental backup 'incr_1-b' of server 'acctg' -INFO: base backup restored -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: incremental restore completed successfully -``` - -Restoring incremental backup `incr_1-b` as shown by the preceding example results in the restoration of full backup `full_1`, then incremental backups `incr_1-a` and finally, `incr_1-b`. - -## Managing Backups - -This section illustrates evaluating, marking, and deleting backups using the `MANAGE` subcommand using a redundancy retention policy and a recovery window retention policy. For detailed information about the `MANAGE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - - -### Using a Redundancy Retention Policy - -The following code sample uses a redundancy retention policy to evaluate, mark, and delete backups as shown by the following server configuration: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The following list is the set of backups. Note that the last backup in the list has been marked as `keep`. - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 active -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -Invoke the `MANAGE` subcommand with the `-n` option to perform a dry run to observe which active backups would be changed to obsolete according to the retention policy as shown in the following code sample: - -```text --bash-4.1$ bart MANAGE -s acctg -n -INFO: processing server 'acctg', backup '1428768344061' -INFO: processing server 'acctg', backup '1428684537299' -INFO: processing server 'acctg', backup '1428589759899' -INFO: processing server 'acctg', backup '1428502049836' -INFO: marking backup '1428502049836' as obsolete -INFO: 6 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428422324880' -INFO: marking backup '1428422324880' as obsolete -INFO: 2 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428355371389' -``` - -The dry run shows that backups `1428502049836` and `1428422324880` would be marked as `obsolete`. - -!!! Note - A dry run does not change the backup status. The two backups that would be considered obsolete are still marked as `active`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 active -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -Invoke the `MANAGE` subcommand omitting the `-n` option to change and mark the status of the backups as `obsolete`: - -```text --bash-4.1$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1428768344061' -INFO: processing server 'acctg', backup '1428684537299' -INFO: processing server 'acctg', backup '1428589759899' -INFO: processing server 'acctg', backup '1428502049836' -INFO: marking backup '1428502049836' as obsolete -INFO: 6 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428422324880' -INFO: marking backup '1428422324880' as obsolete -INFO: 2 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428355371389' -``` - -The obsolete backups can be observed in a number of ways. Use the `MANAGE` subcommand with the `-l` option to list the `obsolete` backups: - -```text --bash-4.1$ bart MANAGE -s acctg -l -INFO: 6 WAL file(s) will be removed -SERVER NAME: acctg -BACKUP ID: 1428502049836 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-08 10:07:30 EDT -BACKUP SIZE: 55.25 MB -WAL FILE(s): 6 -WAL FILE: 000000010000000100000003 -WAL FILE: 000000010000000100000002 -WAL FILE: 000000010000000100000001 -WAL FILE: 000000010000000100000000 -WAL FILE: 0000000100000000000000E3 -WAL FILE: 0000000100000000000000E2 -INFO: 2 WAL file(s) will be removed -SERVER NAME: acctg -BACKUP ID: 1428422324880 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-07 11:58:45 EDT -BACKUP SIZE: 54.53 MB -WAL FILE(s): 2 -WAL FILE: 0000000100000000000000E1 -WAL FILE: 0000000100000000000000E0 -``` - -The `STATUS` field of the `SHOW-BACKUPS` subcommand displays the current status: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 obsolete -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 obsolete -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -The details of an individual backup can be displayed using the `SHOW-BACKUPS` subcommand with the `-t` option. Note the status in the `BACKUP STATUS` field. - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -i 1428502049836 -t -SERVER NAME : acctg -BACKUP ID : 1428502049836 -BACKUP NAME : none -BACKUP STATUS : obsolete -BACKUP TIME : 2015-04-08 10:07:30 EDT -BACKUP SIZE : 55.25 MB -WAL(S) SIZE : 96.00 MB -NO. OF WALS : 6 -FIRST WAL FILE : 0000000100000000000000E2 -CREATION TIME : 2015-04-08 10:07:30 EDT -LAST WAL FILE : 000000010000000100000003 -CREATION TIME : 2015-04-09 10:25:46 EDT -``` - -Use the `MANAGE` subcommand with the `-d` option to physically delete the `obsolete` backups including the unneeded WAL files. - -```text --bash-4.1$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1428502049836' -INFO: 6 WAL file(s) will be removed -INFO: removing WAL file '000000010000000100000003' -INFO: removing WAL file '000000010000000100000002' -INFO: removing WAL file '000000010000000100000001' -INFO: removing WAL file '000000010000000100000000' -INFO: removing WAL file '0000000100000000000000E3' -INFO: removing WAL file '0000000100000000000000E2' -INFO: removing obsolete backup '1428422324880' -INFO: 2 WAL file(s) will be removed -INFO: removing WAL file '0000000100000000000000E1' -INFO: removing WAL file '0000000100000000000000E0' -``` - -The `SHOW-BACKUPS` subcommand now displays the remaining backups marked as `active` or `keep`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - - - -### Using a Recovery Window Retention Policy - -This section illustrates the evaluation, marking, and deletion of backup using a recovery window retention policy. To use the recovery window retention policy, set the `retention_policy` parameter to the desired length of time for the recovery window. - -This section provides examples of the following: - -- How to view the calculated recovery window. -- How to evaluate, mark, and delete backup using a recovery window retention policy. - -#### Viewing the Recovery Window - -You can view the actual, calculated recovery window by invoking any of the following subcommands: - -- `MANAGE` subcommand in debug mode (along with the `-n` option). -- `SHOW-SERVERS` subcommand. - -##### Viewing the Recovery Window Using the Manage Subcommand - -When invoking BART in debug mode with the `MANAGE` subcommand and the `-n` option, the length of the recovery window is calculated based on the `retention_policy` setting and the current date/time. - -For example, using the following `retention_policy` settings: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -backup-name = acctg_%year-%month-%dayT%hour:%minute:%second -description = "Accounting" - -[DEV] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 WEEKS -description = "Development" - -[HR] - -host = 127.0.0.1 -port = 5432 -user = postgres -retention_policy = 3 MONTHS -description = "Human Resources" -``` - -If the `MANAGE` subcommand is invoked in debug mode along with the `-n` option on 2015-04-17, the following results are displayed: - -```text --bash-4.1$ bart -d MANAGE -n -DEBUG: Server: acctg, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -259200 (secs) ==> 72 hour(s) -DEBUG: Server: dev, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -1814400 (secs) ==> 504 hour(s) -DEBUG: Server: hr, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -7776000 (secs) ==> 2160 hour(s) -``` - -For server `acctg`, 72 hours translates to a recovery window of 3 days. - -For server `dev`, 504 hours translates to a recovery window of 21 days (3 weeks). - -For server `hr`, 2160 hours translates to a recovery window of 90 days (3 months). - -For a setting of ` MONTHS`, the calculated total number of days for the recovery window is dependent upon the actual number of days in the preceding months from the current date/time. Thus, ` MONTHS` is not always exactly equivalent to ` x 30 DAYS`. For example, if the current date/time is in the month of March, a 1-month recovery window would be equivalent to only 28 days because the preceding month is February. Thus, for a current date of March 31, a 1-month recovery window would start on March 3. However, the typical result is that the day of the month of the starting recovery window boundary will be the same day of the month of when the `MANAGE` subcommand is invoked. - -##### Viewing the Recovery Window Using the Show-Servers Subcommand - -This section provides an example of viewing the recovery window using the `SHOW-SERVERS` subcommand; the `RETENTION POLICY` field displays the start of the recovery window. - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-day recovery window as the active backups. - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -description = "Accounting" -``` - -The start of the 3-day recovery window displayed in the `RETENTION POLICY` field is `2015-04-07 14:57:36 EDT` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-04-07 14:57:36 EDT` would be considered active. Backups taken prior to `2015-04-07 14:57:36 EDT` would be considered obsolete except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 14:57:33 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 2015-04-07 14:57:36 EDT -DISK UTILIZATION : 824.77 MB -NUMBER OF ARCHIVES : 37 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/acctg/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Accounting" -``` - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-week recovery window as the `active` backups. - -```text -[DEV] -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 WEEKS -description = "Development" -``` - -The start of the 3-week recovery window displayed in the `RETENTION POLICY` field is `2015-03-20 14:59:42 EDT` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-03-20 14:59:42 EDT` would be considered `active`. Backups taken prior to `2015-03-20 14:59:42 EDT` would be considered `obsolete` except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 14:59:39 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s dev -SERVER NAME : dev -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5445 -REMOTE HOST : -RETENTION POLICY : 2015-03-20 14:59:42 EDT -DISK UTILIZATION : 434.53 MB -NUMBER OF ARCHIVES : 22 -ARCHIVE PATH : /opt/backup/dev/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/dev/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Development" -``` - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-month recovery window as the `active` backups. - -```text -[HR] -host = 127.0.0.1 -port = 5432 -user = postgres -retention_policy = 3 MONTHS -description = "Human Resources" -``` - -The start of the 3-month recovery window displayed in the `RETENTION POLICY` field is `2015-01-10 14:04:23 EST` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-01-10 14:04:23 EST` would be considered `active`. Backups taken prior to `2015-01-10 14:04:23 EST` would be considered `obsolete`, except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 15:04:19 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s hr -SERVER NAME : hr -HOST NAME : 127.0.0.1 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : -RETENTION POLICY : 2015-01-10 14:04:23 EST -DISK UTILIZATION : 480.76 MB -NUMBER OF ARCHIVES : 26 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Human Resources" -``` - -#### Evaluating, Marking, and Deleting Backup Using a Recovery Window Retention Policy - -The following code sample uses a recovery window retention policy to evaluate, mark, and delete backups as shown by the following server configuration: - -```text -[DEV] -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -description = "Development" -``` - -The following is the current set of backups. Note that the last backup in the list has been marked as `keep`. - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB -14 active -dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB -3 active -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -The current date and time is `2015-04-13 16:46:35 EDT` as shown below: - -```text --bash-4.1$ date -Mon Apr 13 16:46:35 EDT 2015 -``` - -Thus, a 3-day recovery window would evaluate backups prior to `2015-04-10 16:46:35 EDT` as `obsolete` except for those marked as `keep`. - -Invoke the `MANAGE` subcommand with the `-n` option to perform a dry run to observe which active backups would be changed to `obsolete` according to the retention policy. - -```text --bash-4.1$ bart MANAGE -s dev -n -INFO: processing server 'dev', backup '1428933278236' -INFO: processing server 'dev', backup '1428862187757' -INFO: processing server 'dev', backup '1428768351638' -INFO: processing server 'dev', backup '1428684544008' -INFO: marking backup '1428684544008' as obsolete -INFO: 14 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428590536488' -INFO: marking backup '1428590536488' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428502171990' -``` - -The dry run shows that backups `1428684544008` and `1428590536488` would be marked as `obsolete`. - -Also note that a dry run does not change the backup status. The two backups that would be considered obsolete are still marked as `active`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev\ - SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE - WAL FILES STATUS - dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB - 1 active - dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB - 2 active - dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB - 2 active - dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB - 14 active - dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB - 3 active - dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB - 5 keep -``` - -Invoke the `MANAGE` subcommand omitting the `-n` option to change and mark the status of the backups as `obsolete`: - -```text --bash-4.1$ bart MANAGE -s dev -INFO: processing server 'dev', backup '1428933278236' -INFO: processing server 'dev', backup '1428862187757' -INFO: processing server 'dev', backup '1428768351638' -INFO: processing server 'dev', backup '1428684544008' -INFO: marking backup '1428684544008' as obsolete -INFO: 14 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428590536488' -INFO: marking backup '1428590536488' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428502171990' -``` - -The obsolete backups can be observed in a number of ways. Use the `MANAGE` subcommand with the `-l` option to list the `obsolete` backups: - -```text --bash-4.1$ bart MANAGE -s dev -l -INFO: 14 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -SERVER NAME: dev -BACKUP ID: 1428684544008 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-10 12:49:06 EDT -BACKUP SIZE: 5.65 MB -WAL FILE(s): 14 -UNUSED WAL FILE(s): 1 -WAL FILE: 00000001000000000000002E -WAL FILE: 00000001000000000000002D -WAL FILE: 00000001000000000000002C -WAL FILE: 00000001000000000000002B -WAL FILE: 00000001000000000000002A -WAL FILE: 000000010000000000000029 -WAL FILE: 000000010000000000000028 -WAL FILE: 000000010000000000000027 -WAL FILE: 000000010000000000000026 -WAL FILE: 000000010000000000000025 -WAL FILE: 000000010000000000000024 -WAL FILE: 000000010000000000000023 -WAL FILE: 000000010000000000000022 -WAL FILE: 000000010000000000000021 -UNUSED WAL FILE: 00000001000000000000000F.00000028 -INFO: 3 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -SERVER NAME: dev -BACKUP ID: 1428590536488 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-09 10:42:18 EDT\ -BACKUP SIZE: 5.65 MB -WAL FILE(s): 3 -UNUSED WAL FILE(s): 1 -WAL FILE: 000000010000000000000020 -WAL FILE: 00000001000000000000001F -WAL FILE: 00000001000000000000001E -UNUSED WAL FILE: 00000001000000000000000F.00000028 -``` - -The `STATUS` field of the `SHOW-BACKUPS` subcommand displays the current status: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB -14 obsolete -dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB -3 obsolete -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -The details of an individual backup can be displayed using the `SHOW-BACKUPS` subcommand with the `-t` option. Note the status in the `BACKUP STATUS` field. - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -i 1428684544008 -t -SERVER NAME : dev -BACKUP ID : 1428684544008 -BACKUP NAME : none -BACKUP STATUS : obsolete -BACKUP TIME : 2015-04-10 12:49:06 EDT -BACKUP SIZE : 5.65 MB -WAL(S) SIZE : 224.00 MB -NO. OF WALS : 14 -FIRST WAL FILE : 000000010000000000000021 -CREATION TIME : 2015-04-10 12:49:06 EDT -LAST WAL FILE : 00000001000000000000002E -CREATION TIME : 2015-04-11 12:02:15 EDT -``` - -Use the `MANAGE` subcommand with the `-d` option to physically delete the obsolete backups including the unneeded WAL files. - -```text --bash-4.1$ bart MANAGE -s dev -d -INFO: removing all obsolete backups of server 'dev' -INFO: removing obsolete backup '1428684544008' -INFO: 14 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -INFO: removing WAL file '00000001000000000000002E' -INFO: removing WAL file '00000001000000000000002D' -INFO: removing WAL file '00000001000000000000002C' -INFO: removing WAL file '00000001000000000000002B' -INFO: removing WAL file '00000001000000000000002A' -INFO: removing WAL file '000000010000000000000029' -INFO: removing WAL file '000000010000000000000028' -INFO: removing WAL file '000000010000000000000027' -INFO: removing WAL file '000000010000000000000026' -INFO: removing WAL file '000000010000000000000025' -INFO: removing WAL file '000000010000000000000024' -INFO: removing WAL file '000000010000000000000023' -INFO: removing WAL file '000000010000000000000022' -INFO: removing WAL file '000000010000000000000021' -INFO: removing (unused) WAL file '00000001000000000000000F.00000028' -INFO: removing obsolete backup '1428590536488' -INFO: 3 WAL file(s) will be removed -INFO: removing WAL file '000000010000000000000020' -INFO: removing WAL file '00000001000000000000001F' -INFO: removing WAL file '00000001000000000000001E' -``` - -The `SHOW-BACKUPS` subcommand now displays the remaining backups marked as `active` or `keep`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -## Managing Incremental Backups - -This section illustrates evaluating, marking, and deleting incremental backups using the `MANAGE` and `DELETE` subcommands utilizing redundancy retention policy and recovery window retention policy. For detailed information about the `MANAGE` and `DELETE` subcommands, as well as the redundancy retention and recovery window retention policy, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -- [Using a Redundancy Retention Policy](#redundancy_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 3 backup redundancy retention policy is in effect. -- [Using a Recovery Window Retention Policy](#recovery_window_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 1-day recovery window retention policy is in effect. - - - -### Using a Redundancy Retention Policy - -The following code sample uses the `MANAGE` and `DELETE` subcommands to evaluate, mark, and delete incremental backups when a 3 backup redundancy retention policy is in effect. The example uses the following server configuration: - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The example uses the following set of backups. In these code samples, some columns have been omitted from the `SHOW-BACKUPS` output to display the relevant information in a more observable manner. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -There is one backup chain. The first backup is the initial full backup. - -Backup chain: `1481749619582 => 1481749651927 => 1481749673603 => 1481749696905` - -The `MANAGE` subcommand is invoked as shown by the following: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481749619582' -INFO: 2 Unused WAL file(s) present -INFO: 4 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample shows the resulting status of the backups: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -The status remains active for all backups. Even though the total number of backups exceeds the 3 backup redundancy retention policy, it is only the total number of full backups that is used to determine if the redundancy retention policy has been exceeded. Additional full backups are added including a second backup chain. The following example shows the resulting list of backups: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -Second backup chain: `1481749997807 => 1481750098924` - -The `MANAGE` subcommand is invoked, but now with a total of four active full backups. - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481750365397' -INFO: processing server 'acctg', backup '1481749997807' -INFO: processing server 'acctg', backup '1481749992003' -INFO: processing server 'acctg', backup '1481749619582' -INFO: marking backup '1481749619582' as obsolete -INFO: 3 incremental(s) of backup '1481749619582' will be marked obsolete -INFO: marking incremental backup '1481749696905' as obsolete -INFO: marking incremental backup '1481749673603' as obsolete -INFO: marking incremental backup '1481749651927' as obsolete -INFO: 4 WAL file(s) marked obsolete -INFO: 2 Unused WAL file(s) present -INFO: 4 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The oldest full backup and its chain of incremental backups are now marked as obsolete. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... obsolete -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... obsolete -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... obsolete -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... obsolete -``` - -Invoking the `MANAGE` subcommand with the `-d` option deletes the entire obsolete backup chain. - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1481749619582' -INFO: 4 WAL file(s) will be removed -INFO: 3 incremental(s) of backup '1481749619582' will be removed -INFO: removing obsolete incremental backup '1481749696905' -INFO: removing obsolete incremental backup '1481749673603' -INFO: removing obsolete incremental backup '1481749651927' -INFO: removing WAL file '000000010000000100000000' -INFO: removing WAL file '0000000100000000000000FF' -INFO: removing WAL file '0000000100000000000000FE' -INFO: removing WAL file '0000000100000000000000FD' -INFO: 16 Unused file(s) will be removed -INFO: removing (unused) file '000000010000000100000004.00000028.backup' -. -. -. -INFO: removing (unused) file -'0000000100000000FB00002800000000FC000000.mbm' -``` - -The following code sample shows the remaining full backups and the second backup chain. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -``` - - - -### Using a Recovery Window Retention Policy - -The following example demonstrates using the `MANAGE` and `DELETE` subcommands to evaluate, mark, and delete incremental backups when a 1-day recovery window retention policy is in effect. The example uses the following server configuration: - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -retention_policy = 1 DAYS -description = "Accounting" -``` - -The example uses the following set of backups. In the samples, some columns have been omitted from the `SHOW-BACKUPS` output to display the relevant information in a more observable manner. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST ... active -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -There are two backup chains. In each of the following chains, the first backup is the initial full backup. - -First backup chain: `1481552078404 => 1481553088053 => 1481553914533 => 1481554802918 => 1481559014359` - -Second backup chain: `1481553651165 => 1481554203288 => 1481559303348` - -The `MANAGE` subcommand is invoked when the first full backup `1481552078404` falls out of the recovery window. When the `MANAGE` subcommand is invoked, it is `2016-12-13 09:20:03 EST`, thus making the start of the 1-day recovery window at `2016-12-12 09:20:03 EST` exactly one day earlier. This backup was taken at `2016-12-12 09:14:39 EST`, which is about 5 ½ minutes before the start of the recovery window, thus making the backup obsolete. - -```text --bash-4.2$ date -Tue Dec 13 09:20:03 EST 2016 --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481553651165' -INFO: processing server 'acctg', backup '1481552078404' -INFO: marking backup '1481552078404' as obsolete -INFO: 4 incremental(s) of backup '1481552078404' will be marked obsolete -INFO: marking incremental backup '1481559014359' as obsolete -INFO: marking incremental backup '1481554802918' as obsolete -INFO: marking incremental backup '1481553914533' as obsolete -INFO: marking incremental backup '1481553088053' as obsolete -INFO: 7 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the list -``` - -The incremental backup date and time are within the recovery window since they were taken after the start of the recovery window of `2016-12-12 09:20:03 EST`, but all backups in the chain are marked as `obsolete`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg\ -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST -... obsolete -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST -... obsolete -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -The following code sample shows how the entire backup chain is changed back to active status by invoking the `MANAGE` subcommand with the `-c nokeep` option on the full backup of the chain. - -```text --bash-4.2$ bart MANAGE -s acctg -c nokeep -i 1481552078404 -INFO: changing status of backup '1481552078404' of server 'acctg' from -'obsolete' to 'active' -INFO: status of 4 incremental(s) of backup '1481552078404' will be -changed -INFO: changing status of incremental backup '1481559014359' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481554802918' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481553914533' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481553088053' of server -'acctg' from 'obsolete' to 'active' -INFO: 7 WAL file(s) changed -``` - -The backup chain has now been reset to active status. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST ... active -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -The following code sample shows usage of the `DELETE` subcommand on an incremental backup. The specified incremental backup `1481554802918` in the first backup chain as well as its successive incremental backup `1481559014359` are deleted. - -```text --bash-4.2$ bart DELETE -s acctg -i 1481554802918 -INFO: deleting backup '1481554802918' of server 'acctg' -INFO: deleting backup '1481554802918' -INFO: 1 incremental backup(s) will be deleted -INFO: deleting incremental backup '1481559014359' -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or -will be marked unused -INFO: 2 Unused file(s) will be removed -INFO: removing (unused) file '0000000100000000000000BA' -INFO: removing (unused) file -'0000000100000000BA00002800000000BB000000.mbm' -INFO: backup(s) deleted -``` - -The results show that the backups `1481554802918` and `1481559014359` are no longer listed by the `SHOW-BACKUPS` subcommand. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -The `MANAGE` subcommand is invoked again. This time both backup chains are marked `obsolete` since the full backups of both chains fall out of the start of the recovery window, which is now `2016-12-12 09:55:03 EST`. - -```text --bash-4.2$ date -Tue Dec 13 09:55:03 EST 2016 --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481553651165' -INFO: marking backup '1481553651165' as obsolete -INFO: 2 incremental(s) of backup '1481553651165' will be marked obsolete -INFO: marking incremental backup '1481559303348' as obsolete -INFO: marking incremental backup '1481554203288' as obsolete -INFO: 38 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1481552078404' -INFO: marking backup '1481552078404' as obsolete -INFO: 2 incremental(s) of backup '1481552078404' will be marked obsolete -INFO: marking incremental backup '1481553914533' as obsolete -INFO: marking incremental backup '1481553088053' as obsolete -INFO: 7 WAL file(s) marked obsolete -``` - -The following code sample shows both backup chains marked as `obsolete`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... obsolete -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... obsolete -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... obsolete -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -The following code sample demonstrates using the `MANAGE` subcommand with the `-c keep` option to keep a backup chain indefinitely. The `MANAGE` subcommand with the `-c keep` option must specify the backup identifier or backup name of the full backup of the chain, and not any incremental backup. - -```text --bash-4.2$ bart MANAGE -s acctg -c keep -i 1481553651165 -INFO: changing status of backup '1481553651165' of server 'acctg' from -'obsolete' to 'keep' -INFO: status of 2 incremental(s) of backup '1481553651165' will be -changed -INFO: changing status of incremental backup '1481559303348' of server -'acctg' from 'obsolete' to 'keep' -INFO: changing status of incremental backup '1481554203288' of server -'acctg' from 'obsolete' to 'keep' -INFO: 38 WAL file(s) changed -``` - -The full backup `1481553651165` and its successive incremental backups `1481554203288` and `1481559303348` have been changed to `keep` status: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... keep -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... keep -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... keep -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -Finally, the `MANAGE` subcommand with the `-d` option is used to delete the `obsolete` backup chain: - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1481552078404' -INFO: 7 WAL file(s) will be removed -INFO: 2 incremental(s) of backup '1481552078404' will be removed -INFO: removing obsolete incremental backup '1481553914533' -INFO: removing obsolete incremental backup '1481553088053' -INFO: removing WAL file '0000000100000000000000C1' -INFO: removing WAL file '0000000100000000000000C0' -INFO: removing WAL file '0000000100000000000000BF' -INFO: removing WAL file '0000000100000000000000BE' -INFO: removing WAL file '0000000100000000000000BD' -INFO: removing WAL file '0000000100000000000000BC' -INFO: removing WAL file '0000000100000000000000BB' -INFO: 48 Unused file(s) will be removed -INFO: removing (unused) file '0000000100000000000000FA' -. -. -. -INFO: removing (unused) file '0000000100000000000000BB.00000028.backup' -``` - -Only the backup chain with the `keep` status remains as shown below: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... keep -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... keep -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... keep -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx b/product_docs/docs/bart/2.6.1/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx deleted file mode 100644 index b1527216806..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx +++ /dev/null @@ -1,1385 +0,0 @@ ---- -title: "Sample BART System with Local and Remote Database Servers" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/sample_bart_system_with_local_and_remote_database_servers.html" ---- - - - -This section describes a sample BART managed backup and recovery system consisting of both local and remote database servers. The complete steps to configure and operate the system are provided. - -For detailed information about configuring a BART system, see the *EDB Backup and Recovery Installation and Upgrade Guide*. For detailed information about the operational procedures and BART subcommands, see the *EDB Backup and Recovery User Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). - -The environment for this sample system is as follows: - -- BART on host `192.168.2.22` running with BART user account `enterprisedb` -- Local Advanced Server on host `192.168.2.22` running with user account `enterprisedb` -- Remote Advanced Server on host `192.168.2.24` running with user account `enterprisedb` -- Remote PostgreSQL server on host `192.168.2.24` running with user account `postgres` - -Passwordless SSH/SCP connections are required between the following: - -- BART on host `192.168.2.22` and the local Advanced Server on the same host `192.168.2.22` -- BART on host `192.168.2.22` and the remote Advanced Server on host `192.168.2.24` -- BART on host `192.168.2.22` and the remote PostgreSQL server on host `192.168.2.24` - -The following sections demonstrate configuring and taking full backups only. To support incremental backups as well, enable the `allow_incremental_backups` parameter for the desired database servers and use the `WAL scanner` program. - -- [The BART Configuration File](#bart_configuration_file) shows the settings used in the BART configuration file. -- [Establishing SSH/SCP Passwordless Connections](#establishing-sshscp-passwordless-connections) provides an example of how to establish an SSH/SCP passwordless connection. -- [Configuring a Replication Database User](#configuring-a-replication-database-user) provides an example of how to configure the replication database user. -- [WAL Archiving Configuration Parameters](#wal-archiving-configuration-parameters) provides an example of how to configure WAL archiving. -- [Creating the BART Backup Catalog](#creating-the-bart-backup-catalog-backup_path) provides information about creating a BART Backup Catalog. -- [Starting the Database Servers with WAL Archiving](#starting-the-database-servers-with-wal-archiving) provides example of starting the database servers with WAL archiving. -- [Taking a Full Backup](#taking-a-full-backup) illustrates taking the first full backup of the database servers. -- [Using Point-In-Time Recovery](#using-point-in-time-recovery) demonstrates the point-in-time recovery operation on the remote PostgreSQL database server. - - - -## The BART Configuration File - -The following code sample shows the settings used in the BART configuration file for the examples that follow: - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" - -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" - -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - - - -## Establishing SSH/SCP Passwordless Connections - -This section demonstrates how passwordless SSH/SCP connections are established with the authorized public keys files. - - - -### Generating a Public Key File for the BART User Account - -The BART user account is `enterprisedb` with a home directory of `/opt/PostgresPlus/9.6AS`. - -To generate the public key file, as a root user, first create the `.ssh` subdirectory in the BART user’s home directory and assign ownership of this directory to the `enterprisedb` user, ensuring there are no groups or other users that can access the `.ssh` directory. - -```text -[root@localhost 9.6AS]# pwd -/opt/PostgresPlus/9.6AS -[root@localhost 9.6AS]# mkdir .ssh -[root@localhost 9.6AS]# chown enterprisedb .ssh -[root@localhost 9.6AS]# chgrp enterprisedb .ssh -[root@localhost 9.6AS]# chmod 700 .ssh -[root@localhost 9.6AS]# ls -la | grep ssh -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 13:02 .ssh -``` - -Generate the public key file: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key -(/opt/PostgresPlus/9.6AS/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa. -Your public key has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa.pub. -The key fingerprint is: -de:65:34:d6:b1:d2:32:3c:b0:43:c6:a3:c0:9f:f4:64 -enterprisedb@localhost.localdomain -The key's randomart image is: -+----[ RSA 2048]----+ -| . .+ . | -| o .oE+ o o | -| + * o.X + | -| + .+ * | -| S o | -| . . o | -| . . | -| - | -| | -+-------------------+ -``` - -The following are the resulting files. `id_rsa.pub` is the public key file of BART user account `enterprisedb`. - -```text --bash-4.1$ ls -l .ssh -total 8 --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -### Configuring Access between Local Advanced Server and the BART Host - -Even when the Advanced Server database is on the same host as the BART user account, and the Advanced Server database cluster owner is also the BART user account (`enterprisedb` is this case), a passwordless SSH/SCP connection must be established from the same user account to itself. - -On the BART host where the public key file was just generated (as shown in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account)), create the authorized keys file by appending the public key file to any existing authorized keys file. - -Log into the BART host as the BART user account and append the public key file, `id_rsa.pub` onto the `authorized_keys` file in the same `.ssh` directory. - -```text -[user@localhost ~]$ su - enterprisedb -Password: -Last login: Thu Mar 23 10:27:35 EDT 2017 on pts/0 --bash-4.2$ pwd -/opt/PostgresPlus/9.6AS --bash-4.2$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts --bash-4.2$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys --bash-4.2$ ls -l .ssh -total 16 --rw-rw-r-- 1 enterprisedb enterprisedb 416 Mar 23 10:33 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts -``` - -The `authorized_keys` file must have file permission `600` as set by the following `chmod 600` command, or the passwordless connection will fail: - -```text --bash-4.2$ chmod 600 ~/.ssh/authorized_keys --bash-4.2$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 416 Mar 23 10:33 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts -``` - -Test the passwordless connection. Use the `ssh` command to verify that you can access the same user account as you are currently logged in as (`enterprisedb`) without being prompted for a password: - -```text --bash-4.2$ ssh enterprisedb@127.0.0.1 -Last login: Thu Mar 23 10:27:50 2017 --bash-4.2$ exit -logout -Connection to 127.0.0.1 closed. -``` - -### Configuring Access from Remote Advanced Server to BART Host - -On the remote host `192.168.2.24`, create the public key file for the remote database server user account, `enterprisedb`, for access to the BART user account, `enterprisedb`, on the BART host 192.168.2.22. - -Create the `.ssh` directory for user account `enterprisedb` on the remote host: - -```text -[root@localhost 9.6AS]# pwd -/opt/PostgresPlus/9.6AS -[root@localhost 9.6AS]# mkdir .ssh -[root@localhost 9.6AS]# chown enterprisedb .ssh -[root@localhost 9.6AS]# chgrp enterprisedb .ssh -[root@localhost 9.6AS]# chmod 700 .ssh -[root@localhost 9.6AS]# ls -la | grep ssh -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 13:08 .ssh -``` - -Generate the public key file on the remote host for user account `enterprisedb`: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key -(/opt/PostgresPlus/9.6AS/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa. -Your public key has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa.pub. -The key fingerprint is: -15:27:1e:1e:61:4b:48:66:67:0b:b2:be:fc:ea:ea:e6 -enterprisedb@localhost.localdomain -The key's randomart image is: -+--[ RSA 2048]---+ -| ..=.@.. | -| =.O O | -| . * | -| . . | -| . S | -| . . | -| o | -| . . | -| +Eoo.. | -+----------------+ -``` - -Copy the generated public key file, `id_rsa.pub`, to the BART user account, `enterprisedb`, on the BART host, `192.168.2.22`: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.22:/tmp/tmp.pub -The authenticity of host '192.168.2.22 (192.168.2.22)' can't be -established. -RSA key fingerprint is b8:a9:97:31:79:16:b8:2b:b0:60:5a:91:38:d7:68:22. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.22' (RSA) to the list of known hosts. -enterprisedb@192.168.2.22's password: -id_rsa.pub -``` - -Log into the BART host as the BART user account and append the temporary public key file, `/tmp/tmp.pub` onto the `authorized_keys` file owned by the BART user account. - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -enterprisedb@192.168.2.22's password: -Last login: Tue Apr 21 17:03:24 2015 from 192.168.2.22 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 12 --rw-rw-r-- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -The `authorized_keys` file must have file permission `600` as set by the following `chmod 600` command, otherwise the passwordless connection fails: - -```text --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -Test the passwordless connection. From the remote host, verify that you can log into the BART host with the BART user account without being prompted for a password: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -Last login: Thu Apr 23 13:14:48 2015 from 192.168.2.24 --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -### Configuring Access from the BART Host to a Remote Advanced Server - -On the BART host `192.168.2.22`, copy the public key file for the BART user account, `enterprisedb`, for access to the remote database server user account, `enterprisedb`, on the remote host `192.168.2.24`. - -The following lists the current SSH keys files in the BART user’s `.ssh` directory on the BART host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -The public key file, `id_rsa.pub`, for BART user account `enterprisedb` on the BART host that was earlier generated in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account), is now copied to the remote Advanced Server host on `192.168.2.24`: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.24:/tmp/tmp.pub -The authenticity of host '192.168.2.24 (192.168.2.24)' can't be -established. -RSA key fingerprint is 59:41:fb:0c:ae:64:3d:3f:a2:d9:90:95:cf:2c:99:f2. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.24' (RSA) to the list of known -hosts. -enterprisedb@192.168.2.24's password: -id_rsa.pub -``` - -Log into the `enterprisedb` user account on the remote host and copy the public key file onto the `authorized_keys` file of the remote `enterprisedb` user account under its `.ssh` directory: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.24 -enterprisedb@192.168.2.24's password: -Last login: Tue Apr 21 09:53:18 2015 from 192.168.2.22 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:11 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:11 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:12 known_hosts --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys -``` - -Adjust the file permission on `authorized_keys`: - -```text --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:26 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:11 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:11 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:12 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -While logged into the BART host, test the passwordless connection from the BART host to the remote Advanced Server host: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.24 -Last login: Thu Apr 23 13:25:53 2015 from 192.168.2.22 --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -### Configuring Access from a Remote PostgreSQL Server to a BART Host - -On the remote host (192.168.2.24), create a public key file owned by the database server user account (`postgres`), allowing access to the BART user account (`enterprisedb`) on the BART host (192.168.2.22). - -Create the `.ssh` directory for the `postgres` user account on the remote host: - -```text -[root@localhost 9.6]# cd /opt/PostgreSQL/9.6 -[root@localhost 9.6]# mkdir .ssh -[root@localhost 9.6]# chown postgres .ssh -[root@localhost 9.6]# chgrp postgres .ssh -[root@localhost 9.6]# chmod 700 .ssh -[root@localhost 9.6]# ls -la | grep ssh -drwx------ 2 postgres postgres 4096 Apr 23 13:32 .ssh -``` - -Create and copy the generated public key file, `id_rsa.pub`, to the BART user account (`enterprisedb`), on the BART host (`192.168.2.22`): - -```text -[user@localhost ~]$ su - postgres -Password: --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key (/opt/PostgreSQL/9.6/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in /opt/PostgreSQL/9.6/.ssh/id_rsa. -Your public key has been saved in /opt/PostgreSQL/9.6/.ssh/id_rsa.pub. -The key fingerprint is: -1f:f8:76:d6:fc:a5:1a:c5:5a:66:66:01:d0:a0:ca:ba -postgres@localhost.localdomain -The key's randomart image is: -+--[ RSA 2048]----+ -| o+. | -| . .. | -| . . | -| . . . . . | -| o S . O | -| . o . @ | -| . + = o .| -| . . o . o.| -| E ... .| -+-----------------+ --bash-4.1$ ls -l .ssh -total 8 --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.22:/tmp/tmp.pub -The authenticity of host '192.168.2.22 (192.168.2.22)' can't be -established. -RSA key fingerprint is b8:a9:97:31:79:16:b8:2b:b0:60:5a:91:38:d7:68:22. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.22' (RSA) to the list of known -hosts. -enterprisedb@192.168.2.22's password: -id_rsa.pub -``` - -Log into the BART host as the BART user account and append the temporary public key file, `/tmp/tmp.pub`, onto the `authorized_keys` file owned by the BART user account. - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -enterprisedb@192.168.2.22's password: -Last login: Thu Apr 23 13:19:25 2015 from 192.168.2.24 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 828 Apr 23 13:40 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:24 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -Make sure the `authorized_keys` file has file permission 600 as shown, or the passwordless connection will fail. Test the passwordless connection; from the remote host, while logged in as user account `postgres`, verify that you can log into the BART host with the BART user account without being prompted for a password: - -```text --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ ssh enterprisedb@192.168.2.22 -Last login: Thu Apr 23 13:40:10 2015 from 192.168.2.24 --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -### Configuring Access from the BART Host to Remote PostgreSQL - -Copy the public key file on the BART host that is owned by the BART user account (`enterprisedb`) to the remote database server user account (`postgres`), on the remote host (192.168.2.24). - -The following lists the current SSH keys files in the BART user’s `.ssh` directory on the BART host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 828 Apr 23 13:40 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:24 known_hosts -``` - -The public key file, `id_rsa.pub`, for BART user account `enterprisedb` on the BART host that was earlier generated in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account), now resides on the remote PostgreSQL host: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub postgres@192.168.2.24:/tmp/tmp.pub -postgres@192.168.2.24's password: -id_rsa.pub -``` - -Log into the `postgres` user account on the remote host and copy the public key file onto the `authorized_keys` file of `postgres` under its `.ssh` directory: - -```text --bash-4.1$ ssh postgres@192.168.2.24 -postgres@192.168.2.24's password: -Last login: Mon Jan 26 18:08:36 2015 from 192.168.2.19 --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys -``` - -Adjust the file permissions on `authorized_keys`: - -```text --bash-4.1$ ls -l .ssh -total 16 --rw-rw-r-- 1 postgres postgres 416 Apr 23 13:52 authorized_keys --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --rw-r--r-- 1 postgres postgres 394 Apr 23 13:36 known_hosts --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 postgres postgres 416 Apr 23 13:52 authorized_keys --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --rw-r--r-- 1 postgres postgres 394 Apr 23 13:36 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -Test the passwordless connection from the BART host to the remote PostgreSQL host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ssh postgres@192.168.2.24 -Last login: Thu Apr 23 13:52:25 2015 from 192.168.2.22 --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - - - -## Configuring a Replication Database User - -This section demonstrates how a replication database user is established. - -**All database servers must use a superuser as the replication database user.** - -The replication database user for each database server is specified by the `user` parameter in the BART configuration file as shown by the following: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb <=== Replication Database User -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" - -[MKTG] -host = 192.168.2.24 -port = 5444 -user = repuser <=== Replication Database User -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" - -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres <=== Replication Database User -cluster_owner = enterprisedb -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -Add entries to the `.pgpass` file on each server to allow the BART user account to initiate a backup without being prompted for credentials. The `.pgpass` file is located in `/opt/PostgresPlus/9.6AS/.pgpass`: - -```text -127.0.0.1:5444:*:enterprisedb:password -192.168.2.24:5444:*:repuser:password -192.168.2.24:5432:*:postgres:password -``` - -For more information about using a `.pgpass` file, please see the [PostgreSQL documentation](https://www.postgresql.org/docs/current/libpq-pgpass.html). - -While connected to `MKTG` on 192.168.2.24, execute the following `CREATE ROLE` command to create the replication database superuser: - -```text -CREATE ROLE repuser WITH LOGIN SUPERUSER PASSWORD 'password'; -``` - -Access is granted in the `pg_hba.conf` file for the local Advanced Server: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 enterprisedb 127.0.0.1/32 md5 -host edb enterprisedb 127.0.0.1/32 md5 -#host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -#local replication enterprisedb md5 -host replication enterprisedb 127.0.0.1/32 md5 -``` - -Similarly, access is granted in the `pg_hba.conf` file for the remote Advanced Server installation: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 repuser 192.168.2.22/32 md5 -host all enterprisedb 127.0.0.1/32 md5 -#host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -#local replication enterprisedb md5 -host replication repuser 192.168.2.22/32 md5 -``` - -Access is also granted in the `pg_hba.conf` file for the remote PostgreSQL server: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 postgres 192.168.2.22/32 md5 -host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -q# replication privilege. -#local replication postgres md5 -host replication postgres 192.168.2.22/32 md5 -``` - - - -## WAL Archiving Configuration Parameters - -Use the following parameters in the `postgresql.conf` file to enable WAL archiving. The `postgresql.conf` file for the local Advanced Server database (`ACCTG`) is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -#archive_command = '' # command to use to archive - a logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set based on the BART `archive_command` parameter located in the BART configuration file. - -!!! Note - If the Postgres `archive_command` is already set, invoke the `INIT` subcommand with the `-- no-configure` option to prevent the `archive_command` from being reset. For details, see [INIT](../bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init/#init). - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -When the `INIT` subcommand is invoked, the `postgresql.auto.conf` file contains the following: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup/acctg/archived_wals/%f' -``` - -The `archive_command` uses the `cp` command instead of `scp` since the BART backup catalog is local to this database cluster and the BART user account (the account that owns the backup catalog, `enterprisedb`), is the same user account running Advanced Server. The result is that there is no directory permission conflict during the archive operation. - -The `postgresql.conf` file for the remote Advanced Server, `MKTG` is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -archive_command = '' # command to use to archive a - logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set by the default BART format of the BART `archive_command` parameter (since it is not explicitly set for this database server in the BART configuration file). - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -. -. -. -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" -``` - -The default BART `archive_command` format is: - -```text -archive_command = 'scp %p %h:%a/%f' -``` - -The `postgresql.auto.conf` file contains the following after the `INIT` subcommand is invoked: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f' -``` - -The `archive_command` uses the `scp` command since the BART backup catalog is remote relative to this database cluster. The BART user account, `enterprisedb`, is specified on the `scp` command since this is the user account owning the BART backup catalog where the archived WAL files are to be copied. The result is that there is no directory permission conflict during the archive operation. - -The `postgresql.conf` file for the remote PostgreSQL server (`HR`) is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -#archive_command = '' # command to use to archive a - logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set by the default BART format of the BART `archive_command` parameter (since it is not explicitly set for this database server in the BART configuration file): - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -. -. -. -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -The default BART `archive_command` format is: - -```text -archive_command = 'scp %p %h:%a/%f' -``` - -The `postgresql.auto.conf` file contains the following after the `INIT` subcommand is invoked: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f' -``` - -The `archive_command` uses the `scp` command since the BART backup catalog is remote relative to this database cluster. The BART user account, `enterprisedb`, is specified on the `scp` command since this is the user account owning the BART backup catalog where the archived WAL files are to be copied. The result is that there is no directory permission conflict during the archive operation. - - - -## Creating the BART Backup Catalog (backup_path) - -Create the directory specified by the `backup_path` configuration parameter. - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -``` - -Ensure that the directory is owned by the BART user account: - -```text -[root@localhost opt]# pwd -/opt -[root@localhost opt]# mkdir backup -[root@localhost opt]# chown enterprisedb backup -[root@localhost opt]# chgrp enterprisedb backup -[root@localhost opt]# chmod 700 backup -[root@localhost opt]# ls -l | grep backup -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 15:36 backup -``` - -Use the BART `INIT` subcommand to complete the directory structure and set the Postgres `archive_command` configuration parameter. - -Before invoking any BART subcommands, set up a profile under the BART user account’s home directory to set the `LD_LIBRARY_PATH` and `PATH` environment variables. For more information regarding setting this variable, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -The `-o` option is specified with the `INIT` subcommand to force the setting of the Postgres `archive_command` configuration parameter when `archive_mode` is `off` or if the Postgres `archive_command` parameter is already set and needs to be overridden. - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ bart INIT -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -INFO: setting archive_command for server 'hr' -WARNING: archive_command is set. server restart is required -INFO: setting archive_command for server 'mktg' -WARNING: archive_command is set. server restart is required -``` - -The BART `SHOW-SERVERS` subcommand displays the following: - -```text --bash-4.1$ bart SHOW-SERVERS -SERVER NAME : acctg -BACKUP FRIENDLY NAME: acctg_%year-%month-%dayT%hour:%minute -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -SERVER NAME : hr -BACKUP FRIENDLY NAME: hr_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : postgres@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Human Resources" -SERVER NAME : mktg -BACKUP FRIENDLY NAME: mktg_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : enterprisedb@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/mktg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Marketing" --bash-4.1$ cd /opt/backup --bash-4.1$ pwd -/opt/backup --bash-4.1$ ls -l -total 12 -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 acctg -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 hr -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 mktg --bash-4.1$ ls -l acctg -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals --bash-4.1$ ls -l hr -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals --bash-4.1$ ls -l mktg -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals -``` - -The `ARCHIVE PATH` field displays the full directory path to where the WAL files are copied. This directory path must match the directory path specified in the Postgres `archive_command` parameter of the `postgresql.conf` file or the `postgresql.auto.conf` file of each database server. - - - -### Starting the Database Servers with WAL Archiving - -After the BART backup catalog directory structure has been configured, start the archiving of WAL files from the database servers by restarting each database server. - -On BART host 192.168.2.22: - -```text -[root@localhost data]# service ppas-9.6 restart -``` - -On remote host 192.168.2.24: - -```text -[root@localhost data]# service ppas-9.6 restart - -[root@localhost data]# service postgresql-9.6 restart -``` - -In the BART backup catalog, verify that the WAL files are archiving. - -Archived WAL files may not appear very frequently depending upon how often WAL archiving is set to switch to a new segment file with the `archive_timeout` parameter in your database server configuration settings. - -Verify that there are no archiving-related errors in the database server log files. - -## Taking a Full Backup - -The following code sample shows the first full backup of the database servers. - -```text --bash-4.1$ bart BACKUP -s acctg -z -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1490809695281' -60776/60776 kB (100%), 1/1 tablespace - -INFO: backup completed successfully -INFO: backup checksum: 37f3defb98ca88dcf05079815555dfc2 of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809695281 -BACKUP NAME: acctg_2017-03-29T13:48 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1490809695281 -BACKUP SIZE: 6.10 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -37f3defb98ca88dcf05079815555dfc2 base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000004 -STOP WAL LOCATION: 000000010000000000000004 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:48:15 EDT -STOP TIME: 2017-03-29 13:48:17 EDT -TOTAL DURATION: 2 sec(s) - --bash-4.1$ bart BACKUP -s mktg -z -INFO: creating backup for server 'mktg' -INFO: backup identifier: '1490809751193' -61016/61016 kB (100%), 1/1 tablespace - -INFO: backup completed successfully -INFO: backup checksum: 8b010e130a105e76d01346bb56dfcf14 of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809751193 -BACKUP NAME: mktg_2017-03-29T13:49 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/mktg/1490809751193 -BACKUP SIZE: 6.13 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -8b010e130a105e76d01346bb56dfcf14 base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000100000085 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:49:11 EDT -STOP TIME: 2017-03-29 13:49:14 EDT -TOTAL DURATION: 3 sec(s) - --bash-4.1$ bart BACKUP -s hr -z -INFO: creating backup for server 'hr' -INFO: backup identifier: '1490809824946' -38991/38991 kB (100%), 1/1 tablespace -INFO: backup completed successfully -INFO: backup checksum: 277e8a1a80ba3474f541eb316a417c9a of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809824946 -BACKUP NAME: hr_2017-03-29T13:50 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/hr/1490809824946 -BACKUP SIZE: 2.59 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -277e8a1a80ba3474f541eb316a417c9a base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000002 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:50:25 EDT -STOP TIME: 2017-03-29 13:50:26 EDT -TOTAL DURATION: 1 sec(s) -``` - -The following code sample shows the backup directories created for each backup of each database server. The backup ID is used as the backup directory name. - -```text --bash-4.1$ cd /opt/backup --bash-4.1$ ls -l -total 12 -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:48 acctg -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:50 hr -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:49 mktg --bash-4.1$ ls -l acctg -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:48 1490809695281 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:48 archived_wals --bash-4.1$ ls -l hr -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:50 1490809824946 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:50 archived_wals --bash-4.1$ ls -l mktg -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:49 1490809751193 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:49 archived_wals -``` - - - -## Using Point-In-Time Recovery - -This section demonstrates using the point-in-time recovery operation on the remote PostgreSQL database server. - -The following tables were created about two minutes apart with WAL archiving enabled: - -```text -postgres=# \dt - - List of relations -Schema | Name | Type | Owner - ---------+----------------+---------+--------- -public | hr_rmt_t1_1356 | table | postgres -public | hr_rmt_t1_1358 | table | postgres -public | hr_rmt_t1_1400 | table | postgres -public | hr_rmt_t1_1402 | table | postgres -public | hr_rmt_t1_1404 | table | postgres -public | hr_rmt_t1_1406 | table | postgres -(6 rows) -``` - -In the table name `hr_rmt_t_, n` represents the active timeline. `` is the approximate time the table was created. For example, `hr_rmt_t1_1356` was created at approximately 1:56 PM while timeline #1 is active. - -The PostgreSQL database server was then stopped. WAL files that have been created, but not yet archived must be identified, and then saved. The following archived WAL files are in the BART backup catalog: - -```text --bash-4.1$ ls -l hr/archived_wals -total 49156 --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 13:50 -000000010000000000000001 --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 13:50 -000000010000000000000002 --rw------- 1 enterprisedb enterprisedb 302 Mar 29 13:50 -000000010000000000000002.00000028.backup --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 14:07 -000000010000000000000003 -``` - -The following sample lists the current PostgreSQL server WAL files. The unarchived WAL files are marked with two stars (\*\*). - -```text --bash-4.1$ cd /opt/PostgreSQL/9.6/data/pg_xlog --bash-4.1$ pwd -/opt/PostgreSQL/9.6/data/pg_xlog --bash-4.1$ ls -l -total 49160 --rw------- 1 postgres postgres 302 Mar 29 13:50 -000000010000000000000002.00000028.backup --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000003 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -**000000010000000000000004** --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -**000000010000000000000005** -drwx------ 2 postgres postgres 4096 Mar 29 14:07 archive_status -``` - -Copies of the unarchived WAL files are saved to a temporary location: - -```text --bash-4.1$ mkdir /tmp/unarchived_pg96_wals --bash-4.1$ pwd -/opt/PostgreSQL/9.6/data/pg_xlog -bash-4.1$ cp -p 000000010000000000000004 /tmp/unarchived_pg96_wals -bash-4.1$ cp -p 000000010000000000000005 /tmp/unarchived_pg96_wals -bash-4.1$ ls -l /tmp/unarchived_pg96_wals -total 32768 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 000000010000000000000005 -``` - -On the remote host, a directory is created to which the PostgreSQL database cluster is to be restored. This restore path is named `/opt/restore_pg96` and is owned by user account `postgres`. - -```text -[user@localhost ~]$ su root -Password: -[root@localhost user]# cd /opt -[root@localhost opt]# mkdir restore_pg96 -[root@localhost opt]# chown postgres restore_pg96 -[root@localhost opt]# chgrp postgres restore_pg96 -[root@localhost opt]# chmod 700 restore_pg96 -[root@localhost opt]# ls -l -total 16 -drwxr-xr-x 4 root daemon 4096 Mar 29 12:10 PostgresPlus -drwxr-xr-x 3 root daemon 4096 Mar 29 12:25 PostgreSQL -drwx------ 2 postgres postgres 4096 Mar 29 14:15 restore_pg96 -drwxr-xr-x. 2 root root 4096 Nov 22 2013 rh -``` - -In the BART configuration file, the remote user and remote host IP address, `postgres@192.168.2.24`, have been set with the `remote_host` parameter. If not given in the BART configuration file, this information must then be specified by the `--remote-host` option when giving the `RESTORE` subcommand (for example, `bart RESTORE --remote-host postgres@192.168.2.24 …`). - -```text -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -Use the `SHOW-BACKUPS` subcommand to identify the backup to use with the `RESTORE` subcommand. - -```text -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME -BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -acctg 1490809695281 acctg_2017-03-29T13:48 none -2017-03-29 13:48:17 EDT -6.10 MB 32.00 MB 2 active -hr 1490809824946 hr_2017-03-29T13:50 none -2017-03-29 13:50:26 EDT -2.59 MB 32.00 MB 2 active -mktg 1490809751193 mktg_2017-03-29T13:49 none -2017-03-29 13:49:14 EDT -6.13 MB 64.00 MB 4 active -``` - -The `-t` option with the `SHOW-BACKUPS` subcommand displays additional backup information: - -```text --bash-4.1$ bart SHOW-BACKUPS -s hr -i 1490809824946 -t -SERVER NAME : hr -BACKUP ID : 1490809824946 -BACKUP NAME : hr_2017-03-29T13:50 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2017-03-29 13:50:26 EDT -BACKUP SIZE : 2.59 MB -WAL(S) SIZE : 32.00 MB -NO. OF WALS : 2 -FIRST WAL FILE : 000000010000000000000002 -CREATION TIME : 2017-03-29 13:50:31 EDT -LAST WAL FILE : 000000010000000000000003 -CREATION TIME : 2017-03-29 14:07:35 EDT -``` - -A recovery is made using timeline `1` to `2017-03-29 14:01:00`. - -```text --bash-4.1$ bart RESTORE -s hr -i hr_2017-03-29T13:50 -p -/opt/restore_pg96 -t 1 -g '2017-03-29 14:01:00' -INFO: restoring backup 'hr_2017-03-29T13:50' of server 'hr' -INFO: base backup restored -INFO: copying WAL file(s) to -postgres@192.168.2.24:/opt/restore_pg96/archived_wals -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: restore completed successfully -``` - -The following example shows the restored backup files in the restore path directory, `/opt/restore_pg96`: - -```text --bash-4.1$ pwd -/opt/restore_pg96 --bash-4.1$ ls -l -total 128 -drwxr-xr-x 2 postgres postgres 4096 Mar 29 14:27 archived_wals --rw------- 1 postgres postgres 206 Mar 29 13:50 backup_label -drwx------ 5 postgres postgres 4096 Mar 29 12:25 base -drwx------ 2 postgres postgres 4096 Mar 29 14:27 global -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_clog -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_commit_ts -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_dynshmem --rw------- 1 postgres postgres 4212 Mar 29 13:18 pg_hba.conf --rw------- 1 postgres postgres 1636 Mar 29 12:25 pg_ident.conf -drwxr-xr-x 2 postgres postgres 4096 Mar 29 13:45 pg_log -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_logical -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_multixact -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_notify -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_replslot -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_serial -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_snapshots -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_stat -drwx------ 2 postgres postgres 4096 Mar 29 13:50 pg_stat_tmp -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_subtrans -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_tblspc -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_twophase --rw------- 1 postgres postgres 4 Mar 29 12:25 PG_VERSION -drwx------ 3 postgres postgres 4096 Mar 29 14:27 pg_xlog --rw------- 1 postgres postgres 169 Mar 29 13:24 postgresql.auto.conf --rw-r--r-- 1 postgres postgres 21458 Mar 29 14:27 postgresql.conf --rw-r--r-- 1 postgres postgres 118 Mar 29 14:27 postgresql.auto.conf -``` - -Copy the saved, unarchived WAL files to the restore path `pg_xlog` subdirectory (`/opt/restore_pg96/pg_xlog`): - -```text --bash-4.1$ pwd -/opt/restore_pg96/pg_xlog --bash-4.1$ ls -l -total 16388 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000002 -drwx------ 2 postgres postgres 4096 Mar 29 14:27 archive_status --bash-4.1$ ls -l /tmp/unarchived_pg96_wals -total 32768 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000005 --bash-4.1$ cp -p /tmp/unarchived_pg96_wals/* . --bash-4.1$ ls -l -total 49156 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000002 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000005 -drwx------ 2 postgres postgres 4096 Mar 29 14:27 archive_status -``` - -Inspect the `/opt/restore_pg96/postgresql.auto.conf` file to verify that it contains the correct recovery settings: - -```text -restore_command = 'cp archived_wals/%f %p' -recovery_target_time = '2017-03-29 14:01:00' -recovery_target_timeline = 1 -``` - -Note that the command restores from the `archived_wals` subdirectory of `/opt/restore_pg96` since the `copy_wals_during_restore` parameter in the BART configuration file is set to `enabled` for database server `hr`. - -Start the database server to initiate the point-in-time recovery operation: - -```text -[user@localhost ~]$ su postgres -Password: -bash-4.1$ cd /opt/restore_pg96 -bash-4.1$ /opt/PostgreSQL/9.6/bin/pg_ctl start -D /opt/restore_pg96 -l -/opt/restore_pg96/pg_log/logfile -server starting -``` - -Inspect the database server log file to ensure the operation did not result in any errors: - -```text -2017-03-29 14:33:23 EDT LOG: database system was interrupted; last known -up at 2017-03-29 13:50:25 EDT -2017-03-29 14:33:23 EDT LOG: starting point-in-time recovery to -2017-03-29 14:01:00-04 -2017-03-29 14:33:23 EDT LOG: restored log file -"000000010000000000000002" from archive -2017-03-29 14:33:23 EDT LOG: redo starts at 0/2000098 -2017-03-29 14:33:23 EDT LOG: consistent recovery state reached at -0/20000C0 -2017-03-29 14:33:23 EDT LOG: restored log file -"000000010000000000000003" from archive -2017-03-29 14:33:23 EDT LOG: recovery stopping before commit of -transaction 1762, time 2017-03-29 14:02:28.100072-04 -2017-03-29 14:33:23 EDT LOG: redo done at 0/303F390 -2017-03-29 14:33:23 EDT LOG: last completed transaction was at log time -2017-03-29 14:00:43.351333-04 -cp: cannot stat `archived_wals/00000002.history': No such file or -directory -2017-03-29 14:33:23 EDT LOG: selected new timeline ID: 2 -cp: cannot stat `archived_wals/00000001.history': No such file or -directory -2017-03-29 14:33:23 EDT LOG: archive recovery complete -2017-03-29 14:33:23 EDT LOG: MultiXact member wraparound protections are -now enabled -2017-03-29 14:33:23 EDT LOG: database system is ready to accept -connections -2017-03-29 14:33:23 EDT LOG: autovacuum launcher started -``` - -The tables that exist in the recovered database cluster are: - -```text -postgres=# \dt - List of relations -Schema | Name | Type | Owner ---------+----------------+-------+---------- -public | hr_rmt_t1_1356 | table | postgres -public | hr_rmt_t1_1358 | table | postgres -public | hr_rmt_t1_1400 | table | postgres -(3 rows) -``` - -Since recovery was up to and including 2017-03-29 14:01:00, the following tables created after 14:01 are not present: - -```text -public | hr_rmt_t1_1402 | table | postgres -public | hr_rmt_t1_1404 | table | postgres -public | hr_rmt_t1_1406 | table | postgres -``` - -The BART `RESTORE` operation stops WAL archiving by adding an `archive_mode = off` parameter at the very end of the `postgresql.conf` file. This last parameter in the file overrides any other previous setting of the same parameter in the file. Delete the last setting and restart the database server to start WAL archiving. - -```text -# Add settings for extensions here -archive_mode = off -``` diff --git a/product_docs/docs/bart/2.6.1/bart_ref/images/EDB_logo.png b/product_docs/docs/bart/2.6.1/bart_ref/images/EDB_logo.png deleted file mode 100755 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.1/bart_ref/images/edb.png b/product_docs/docs/bart/2.6.1/bart_ref/images/edb.png deleted file mode 100755 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.1/bart_ref/images/edb_logo.svg b/product_docs/docs/bart/2.6.1/bart_ref/images/edb_logo.svg deleted file mode 100755 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.1/bart_ref/images/image2.png b/product_docs/docs/bart/2.6.1/bart_ref/images/image2.png deleted file mode 100755 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.6.1/bart_ref/index.mdx b/product_docs/docs/bart/2.6.1/bart_ref/index.mdx deleted file mode 100644 index 6a8817bd039..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_ref/index.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -navTitle: Reference Guide -title: "EDB Postgres Backup and Recovery Reference Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/index.html" ---- - -This guide acts as a quick reference for BART subcommands and provides comprehensive examples of the following BART operations: - -- Performing a full backup of database servers -- Performing a point-in-time recovery (PITR) on a remote PostgreSQL database server -- Restoring an incremental backup -- Restoring a database cluster with tablespaces -- Evaluating, marking, and deleting backups and incremental backups -- Configuring and operating local and remote database servers - -For detailed information about BART subcommands and operations, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The document is organized as follows: - -- See [Subcommands](01_bart_subcommands_examples/#using_bart_subcommands) to view BART subcommand examples. -- See [Examples](02_additional_examples/#examples) to view BART operations examples. -- See [Sample BART System](03_sample_bart_system_with_local_and_remote_database_servers/#a_sample_bart_system_with_local_and_remote_database_servers) to view examples of both local and remote database server configuration and operation. - -
- -bart_subcommands_examples additional_examples sample_bart_system_with_local_and_remote_database_servers conclusion - -
diff --git a/product_docs/docs/bart/2.6.1/bart_user/01_introduction.mdx b/product_docs/docs/bart/2.6.1/bart_user/01_introduction.mdx deleted file mode 100644 index 1212b2847bf..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/01_introduction.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Introduction" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" ---- - -The EDB Backup and Recovery Tool (BART) is an administrative utility that provides simplified backup and recovery management for multiple local or remote EDB Advanced Server and PostgreSQL database servers. - -BART provides the following features: - -- Support for complete, hot, physical backups of multiple Advanced Servers and PostgreSQL database servers -- Support for two types of backups – full base backups and block-level incremental backups -- Backup and recovery management of database servers on local or remote hosts -- A single, centralized catalog for backup data -- Retention policy support for defining and managing how long backups should be kept -- The capability to store the backup data in compressed format -- Verified backup data with checksums -- Backup information displayed in an easy-to-read format -- A simplified point-in-time recovery process - -This guide provides the following information about using BART: - -- an [overview](02_overview/#overview) of the BART components and concepts. -- [backup and recovery management process](03_using_bart/#using_bart). -- [using tablespaces](04_using_tablespaces/#using_tablespaces). - -For information about installing BART, see the *EDB Backup and Recovery Installation and Upgrade Guide*; for examples of BART operations and subcommand usage, see the *EDB Backup and Recovery Reference Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). - - - -## Conventions Used in this Guide - -The following is a list of conventions used throughout this document. - -- Much of the information in this document applies interchangeably to the PostgreSQL and EDB Advanced Server database systems. The term *Advanced Server* is used to refer to EDB Advanced Server. The term *Postgres* is used to generically refer to both PostgreSQL and Advanced Server. When a distinction needs to be made between these two database systems, the specific names, PostgreSQL or Advanced Server are used. - -- The installation directory of the PostgreSQL or Advanced Server products is referred to as `POSTGRES_INSTALL_HOME`: - - - For PostgreSQL Linux installations, this defaults to `/opt/PostgreSQL/` for version 10 and earlier. For later versions, the installation directory is `/var/lib/pgsql/`. - - For Advanced Server Linux installations performed using the interactive installer for version 10 and earlier, this defaults to `/opt/PostgresPlus/AS` or `/opt/edb/as`. For Advanced Server Linux installations performed with an RPM package, this defaults to `/usr/ppas-` or `/usr/edb/as`. For Advanced Server Linux installations performed with an RPM package for version 11 or later, this defaults to `/usr/edb/as`. - -## Restrictions on pg_basebackup - -BART takes full backups using the `pg_basebackup` utility program under the following conditions: - -- The backup is taken on a standby server. -- The `--with-pg_basebackup` option is specified with the `BACKUP` subcommand (see [Backup](03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup)). -- The number of thread count in effect is 1, and the `with-pg_basebackup` option is not specified with the `BACKUP` subcommand. -- Database servers can only be backed up using `pg_basebackup` utility program of the same or later version than the database server version. - -In the global section of the BART configuration file, the `pg_basebackup_path` parameter specifies the complete directory path to the `pg_basebackup` program. For information about the `pg_basebackup_path` parameter and the `thread_count`, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - -For information about `pg_basebackup`, see the [PostgreSQL Core Documentation](https://postgresql.org/docs/current/static/app-pgbasebackup.html). diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx deleted file mode 100644 index a3fe8894d09..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Incremental Backup Limitations and Requirements" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/incremental_backup_limitations_and_requirements.html" ---- - - - -The following limitations apply to incremental backup: - -- If you have restored a full or incremental backup, you must take a full backup before enabling incremental backup. -- If a standby node has been promoted to the role of a primary node, you must take a full backup before enabling incremental backup on the cluster. -- On a standby database server, you cannot take an incremental backup. - -You must meet the following requirements before implementing incremental backup: - -- You must create or select an operating system account to be used as the BART user account. - -- You must create or select the replication database user, which must be a superuser. - -- In the BART configuration file: - - - You must set the `cluster_owner` parameter to the Linux operating system user account that owns the database cluster directory from which incremental backups are to be taken. - - You must enable the `allow_incremental_backups` parameter. - -- A passwordless SSH/SCP connection must be established between the BART user account on the BART host and the `cluster_owner` user account on the database server. - - It must be noted that a passwordless SSH/SCP connection must be established even if BART and the database server are running on the same host and the BART user account and the `cluster_owner` user account are the same account. - -- In addition to the BART host (where the BART backup catalog resides), the BART package must also be installed on every remote database server on which incremental backups are to be restored. To restore an incremental backup, the `bart` program must be executable on the remote host by the remote user (the remote user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup). - -- When [restoring incremental backups on a remote database server](05_restoring_an_incremental_backup/#restoring-an-incremental-backup-on-a-remote-host), a passwordless SSH/SCP connection must be established from the BART user account on the BART host to the remote user on the remote host (the remote user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup). - -- Compression of archived WAL files in the BART backup catalog is not permitted for database servers on which incremental backups are to be taken. The `wal_compression` setting in the BART configuration file must be disabled for those database servers. - -- The incremental backup must be on the same timeline as the parent backup. The timeline changes after each recovery operation so an incremental backup cannot use a parent backup from an earlier timeline. - -For information about configuring these requirements, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -The following section provides an overview of the basic incremental backup concepts. diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx deleted file mode 100644 index 8183d4802bd..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Concept Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/concept_overview.html" ---- - - - -Using incremental backups involves the following sequence of steps: - -1. Configure BART, and enable and initiate archiving of WAL files to the `archive_path` in the same manner as done for full backups. - - The default `archive_path` is the BART backup catalog (`//archived_wals`). Using the `` parameter in the server section of the BART configuration file, you can specify the location where WAL files will be archived. - - For more information about the `archive_path` parameter and configuring BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -2. Take an initial full backup with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. - -3. Scan all WAL files produced by database servers on which incremental backups are to be taken. These WAL files are scanned once they have been archived to the `archive_path`. - - Each scanned WAL file results in a modified block map (MBM) file that records the location of modified blocks obtained from the corresponding WAL file. The BART WAL scanner program `bart-scanner` performs this process. - -4. Take incremental backups using the `BACKUP` subcommand with the `--parent` option to specify the backup identifier or name of a previous, full backup or an incremental backup. Any previous backup may be chosen as the parent as long as all backups belong to the same timeline. - -5. The incremental backup process identifies which WAL files may contain changes from when the parent backup was taken to the starting point of the incremental backup. The corresponding MBM files are used to locate and copy the modified blocks to the incremental backup directory along with other database cluster directories and files. Instead of backing up all, full relation files, only the modified blocks are copied and saved. In addition, the relevant MBM files are condensed into one consolidated block map (CBM) file that is stored with the incremental backup. - - Multiple block copier threads can be used to copy the modified blocks to the incremental backup directory. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting the `thread_count` parameter in the BART configuration file. See [Backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for information about using the `--thread-count` option with the `BACKUP` subcommand. - -6. Invoke the restore process for an incremental backup using the `RESTORE` subcommand in the same manner as restoring a full backup. The `-i` option specifies the backup identifier or name of the incremental backup to restore. The restore process begins by going back through the chain of past, parent incremental backups until the initial full backup starting the chain is identified. This full backup provides the initial set of directories and files to be restored to the location specified with the `-p` option. Each subsequent incremental backup in the chain is then restored. Restoration of an incremental backup uses its CBM file to restore the modified blocks from the incremental backup. - -The following sections provide some additional information on these procedures. diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx deleted file mode 100644 index 5264499e13e..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "WAL Scanning – Preparation for an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/wal_scanning_preparation_for_an_incremental_backup.html" ---- - - - -The WAL scanner program (`bart-scanner`) scans the WAL files created from the time of the parent backup up to the start of the incremental backup to determine which blocks have modified since the parent backup, and records the information in a file called the *modified block map (MBM) file*. One MBM file is created for each WAL file. - -The MBM file is stored in the directory where archived_wals will be stored, as specified in the `archive_path` parameter in the `bart.cfg` file. If the `archive_path` is not specified, the default `archived_wals` directory is: - -`//` - -Where: - -`` is the BART backup catalog parent directory specified in the global section of the BART configuration file. - -`` is the lowercase conversion of the database server name specified in the server section of the BART configuration file. - -The following code snippet is the content of the archive path showing the MBM files created for the WAL files. (The user name and group name of the files have been removed from the example to list the WAL files and MBM files in a more comparable manner): - -```text -[root@localhost archived_wals]# pwd -/opt/backup/acctg/archived_wals -[root@localhost archived_wals]# ls -l -total 131104 --rw------- 1 ... ... 16777216 Oct 12 09:38 000000010000000100000078 --rw------- 1 ... ... 16777216 Oct 12 09:38 000000010000000100000079 --rw------- 1 ... ... 16777216 Oct 12 09:38 00000001000000010000007A --rw------- 1 ... ... 16777216 Oct 12 09:35 00000001000000010000007B --rw------- 1 ... ... 16777216 Oct 12 09:38 00000001000000010000007C --rw------- 1 ... ... 16777216 Oct 12 09:39 00000001000000010000007D --rw------- 1 ... ... 16777216 Oct 12 09:42 00000001000000010000007E --rw------- 1 ... ... 16777216 Oct 12 09:47 00000001000000010000007F --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 0000000100000001780000280000000179000000.mbm --rw-rw-r-- 1 ... ... 684 Oct 12 09:49 000000010000000179000028000000017A000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017A000028000000017B000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017B000028000000017C000000.mbm --rw-rw-r-- 1 ... ...1524 Oct 12 09:49 00000001000000017C000028000000017D000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017D000028000000017E000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017E000028000000017F000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017F0000280000000180000000.mbm -``` - -MBM files have the suffix, `.mbm`. - -In preparation for any incremental backup, the WAL files should be scanned as soon as they are copied to the `archive_path`. Thus, the WAL scanner should be running as soon as the WAL files from the database cluster are archived to the `archive_path`. If the `archive_path` contains WAL files that have not yet been scanned, starting the WAL scanner begins scanning these files. If WAL file fails to be scanned (resulting in a missing MBM file), you can use the WAL scanner to specify an individual WAL file. - -Under certain conditions such as when the Network File System (NFS) is used to copy WAL files to the `archive_path`, the WAL files may have been missed by the WAL scanner program for scanning and creation of MBM files. Use the `scan_interval` parameter in the BART configuration file to initiate force scanning of WAL files in the `archive_path` to ensure MBM files are generated. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about the `scan_interval` parameter. - -See [Running the BART WAL Scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) for information about using the WAL scanner. diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx deleted file mode 100644 index 8198f0f6400..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: "Performing an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_an_incremental_backup.html" ---- - - - -The WAL files produced at the time of the parent backup up to the start of the incremental backup contain information about which blocks were modified during that time interval. That information is consolidated into an MBM file for each WAL file by the WAL scanner. - -The MBM files for the relevant WAL files are read, and the information is used to copy the modified blocks from the database cluster to the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file. When compared to a full backup, the number and sizes of relation files can be significantly less for an incremental backup. - -For comparison, the following is an abbreviated list of the files copied to the archived `base` subdirectory of a full backup for one database: - -```text -[root@localhost 14845]# pwd -/opt/backup/acctg/1476301238969/base/base/14845 -[root@localhost 14845]# ls -112 13182_vm 14740 16467 16615 2608_vm 2655 2699 2995 ... -113 13184 14742 16471 174 2609 2656 2701 2995_vm ... -1247 13186 14745 16473 175 2609_fsm 2657 2702 2996 ... -1247_fsm 13187 14747 16474 2187 2609_vm 2658 2703 2998 ... -1247_vm 13187_fsm 14748 16476 2328 2610 2659 2704 2998_vm ... -1249 13187_vm 14749 16477 2328_fsm 2610_fsm 2660 2753 2999 ... -1249_fsm 13189 14752 16479 2328_vm 2610_vm 2661 2753_fsm 2999_vm ... -1249_vm 13191 14754 16488 2336 2611 2662 2753_vm 3079 ... -1255 13192 14755 16490 2336_vm 2611_vm 2663 2754 3079_fsm ... - . - . - . -13182_fsm 14739 16465 16603 2608_fsm 2654 2696 2893_vm 3501_vm ... -``` - -In contrast, the following is the content of the archived `base` subdirectory of the same database from a subsequent incremental backup: - -```text -[root@localhost 14845]# pwd -/opt/backup/acctg/1476301835391/base/base/14845 -[root@localhost 14845]# ls -1247 1249 1259 16384 17006 2608 2610 2658 2663 2678 ... -1247_fsm 1249_fsm 1259_fsm 16387 17009 2608_fsm 2610_fsm 2659 2673 2679 ... -1247_vm 1249_vm 1259_vm 16389 17011 2608_vm 2610_vm 2662 2674 2703 ... -``` - -The information from the MBM files are consolidated into one file called a *consolidated block map* (CBM) file. During the restore operation for the incremental backup, the CBM file is used to identify the modified blocks to be restored for that backup. In addition, the incremental backup also stores other required subdirectories and files from the database cluster as is done for full backups. - -Before taking an incremental backup, an initial full backup must be taken with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. - -The syntax for taking a full backup is: - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - [ -z ] [ –c ] - [ --backup-name ] - [ --thread-count ] - [ { --with-pg_basebackup | --no-pg_basebackup } ] - [--checksum-algorithm ] -``` - -The syntax for taking an incremental backup is: - -```text -bart BACKUP –s { | all } [ -F p] - [ --parent { | } ] - [ --backup-name ] - [ --thread-count ] - [ --check ] - [--checksum-algorithm ] -``` - -You must specify the following before taking an incremental backup: - -- `-Fp` option for plain text format as incremental backup can only be taken in the plain text format. -- `--check` option to verify if the required MBM files are present in the `archived_wals` directory. The `--parent` option must be specified when the `--check` option is used. - -See [BACKUP](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for more information about using the `BACKUP` subcommand. diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx deleted file mode 100644 index b3dcf583e31..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Restoring an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restoring_an_incremental_backup.html" ---- - - - -Restoring an incremental backup may require additional steps depending upon the host on which the incremental backup is to be restored: - -- [Restoring an Incremental Backup on a BART Host](#restoring-an-incremental-backup-on-a-bart-host) - This section outlines restoring an incremental backup onto the same host where BART has been installed. -- [Restoring an Incremental Backup on a Remote Host](#restoring-an-incremental-backup-on-a-remote-host) - This section outlines restoring an incremental backup onto a remote host where BART has not been installed. - - - -## Restoring an Incremental Backup on a BART Host - -Specify a backup identifier or name, and include the `-i` option when invoking the `RESTORE` subcommand to restore an incremental backup. All `RESTORE` options may be used in the same manner as when restoring a full backup. See [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) command for more details. - -First, all files from the full backup from the beginning of the backup chain are restored. For each incremental backup, the CBM file is used to identify and restore blocks from the incremental backup. If there are new relations or databases identified in the CBM file, then relevant relation files are copied. If consolidated block map information is found indicating the drop of a relation or a database, then the relevant files are removed from the restore directory. Similarly, if there is any indication of a table truncation, then the related files are truncated. - -Also note that you can use the `-w` option of the `RESTORE` subcommand to specify a multiple number of parallel worker processes to stream the modified blocks to the restore host. - -!!! Note - If you set the [BART scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or [backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) with the `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring an incremental backup. - - - -## Restoring an Incremental Backup on a Remote Host - -Ensure the `bart` program is available on the remote host when restoring an incremental backup on a remote host; the invocation of the `RESTORE` subcommand for an incremental backup results in the execution of the `bart` program on the remote host to restore the modified blocks to their proper location. - -To restore an incremental backup onto a remote host where BART has not been installed, perform the following steps: - -**Step 1:** Install `BART` on the remote host to which an incremental backup is to be restored. - -No editing is needed in the `bart.cfg` file installed on the remote host. - -**Step 2:** Determine the Linux operating system user account on the remote host to be used as the remote user. This user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup. The remote user must be the owner of the directory where the incremental backup is to be restored on the remote host. By default, the user account is `enterprisedb` for Advanced Server or `postgres` for PostgreSQL. - -**Step 3:** Ensure a passwordless SSH/SCP connection is established from the BART user on the BART host to the remote user on the remote host. For information about creating a passwordless SSH/SCP connection, see the *EDB Backup and Recovery Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - -When restoring an incremental backup, specify the backup identifier or name of the incremental backup that will be restored. See the [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) documentation for more details. To view an example of restoring an incremental backup, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -!!! Note - If you set the [BART scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or [backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) with the `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring an incremental backup. diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/index.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/index.mdx deleted file mode 100644 index 3e65e3b0056..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/01_block-level_incremental_backup/index.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Block-Level Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/block-level_incremental_backup.html" ---- - - - -This section describes the basic concepts of a block-level incremental backup (referred to as an incremental backup). An incremental backup is a unique functionality of BART. - -An incremental backup provides a number of advantages when compared to using a full backup: - -- The amount of time required to produce an incremental backup is generally less than a full backup, as modified relation blocks are saved instead of all full relation files of the database cluster. -- An incremental backup uses less disk space than a full backup. - -Generally, all BART features (such as retention policy management) apply to incremental backups and full backups. See [Managing Incremental Backups](../../03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups/#managing_incremental_backups) for more information. - -
- -incremental_backup_limitations_and_requirements concept_overview wal_scanning_preparation_for_an_incremental_backup performing_an_incremental_backup restoring_an_incremental_backup - -
diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/02_creating_a_backup_chain.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/02_creating_a_backup_chain.mdx deleted file mode 100644 index 644040d87f1..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/02_creating_a_backup_chain.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Creating a Backup Chain" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/creating_a_backup_chain.html" ---- - - - -A *backup chain* is the set of backups consisting of a full backup and all of its successive incremental backups. Tracing back on the parent backups of all incremental backups in the chain eventually leads back to that single, full backup. - -It is possible to have a *multi-forked* backup chain, which is two or more successive lines of incremental backups, all of which begin with the same, full backup. Thus, within the chain there is a backup that serves as the parent of more than one incremental backup. - -Since restoration of an incremental backup is dependent upon first restoring the full backup, then all successive incremental backups up to, and including the incremental backup specified by the `RESTORE` subcommand, it is crucial to note the following: - -- Deletion or corruption of the full backup destroys the entire backup chain. It is not possible to restore any of the incremental backups that were part of that chain. -- Deletion or corruption of an incremental backup within the chain results in the inability to restore any incremental backup that was added to that successive line of backups following the deleted or corrupted backup. The full backup and incremental backups prior to the deleted or corrupted backup can still be restored. - -The actions of retention policy management are applied to the full backup and all of its successive incremental backups within the chain in an identical manner as if they were one backup. Thus, use of retention policy management does not result in the breakup of a backup chain. - -See the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/) for examples of creating a backup chain and restoring an incremental backup. diff --git a/product_docs/docs/bart/2.6.1/bart_user/02_overview/index.mdx b/product_docs/docs/bart/2.6.1/bart_user/02_overview/index.mdx deleted file mode 100644 index 7b5b7e92fb3..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/02_overview/index.mdx +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: "Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview.html" ---- - - - -BART provides a simplified interface for the continuous archiving and point-in-time recovery method provided with Postgres database servers. This consists of the following processes: - -- Capturing a complete image of a database cluster as a full base backup or referred to simply as a *full backup*. -- Capturing a modified image of a database cluster called a *block-level incremental backup* or referred as *incremental backup*, which is similar to a full backup, but contains the modified blocks of the relation files that have been changed since a previous backup. -- Archiving the `Write-Ahead Log segments` (WAL files), which continuously record changes to be made to the database files. -- Performing *Point-In-Time Recovery* (PITR) to a specified transaction ID or timestamp with respect to a timeline using a full backup along with successive, [block-level incremental backups](01_block-level_incremental_backup/#block-level_incremental_backup) that reside in the same backup chain, and the WAL files. - -Detailed information regarding WAL files and point-in-time recovery is documented in the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). - -The general term *backup* refers to both full backups and incremental backups. - -When taking a full backup of a standby server, BART uses the PostgreSQL `pg_basebackup` utility program. However, it must be noted that for standby servers, you can only take a full backup, but cannot take an incremental or parallel backups. For information about standby servers, see the [PostgreSQL Documentation](https://www.postgresql.org/docs/current/static/high-availability.html). - -BART uses a centralized backup catalog, a single configuration file, and a command line interface controlling the necessary operations to simplify the management process. Reasonable defaults are automatically used for various backup and restore options. BART also performs the necessary recovery file configuration required for point-in-time recovery using its command line interface. - -BART also provides the following features to enhance backup management: - -- Automation of the WAL archiving command configuration. -- Usage of retention policies to evaluate, categorize, and delete obsolete backups. -- Compression of WAL files to conserve disk space. -- Customizable naming of backups to ease their usage. -- Easy access to comprehensive information about each backup. - -The key components of a BART installation are: - -- **BART Host.** The host system on which BART is installed. BART operations are invoked from this host system. The database server backups and archived WAL files are stored on this host as well. -- **BART User Account.** Linux operating system user account you choose to run BART. The BART user account owns the BART backup catalog directory. -- **BART Configuration File.** File in editable text format containing the configuration information that BART uses. -- **BART Backup Catalog.** File system directory structure containing all of the backups for the database servers that BART manages. It is also the default `archive_path` to store archived WAL files. -- **BART Backupinfo File.** File in text format containing information for a BART backup. A `backupinfo` file resides in each backup subdirectory within the BART backup catalog. -- **BART Command Line Utility Program.** Single, executable file named `bart`, which is used to manage all BART operations. -- **BART WAL Scanner Program.** Single, executable file named `bart-scanner`, which is used to scan WAL files to locate and record the modified blocks for incremental backups. - -Other concepts and terms referred to in this document include the following: - -- **Postgres Database Cluster.** Also commonly called the *data directory*, this is the file system directory where all of the data files related to a particular Postgres database server instance are stored. (Each specific running instance is identified by its host and port number when connecting to a database.) The database cluster is identified by the `–D` option when it is created, started, stopped, etc. by the `Postgres initdb` and `pg_ctl` commands. A full backup is a copy of a database cluster. - - The terms database cluster and database server are used somewhat interchangeably throughout this document, though a single database server can run multiple database clusters. - -- **Postgres User Account.** Linux operating system user account that runs the Advanced Server or PostgreSQL database server and owns the database cluster directory. - - - By default, the database user account is `enterprisedb` when Advanced Server is installed to support compatibility with Oracle databases. - - - By default, the database user account is `postgres` when Advanced Server is installed in PostgreSQL compatible mode. For a PostgreSQL database server, the default database user account is also `postgres`. - - The BART configuration parameter `cluster_owner` must be set to the database user account for each database server. - -- **Replication Database User.** For each database server that BART manages, a database superuser must be selected to act as the replication database user. This database user is used to connect to the database server when backups are taken. The database superusers created with an initial Postgres database server installation (`enterprisedb` or `postgres`) may be used for this purpose. The BART configuration parameter `user` must be set to this replication database user for each database server. - -- **Secure Shell (SSH)/Secure Copy (SCP).** Linux utility programs used to log into hosts (SSH) and copy files (SCP) between hosts. A valid user account must be specified that exists on the target host and in fact is the user account under which the SSH or SCP operations occur. - -For information on how all of these components are configured and used with BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -**Supported BART Operations** - -The following tables are not a conclusive list of the scenarios supported by BART, but instead provides an overview of some of the most common scenarios in both `pg_basebackup` (thread count=1) as well as parallel backup mode (thread count greater than 1). - -| | -Fp-xlog-method=fetch | -Fp-xlog-method=stream | -Ft-xlog-method=fetch | -Ft-xlog-method=stream | -| -------------------------------------------- | --------------------- | ---------------------- | --------------------- | ---------------------- | -| `Primary Database Server/Full backup` | Supported | Supported | Supported | Supported | -| `Primary Database Server/Incremental backup` | Supported | Supported | Not Supported | Not Supported | -| `Standby Database Server/Full backup` | Supported | Supported | Supported | Supported | -| `Standby Database Server/Incremental backup` | Not Supported | Not Supported | Not Supported | Not Supported | - -Backup - -| | Wal compression by BART | WAL scanner | -| -------------------------------------------- | ----------------------- | ----------- | -| `Primary Database Server/Full backup` | Supported | N/A | -| `Primary Database Server/Incremental backup` | Not Supported | N/A | -| `Standby Database Server/Full backup` | Supported | N/A | -| `Standby Database Server/Incremental backup` | Not Supported | N/A | - -Wal Archiving - -| | Wal compression = enabled | Wal compression = disabled | -| ------------------ | ------------------------- | -------------------------- | -| `Restore` | Supported | Supported | -| `Parallel restore` | Supported | Supported | - -Restore - -
- -block-level_incremental_backup creating_a_backup_chain - -
diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx deleted file mode 100644 index 06edb0b5afb..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Performing a Restore Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_a_restore_operation.html" ---- - - - -The following steps describe the process of restoring a backup: - -**Step 1:** Use your system-specific command to shut down the database server. - -**Step 2:** Inspect the `pg_wal` subdirectory (inspect the `pg_xlog` subdirectory if you are using server 9.6 version) of the data directory and save any WAL files that have not yet been archived to the `archive_path`. If there are files that have not been archived, save them to a temporary location. - -**Step 3:** If you want to restore to current data directory, it is recommended to make a copy of the current data directory and then delete all files and subdirectories under the data directory if you have enough extra space. If there is not enough space, then make a copy of `pg_wal` directory (or `pg_xlog` if you are using server 9.6 version) until the server is successfully restored. - -If you want to restore to a new, empty directory, create the directory on which you want to restore the backed up database cluster. Ensure the data directory can be written to by the BART user account or by the user account specified by the `remote_host` configuration parameter, or by the `--remote-host` option of the `RESTORE` subcommand (if these are to be used). - -**Step 4:** Perform the same process for tablespaces as described in Step 3. The `tablespace_path` parameter in the BART configuration file must contain the tablespace directory paths to which the tablespace data files are to be restored. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about this parameter. - -**Step 5:** Identify the backup to use for the restore operation and obtain the backup ID or backup name. - -To use the latest backup, omit the `-i` option; the `RESTORE` subcommand uses that backup by default. The backups can be listed with the `SHOW-BACKUPS` subcommand. - -**Step 6:** Run the BART `RESTORE` subcommand. - -- Minimal recovery settings will be saved in the `postgresql.auto.conf` file and archive recovery will proceed only until consistency is reached, with no restoration of files from the archive. See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for detailed information about `Restore` subcommand. - -- If the `-c` option is specified or if the `copy_wals_during_restore` BART configuration parameter is enabled for this database server, then the following actions occur: - - - In addition to restoring the database cluster to the directory specified by the `-p restore_path` option, the archived WAL files of the backup are copied from the BART backup catalog to the subdirectory `restore_path/archived_wals`. - - If recovery settings are saved in the `postgresql.auto.conf` file, the command string set in the `restore_command` parameter retrieves the WAL files from this `archived_wals` subdirectory relative to the `restore_path` parent directory as: `restore_command = cp archived_wals/%f %p` - -You must ensure that valid options are specified when using the `RESTORE` subcommand. BART will not generate an error message if invalid option values or invalid option combinations are provided. BART will accept the invalid options and pass them to the `postgresql.auto.conf` file, which will then be processed by the database server when it is restarted. - -**Step 7:** Copy any saved WAL files from Step 2 to the `restore_path/pg_xlog` subdirectory. - -**Step 8:** Inspect the restored directories and data files of the restored database cluster in directory `restore_path`. - -All files and directories must be owned by the user account that you intend to use to start the database server. Recursively change the user and group ownership of the `restore_path` directory, its files, and its subdirectories if necessary. There must only be directory access privileges for the user account that will start the database server. No other groups or users can have access to the directory. - -**Step 9:** The `postgresql.auto.conf` file should be configured to recover only until the cluster reaches consistency. In either case, the settings may be modified as desired. - -**Step 10:** Disable WAL archiving at this point. The BART `RESTORE` subcommand adds `archive_mode = off` to the end of the `postgresql.conf` file. - -- If you want to restart the database server with WAL archiving enabled, ensure that this additional parameter is deleted. -- The original `archive_mode` parameter still resides in the `postgresql.conf` file in its initial location with its last setting. - -**Step 11:** Start the database server to initiate recovery. After completion, check the database server log file to ensure the recovery was successful. - -If the backup is restored to a different location than where the original database cluster resided, operations dependent upon the database cluster location may fail if supporting service scripts are not updated to reflect the location where the backup has been restored. For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). - -See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the BART `Restore` subcommand. - -An example of a restore operation is documented in the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/). - -!!! Note - If you set the [backup](../03_basic_bart_subcommand_usage/03_backup/#backup) `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring a backup. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx deleted file mode 100644 index 5d85c80281b..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Point-In-Time Recovery Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/point_in_time_recovery_operation.html" ---- - - - -The following steps outline how to perform a point-in-time recovery operation for a database cluster: - -1. Use your system-specific command to shut down the database server. - -2. If you want to: - a. restore the database cluster and tablespace files to new, empty directories, create the new directories with the appropriate directory ownership and permissions. - b. reuse the existing database cluster directories, delete all the files and subdirectories in the existing directories. We strongly recommend that you make a copy of this data before deleting it. Be sure to save any recent WAL files in the `pg_wal` subdirectory ( `pg_xlog` subdirectory if you are using server 9.6 version) that have not been archived to `archive_path`. - -3. Run the BART `SHOW-BACKUPS -s ` subcommand to list the backup IDs and backup names of the backups for the database server. You will need to provide the appropriate backup ID or backup name with the BART `RESTORE` subcommand, unless you intend to restore the latest backup in which case the `-i` option of the `RESTORE` subcommand for specifying the backup ID or backup name may be omitted. - -4. Run the BART `RESTORE` subcommand with the appropriate options. - - - The backup is restored to the directory specified by the `-p restore_path` option. - - - In addition, if the `RESTORE` subcommand `-c` option is specified or if the enabled setting of the `copy_wals_during_restore` BART configuration parameter is applicable to the database server, then the required archived WAL files from the `archive_path` are copied to the `restore_path/archived_wals` subdirectory. - - - Ensure the `restore_path` directory and all subdirectories and files in the `restore_path` are owned by the proper Postgres user account (for example, `enterprisedb` or `postgres`). Also ensure that only the Postgres user account has access permission to the `restore_path` directory. - - Use the `chown` command to make the appropriate adjustments to file permissions; for example, the following command changes the ownership of `restore_path` to `enterprisedb`: - - `chown -R enterprisedb:enterprisedb restore_path` - - The following command restricts access to `restore_path`: - - `chmod 700 restore_path` - -5. Copy any saved WAL files from Step 2 that were not archived to the BART backup catalog to the `restore_path/pg_wal` subdirectory (`pg_xlog` subdirectory if you are using server 9.6 version). - -6. Identify the timeline ID you wish to use to perform the restore operation. - - The available timeline IDs can be identified by the first non-zero digit of the WAL file names reading from left to right. - -7. Verify that the `postgresql.auto.conf` file created in the directory specified with the `RESTORE` subcommand’s `-p ` option was generated with the correct recovery parameter settings. - - If the `RESTORE` subcommand `-c` option is specified or if the enabled setting of the `copy_wals_during_restore` BART configuration parameter is applicable to the database server, then the `restore_command` parameter retrieves the archived WAL files from the `/archived_wals` subdirectory that was created by the `RESTORE` subcommand, otherwise the `restore_command` retrieves the archived WAL files from the BART backup catalog. - -8. The BART `RESTORE` subcommand disables WAL archiving in the restored database cluster. If you want to immediately enable WAL archiving, modify the `postgresql.conf` file by deleting the `archive_mode = off` parameter that BART appends to the end of the file. - -9. Start the database server, which will then perform the point-in-time recovery operation if recovery settings are saved in the `postgresql.auto.conf` file. - -For a detailed description of the `RESTORE` subcommand, see [Basic BART Subcommand Usage](../03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage). An example of a Point-in-Time Recovery operation is documented in the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the `Restore` subcommand. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/index.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/index.mdx deleted file mode 100644 index 4cb9c779397..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/01_bart_management_overview/index.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "BART Management Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/bart_management_overview.html" ---- - - - -After configuring BART, you can begin the backup and recovery management process. The following steps will help you get started: - -1. Run the `CHECK-CONFIG` subcommand without the `-s` option. When the `CHECK-CONFIG` subcommand is used without specifying the `-s` option, it checks the parameters in the global section of the BART configuration file. -2. Run the `INIT` subcommand (if you have not already done so) to finish creation of the BART backup catalog, which results in the complete directory structure to which backups and WAL files are saved. This step must be done before restarting the database servers with enabled WAL archiving, otherwise the copy operation in the `archive_command` parameter of the `postgresql.conf` file or the `postgresql.auto.conf` file fails due to the absence of the target archive directory. When the directory structure is complete, the `archived_wals` subdirectory should exist for each database server. -3. Start the Postgres database servers with archiving enabled. Verify that the WAL files are appearing in the `archive_path`. The archiving frequency is dependent upon other `postgresql.conf` configuration parameters. Check the Postgres database server log files to ensure there are no archiving errors. Archiving should be operational before taking a backup in order to ensure that the WAL files that may be created during the backup process are archived. -4. Start the WAL scanner if you intend to take incremental backups. Since the WAL scanner processes the WAL files copied to the `archive path`, it is advantageous to commence the WAL scanning as soon as the WAL files begin to appear in the `archive_path` in order to keep the scanning in pace with the WAL archiving. -5. Run the BART `CHECK-CONFIG` subcommand for each database server with the `-s` option specifying the server name. This ensures the database server is properly configured for taking backups. -6. Create a full backup for each database server. The full backup establishes the starting point of when point-in-time recovery can begin and also establishes the initial parent backup for any incremental backups to be taken. - -There are now a number of other BART management processes you may perform: - -- Execute the `BACKUP` subcommand to create additional full backups or incremental backups. -- Use the `VERIFY-CHKSUM` subcommand to verify the checksum of the full backups. -- Display database server information with the `SHOW-SERVERS` subcommand. -- Display backup information with the `SHOW-BACKUPS` subcommand. -- Compress the archived WAL files in the `archive_path` by enabling WAL compression in the BART configuration file and then invoking the `MANAGE` subcommand. -- Determine and set the retention policy for backups in the BART configuration file. -- Establish the procedure for using the `MANAGE` subcommand to enforce the retention policy for backups. This may include using `cron` jobs to schedule the `MANAGE` subcommand. - -
- -performing_a_restore_operation point_in_time_recovery_operation - -
diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx deleted file mode 100644 index 7169d6f7bb6..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Overview - Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview_managing_backups_using_a_retention_policy.html" ---- - - - -The BART retention policy results in the categorization of each backup in one of three statuses – *active*, *obsolete*, and *keep*. - -- **Active.** The backup satisfies the retention policy applicable to its server. Such backups would be considered necessary to ensure the recovery safety for the server and thus should be retained. -- **Obsolete.** The backup does not satisfy the retention policy applicable to its server. The backup is no longer considered necessary for the recovery safety of the server and thus can be deleted. -- **Keep.** The backup is to be retained regardless of the retention policy applicable to its server. The backup is considered vital to the recovery safety for the server and thus should not be deleted for an indefinite period of time. - -There are two types of retention policies - redundancy retention policy and recovery window retention policy. - -- **Redundancy Retention Policy** - The [redundancy retention policy](03_setting_the_retention_policy/#redundancy-retention-policy) relies on a specified, maximum number of most recent backups to retain for a given server. When the number of backups exceeds that maximum number, the oldest backups are considered obsolete (except for backups marked as keep). -- **Recovery Window Retention Policy** - The [recovery window retention policy](03_setting_the_retention_policy/#recovery-window-retention-policy) relies on a time frame (the recovery window) for when a backup should be considered active. The boundaries defining the recovery window are the current date/time (the ending boundary of the recovery window) and the date/time going back in the past for a specified length of time (the starting boundary of the recovery window). - - If the date/time the backup was taken is within the recovery window (that is, the backup date/time is on or after the starting date/time of the recovery window), then the backup is considered active, otherwise it is considered obsolete (except for backups marked as keep). - - Thus, for the recovery window retention policy, the recovery window time frame dynamically shifts, so the end of the recovery window is always the current date/time when the `MANAGE` subcommand is run. As you run the `MANAGE` subcommand at future points in time, the starting boundary of the recovery window moves forward in time. At some future point, the date/time of when a backup was taken will be earlier than the starting boundary of the recovery window. This is when an active backup’s status will be considered obsolete. - - You can see the starting boundary of the recovery window at any point in time by running the `SHOW-SERVERS` subcommand. The `RETENTION POLICY` field of the `SHOW-SERVERS` subcommand displays the starting boundary of the recovery window. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx deleted file mode 100644 index 047552d0a9e..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Marking the Backup Status" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/marking_the_backup_status.html" ---- - - - -When a backup is initially created with the `BACKUP` subcommand, it is always recorded with active status. Use the `MANAGE` subcommand to evaluate if the backup status should be changed to obsolete in accordance with the retention policy. You can review the current status of your backups with the `SHOW-BACKUPS` subcommand. - -Active backups are evaluated and also marked (that is, internally recorded by BART) as obsolete only when the `MANAGE` subcommand is invoked either with no options or with only the `-s` option. - -Once a backup has been marked as obsolete, you cannot change it back to active unless you perform the following steps: - -- Use the `MANAGE` subcommand with the `-c` option along with the backup identifier or name with the `-i` option. To keep this particular backup indefinitely, use `-c keep`, otherwise use `-c nokeep`. -- If you use the `-c nokeep` option, the backup status is changed back to active. When the `MANAGE` subcommand is used the next time, the backup is re-evaluated to determine if its status needs to be changed back to obsolete based on the current retention policy in the BART configuration file. - -After setting the `retention_policy` parameter and running the `MANAGE` subcommand if you change the `retention_policy` parameter, the current, marked status of the backups are probably inconsistent with the new `retention_policy` setting. To modify the backup status to be consistent with the new `retention_policy` setting, you need to run the `MANAGE` subcommand with: - -- the `-c nokeep` option to change the obsolete status to active status if there are backups currently marked as obsolete that would no longer be considered obsolete under a new retention policy. You can also specify the `-i all` option to change all backups back to active status, including those currently marked as keep. -- no options or with only the `-s` option to reset the marked status based on the new `retention_policy` setting in the BART configuration file. - -See [MANAGE](../03_basic_bart_subcommand_usage/07_manage/#manage) for usage information for the `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx deleted file mode 100644 index a4396239bfe..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "Setting the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/setting_the_retention_policy.html" ---- - - - -The retention policy is determined by the `retention_policy` parameter in the BART configuration file. It can be applied globally to all servers, but each server can override the global retention policy with its own. For information about creating a global retention policy and an individual database server retention policy, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -There are two types of retention policies - redundancy retention policy and the recovery window retention policy as described in the following sections. - - - -## Redundancy Retention Policy - -To use the redundancy retention policy, set `retention_policy = max_number BACKUPS` where `max_number` is a positive integer designating the maximum number of most recent backups. - -**Additional Restrictions:** - -- The keyword `BACKUPS` must always be specified in plural form (for example, `1 BACKUPS`). -- BART will accept a maximum integer value of 2,147,483,647 for `max_number`; however, you should use a realistic, practical value based on your system environment. - -The redundancy retention policy is the default type of retention policy if all keywords `BACKUPS`, `DAYS`, `WEEKS`, and `MONTHS` following the `max_number` integer are omitted as shown by the following example: - -`retention_policy = 3` - -In the following example, the redundancy retention policy setting considers the three most recent backups as the active backups. Any older backups, except those marked as `keep`, are considered obsolete: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The `SHOW-SERVERS` subcommand displays the `3 Backups` redundancy retention policy in the `RETENTION POLICY` field: - -```bash --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 3 Backups -DISK UTILIZATION : 627.04 MB -NUMBER OF ARCHIVES : 25 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/acctg/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Accounting" -``` - - - -## Recovery Window Retention Policy - -To use the recovery window retention policy, set the `retention_policy` parameter to the desired length of time for the recovery window in one of the following ways: - -- Set to `max_number DAYS` to define the start date/time recovery window boundary as the number of days specified by `max_number` going back in time from the current date/time. -- Set to `max_number WEEKS` to define the start date/time recovery window boundary as the number of weeks specified by `max_number` going back in time from the current date/time. -- Set to `max_number MONTHS` to define the start date/time recovery window boundary as the number of months specified by `max_number` going back in time from the current date/time. - -**Additional Restrictions:** - -- The keywords `DAYS`, `WEEKS`, and `MONTHS` must always be specified in plural form (for example, `1 DAYS`, `1 WEEKS`, or `1 MONTHS`). -- BART will accept a maximum integer value of `2,147,483,647` for `max_number`, however, a realistic, practical value based on your system environment must always be used. - -A backup is considered active if the date/time of the backup is equal to or greater than the start of the recovery window date/time. - -You can view the actual, calculated recovery window by: - -- Invoking the `MANAGE` subcommand in debug mode, along with the `-n` option. -- Using the `SHOW-SERVERS` subcommand. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx deleted file mode 100644 index def779a4026..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: "Managing the Backups Based on the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_the_backups_based_on_the_retention_policy.html" ---- - - - -The [MANAGE](../03_basic_bart_subcommand_usage/07_manage/#manage) subcommand is used to evaluate and categorize backups according to the retention policy set in the BART configuration file. When a backup is first created with the `BACKUP` subcommand, it is `active`. You can use the `MANAGE` subcommand to change the status of an active backup to `obsolete`. Obsolete backups can then be deleted. - -This section covers following aspects of backup management: - -- The rules for [deleting backups](#deletions_permitted_under_retention_policy) depending upon the backup status and the subcommand used. -- The process to retain a backup indefinitely by [marking it as keep](#marking-backups-for-indefinite-keep-status). This section also provides information about resetting backups status (that are marked as `obsolete` and `keep`) back to active status. -- The general process for [evaluating, marking, and then deleting obsolete backups](#evaluating-marking-and-deleting-obsolete-backups). - - - -## Deletions Permitted Under a Retention Policy - -This section describes how and under what conditions backups may be deleted under a retention policy. - -You must use the `MANAGE` subcommand to delete obsolete backups. Use the `DELETE` subcommand only for special administrative purposes. - -The deletion behavior of the `MANAGE` subcommand and the `DELETE` subcommand are based on different aspects of the retention policy. - -- The `MANAGE` subcommand deletion relies solely upon how a backup status is currently marked (that is, internally recorded by BART). The current setting of the `retention_policy` parameter in the BART configuration file is ignored. -- The `DELETE` subcommand relies solely upon the current setting of the `retention_policy` parameter in the BART configuration file. The current active, obsolete, or keep status of a backup is ignored. - -The specific deletion rules for the `MANAGE` and `DELETE` subcommands are as follows: - -- `MANAGE` subcommand: The `MANAGE` subcommand with the `-d` option can only delete backups marked as obsolete. This deletion occurs regardless of the current `retention_policy` setting in the BART configuration file. The deletion of backups relies on the last occasion when the backups have been marked. -- `DELETE` subcommand: - - - Under a redundancy retention policy currently set with the `retention_policy` parameter in the BART configuration file, any backup regardless of its marked status, can be deleted with the `DELETE` subcommand when the backup identifier or name is specified with the `-i` option and if the current total number of backups for the specified database server is greater than the maximum number of redundancy backups currently specified with the `retention_policy` parameter. - - If the total number of backups is less than or equal to the specified, maximum number of redundancy backups, then no additional backups can be deleted using `DELETE` with the `-i backup` option. - - - Under a recovery window retention policy currently set with the `retention_policy` parameter in the BART configuration file, any backup regardless of its marked status, can be deleted with the `DELETE` subcommand when the backup identifier or name is specified with the `-i` option, and if the backup date/time is not within the recovery window currently specified with the `retention_policy` parameter. If the backup date/time is within the recovery window, then it cannot be deleted using `DELETE` with the `-i backup` option. - - - Invoking the `DELETE` subcommand with the `-i all` option results in the deletion of all backups regardless of the retention policy and regardless of whether the status is marked as active, obsolete, or keep. - -The following table summarizes the deletion rules of backups according to their marked status. An entry of `Yes` indicates the backup may be deleted under the specified circumstances. An entry of `No` indicates that the backup may not be deleted. - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OperationRedundancy Retention PolicyRecovery Window Retention Policy
ActiveObsoleteKeepActiveObsoleteKeep
MANAGE –dNoYesNoNoYesNo
DELETE –i *backup* -

Yes

-

(see Note 1)

- 		-

Yes

-

(see Note 1)

- 		-

Yes

-

(see Note 1_)

- 		-

Yes

-

(see Note 2

- 		-

Yes

(see Note 2 - 		-

Yes

(see Note 2) -
DELETE –i allYesYesYesYesYesYes
- - - -!!! Note - Redundancy Retention Policy (Note 1) : Deletion occurs only if the total number of backups for the specified database server is greater than the specified, maximum number of redundancy backups currently set with the `redundancy_policy` parameter in the BART configuration file. - - - -!!! Note - Recovery Window Retention Policy (Note 2): Deletion occurs only if the backup is not within the recovery window currently set with the `redundancy_policy` parameter in the BART configuration file. - - - -## Marking Backups for Indefinite Keep Status - -There may be certain backups that you wish to keep for an indefinite period of time and do not wish to delete based upon the retention policy applied to the database server. Such backups can be marked as `keep` to exclude them from being marked as obsolete. Use the `MANAGE` subcommand with the `-c keep` option to retain such backups indefinitely. - - - -## Evaluating, Marking, and Deleting Obsolete Backups - -When the `MANAGE` subcommand is invoked, BART evaluates active backups: - -- If you include the `-s` option when invoking the `MANAGE` subcommand, BART evaluates backups for the database server. -- If you include the `-s all` option when invoking the `MANAGE` subcommand, BART evaluates backups for all database servers. -- If the `-s` option is omitted, the command evaluates the current number of backups for the database server based on the redundancy retention policy or the current date/time for a recovery window retention policy. - -!!! Note - The status of backups currently marked as `obsolete` or `keep` is not changed. To re-evaluate such backups and then classify them, their status must first be reset to `active` with the `MANAGE -c nokeep` option. See [Marking the Backup Status](02_marking_the_backup_status/#marking_the_backup_status) for more information. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) to review examples of how to evaluate, mark, and delete backups using a redundancy retention policy and recovery window retention policy, as well as examples of `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx deleted file mode 100644 index c69f6b09086..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Managing Incremental Backups" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_incremental_backups.html" ---- - - - -The following section summarizes how retention policy management affects incremental backups. - -- The retention policy rules are applied to full backups. - - A redundancy retention policy uses the number of full backups to determine if a backup is obsolete. Incremental backups are excluded from the comparison count against the `retention_policy` setting for the maximum number of backups. - - A recovery window retention policy uses the backup date/time of any full backups to determine if a backup is obsolete. The backup date/time of any successive incremental backups in the chain are ignored when comparing with the recovery window. -- The retention status of all incremental backups in a chain is set to the same status applied to the full backup of the chain. -- The actions applied by the `MANAGE` and `DELETE` subcommands on a full backup are applied to all incremental backups in the chain in the same manner. -- Thus, a backup chain (that is, the full backup and all its successive incremental backups) are treated by retention policy management as if they are all one, single backup. - - The status setting applied to the full backup is also applied to all incremental backups in its chain. - - If a full backup is marked as obsolete and then deleted according to the retention policy, all incremental backups in the chain are also marked obsolete and then deleted as well. - -The following are some specific points regarding the `MANAGE` and `DELETE` subcommands on incremental backups. - -- `MANAGE` subcommand: - - When the `MANAGE` subcommand is invoked, the status applied to the full backup is also applied to all successive incremental backups in the chain. - - The `MANAGE` subcommand with the `-c { keep | nokeep}` option cannot specify the backup identifier or backup name of an incremental backup with `-i` backup option. The `-i` backup option can only specify the backup identifier or backup name of a full backup. - - You can also use the `-i` all option to take a backup of all backups. When the `MANAGE` subcommand with the `-c { keep | nokeep }` option is applied to a full backup, the same status change is made to all incremental backups in the chain. -- `DELETE` subcommand: - - The `DELETE` subcommand with the `-s server -i` backup option specifies the backup identifier or backup name of an incremental backup in which case that incremental backup along with all its successive incremental backups are deleted, thus shortening that backup chain. - -## Using a Redundancy Retention Policy with Incremental Backups - -When a [redundancy retention policy](03_setting_the_retention_policy/#redundancy-retention-policy) is used and the `MANAGE` subcommand is invoked, the status of the oldest `active` full backup is changed to `obsolete` if the number of full backups exceeds the maximum number specified by the `retention_policy` parameter in the BART configuration file. - -!!! Note - When a full backup is changed from `active` to `obsolete`, all successive incremental backups in the chain of the full backup are also changed from `active` to `obsolete`. - -When determining the number of backups that exceeds the number specified by the `retention_policy` parameter, only full backups are counted for the comparison. Incremental backups are not included in the count for the comparison against the `retention_policy` parameter setting. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a redundancy retention policy is in effect. - -## Using a Recovery Window Retention Policy with Incremental Backups - -If the `MANAGE` command is invoked when BART is configured to use a [recovery window retention policy](03_setting_the_retention_policy/#recovery-window-retention-policy), the status of `active` full backups are changed to `obsolete` if the date/time of the full backup is outside of the recovery window. - -!!! Note - If a full backup is changed from `active` to `obsolete`, all successive incremental backups in the chain of the full backup are also changed from `active` to `obsolete`. - -The status of an incremental backup is changed to `obsolete` regardless of whether or not the date/time of when the incremental backup was taken still lies within the recovery window. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a recovery window retention policy is in effect. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx deleted file mode 100644 index aff92bbd6a5..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_backups_using_a_retention_policy.html" ---- - - - -Over the course of time when using BART, the number of backups can grow significantly. This ultimately leads to a large consumption of disk space unless an administrator periodically performs the process of deleting the oldest backups that are no longer needed. This process of determining when a backup is old enough to be deleted and then actually deleting such backups can be done and automated with the following basic steps: - -1. Determine and set a retention policy in the BART configuration file. A *retention policy* is a rule that determines when a backup is considered obsolete. The retention policy can be applied globally to all servers, but each server can override the global retention policy with its own. - -2. Use the `MANAGE` subcommand to categorize and manage backups according to the retention policy. - -3. Create a cron job to periodically run the `MANAGE` subcommand to evaluate the backups and then list and/or delete the obsolete backups. - - Retention policy management applies differently to incremental backups than to full backups. See [Managing Incremental Backups](05_managing_incremental_backups/#managing_incremental_backups) for information about how retention policy management is applied to each backup type. - - The following sections describe how retention policy management generally applies to backups, and its specific usage and effect on full backups. - -
- -overview_managing_backups_using_a_retention_policy marking_the_backup_status setting_the_retention_policy managing_the_backups_based_on_the_retention_policy managing_incremental_backups - -
diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx deleted file mode 100644 index f12dd038edd..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/check_config.html" ---- - - - -The `CHECK-CONFIG` subcommand checks the parameter settings in the BART configuration file as well as the database server configuration for which the `-s` option is specified. - -**Syntax:** - -`bart CHECK-CONFIG [ –s server_name ]` - -The following table describes the option. - -| Options | Description | -| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s ` or `--server ` | `server_name` is the name of the database server to be checked for proper configuration. If the option is omitted, the settings of the global section of the BART configuration file are checked. | - -- When the `-s` option is omitted, the global section \[BART] parameters including `bart_host`, `backup_path`, and `pg_basebackup_path` are checked. -- When the `-s` option is specified, the server section parameters are checked. In addition, certain database server `postgresql.conf` parameters are also checked, which include the following: - - The `cluster_owner` parameter must be set to the user account owning the database cluster directory. - - A passwordless SSH/SCP connection must be set between the BART user and the user account specified by the `cluster_owner` parameter. - - A database superuser must be specified by the BART `user` parameter. - - The `pg_hba.conf` file must contain a replication entry for the database superuser specified by the BART `user` parameter. - - The `archive_mode` parameter in the `postgresql.conf` file must be enabled. - - The `archive_command` parameter in the `postgresql.auto.conf` or the `postgresql.conf` file must be set. - - The `allow_incremental_backups` parameter in the BART configuration file must be enabled for database servers for which incremental backups are to be taken. - - Archiving of WAL files to the `archive_path` must be in process. - - The WAL scanner program must be running. - -The `CHECK-CONFIG` subcommand displays an error message if the required configuration is not properly set. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx deleted file mode 100644 index d8cdeed8126..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/init.html" ---- - - - -The `INIT` subcommand is used to create the BART backup catalog directory, rebuild the BART `backupinfo` file, and set the `archive_command` in the PostgreSQL server based on the `archive_command` setting in the `bart.cfg` file. - -!!! Note - If the `archive_mode` configuration parameter is set to `off`, then the `-o` option must be used to set the Postgres `archive_command` using the BART `archive_command` parameter in the BART configuration file even if the `archive_command` is not currently set in `postgresql.conf` nor in `postgresql.auto.conf` file. - -**Syntax:** - -```text -bart INIT [ –s { | all } ] [ -o ] - [ -r [ -i { | | all } ] ] - [--no-configure] -``` - -All subcommand options are generally specified in lowercase. The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`

`--server { \| all }` | `server_name` is the name of the database server to which the `INIT` actions are to be applied. If `all` is specified or if the option is omitted, the actions are applied to all servers. | -| `-o`

`--override` | Overrides the existing, active Postgres `archive_command` configuration parameter setting in the `postgresql.conf` file or the `postgresql.auto.conf` file using the BART `archive_command` parameter in the BART configuration file. The `INIT` generated archive command string is written to the `postgresql.auto.conf` file. | -| `-r`

`--rebuild` | Rebuilds the backupinfo file (a text file named `backupinfo`) located in each backup subdirectory. This option is only intended for recovering from a situation where the backupinfo file has become corrupt.
If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild that `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is an integer, backup identifier and `` is the user-defined alphanumeric name for the backup. If `all` is specified or if the option is omitted, the backupinfo files of all backups for the database servers specified by the `-s` option are recreated. The `-i` option can only be used with the `-r` option. | -| `--no-configure` | Prevents the `archive_command` from being set in the PostgreSQL server. | - -**Archive Command Setting** - -After the `archive_command` is set, you need to either restart the PostgreSQL server or reload the configuration file in the PostgreSQL server based on the following conditions. - -- If the `archive_mode` is set to `off` and `archive_command` is not set in the PostgreSQL server, the `archive_command` is set based on the `archive_command` setting in the `bart.cfg` and also sets the `archive_mode` to `on`. In this case, you need to restart the PostgreSQL server using `pg_ctl restart` -- If the `archive_mode` is set to `on` and `archive_command` is not set in the PostgreSQL server, the `archive_command` is set based on the `archive_command` setting in the `bart.cfg`. In this case, you need to reload the configuration in the PostgreSQL server using `pg_reload_conf()` or `pg_ctl reload`. -- If the `archive_mode` is set to `off` and `archive_command` is already set in the PostgreSQL server, the `archive_mode` is set to on. In this case, you need to restart the PostgreSQL server using `pg_ctl restart` -- If the `archive_mode` is set to `on` and `archive_command` is already set in the PostgreSQL server, then the `archive_command` is not set unless `-o` option is specified. diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx deleted file mode 100644 index 0189291fe44..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/backup.html" ---- - - - -The `BACKUP` subcommand is used to create a full backup or an incremental backup. - -**Syntax for full backup:** - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - [ -z ] [ –c ] - [ --backup-name ] - [ --thread-count ] - [ { --with-pg_basebackup | --no-pg_basebackup } ] -``` - -!!! Note - While taking a backup, if a file (for example, database server log file) exceeding 1 GB size is stored in the `$PGDATA` directory, the backup will fail. To avoid such backup failure, you need to store large files (exceeding 1 GB) outside the `$PGDATA` directory. - -**Syntax for incremental Backup:** - -```text -bart BACKUP –s { | all } [ -F p] - [ --parent { | } ] - [ --backup-name ] - [ --thread-count ] - [ --check ] - [--checksum-algorithm ] -``` - -!!! Note - To take an [incremental backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup), you must take a full backup first followed by incremental backup. - -**Please Note:** - -- While a `BACKUP` subcommand is in progress, no other subcommands must be invoked. Any subcommands invoked while a backup is in progress will skip and ignore the backups. - -- For full backup, the target default format is a tar file, whereas for incremental backup, only plain format must be specified. - -- The backup is saved in the `//` directory, where `` is the value assigned to the `` parameter in the BART configuration file, `` is the lowercase name of the database server as listed in the configuration file, and `` is a backup identifier assigned by BART to the particular backup. - -- MD5 checksums of the full backup and any user-defined tablespaces are saved as well for tar backups. - -- Before performing the backup, BART checks to ensure if there is enough disk space to completely store the backup in the BART backup catalog. - -- In the `postgresql.conf` file, ensure the `wal_keep_segments` configuration parameter is set to a sufficiently large value. A low setting of the `wal_keep_segments` configuration parameter may result in the deletion of some WAL files before the BART `BACKUP` subcommand saves them to the `archive_path`. For information about the `wal_keep_segments` parameter, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/runtime-config-replication.html). - -- In the BART configuration file, setting `xlog_method=stream` will instruct the server to stream the transaction log in parallel with creation of the backup for a specific database server; otherwise the transaction log files are collected upon completion of the backup. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details about database server setting. - - !!! Note - If the transaction log streaming method is used, the `-Fp` option for a plain text backup format must be specified with the `BACKUP` subcommand. - -- When you use BART to take a backup of PostgreSQL server, multiple backups can be taken simultaneously and if a backup is interrupted, the backup mode is terminated automatically without the need to run `pg_stop_backup()` command manually to terminate the backup. - -**Options** - -Along with the `BACKUP` subcommand, specify the following option: - -| Options | Description | -| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { server_name \| all }`
`--server { server_name \| all }` | `server_name` is the database server name to be backed up as specified in the BART configuration file. If `all` is specified, all servers are backed up. This option is mandatory.
If `all` is specified, and a connection to a database server listed in the BART configuration file cannot be opened, the backup for that database server is skipped, but the backup operation continues for the other database servers. | - -Specify the following options as required. If you do not specify any of the following options, the backup is created using default settings. - -| Options | Description | -| -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-F { p \| t }`
`--format { p \| t }` | Specify this option to provide the backup file format. Use `p` for plain text or `t` for tar. If the option is omitted, the default is tar format.
For taking incremental backups, the option `-Fp` must be specified. | -| `-z`
`--gzip` | This is applicable only for full backup. Specify this option to use gzip compression on the tar file output using the default compression level. This option is applicable only for the tar format. | -| `-c `
`--compress-level ` | This is applicable only for full backup. Specify this option to use the gzip compression level on the tar file output. `compression_level` is a digit from 1 through 9, with 9 being the best compression. This option is applicable only for the tar format. | -| `--parent { backup_id \| backup_name }` | Specify this option to take an incremental backup. `` is the backup identifier of a parent backup. `` is the user-defined alphanumeric name of a parent backup.
The parent is a backup taken prior to the incremental backup. The parent backup can be either a full backup or an incremental backup.
The option `–Fp` must be specified since an incremental backup can only be taken in plain text format.
An incremental backup cannot be taken on a standby database server. See [Block-Level Incremental Backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup) for additional information on incremental backups. | -| `--backup-name ` | Specify this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
The backup name may include the following variables to be substituted by the timestamp values when the backup is taken: 1) `%year` – 4-digit year, 2) `%month` – 2-digit month, 3) `%day` – 2-digit day, 4) `%hour` 2-digit hour, 5) `%minute` – 2-digit minute, and 6) `%second` – 2-digit second.
To include the percent sign (`%`) as a character in the backup name, specify `%%` in the alphanumeric string.
If the backup name contains space characters (i.e. more than one word) or when referenced with the option `-i` by other subcommands (such as `restore`), enclose the string in single quotes or double quotes. See [backup name examples](#backup_name_examples).
If the `--backup-name` option is not specified, and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to use the number of worker threads to run in parallel to copy blocks for a backup.
If the option `--thread-count` is omitted, then the `thread_count` parameter in the BART configuration file applicable to this database server is used.
If the option `--thread-count` is not enabled for this database server, then the `thread_count` setting in the global section of the BART configuration file is used.
If the option `--thread-count` is not set in the global section as well, the default number of threads is 1.
If parallel backup is run with N number of worker threads, then it will initiate N+ 1 concurrent connections with the server.
Thread count will not be effective if backup is taken on a standby server.
For more information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/) | -| `--with-pg_basebackup` | This is applicable only for full backup. Specify this option to use `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the option `--with-pg_basebackup` is specified with the `BACKUP` subcommand. | -| `--no-pg_basebackup` | This is applicable only for full backup. Specify this option if you do not want `pg_basebackup` to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the option `--no-pg_basebackup` is specified with the `BACKUP` subcommand. | -| `--check` | This is applicable only for incremental backup. Specify this option to verify if the required MBM files are present in the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file before taking an incremental backup. The option `--parent` must be specified when the option `--check` is used. An actual incremental backup is not taken when the option `--check` is specified. | -| `--checksum-algorithm` | While taking a backup, you can specify one of the following values with the `--checksum-algorithm` option:
`--checksum-algorithm=MD5` (default) to generate MD5 checksum files.
`--checksum-algorithm=SHA256` to generate SHA256 checksum files.
`--checksum-algorithm=NONE` to skip generating checksum files. | - - - -**Backup Name Examples** - -The following examples demonstrate using the `--backup-name` clause: - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year -MONTH = %month DAY = %day" -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year -MONTH = %month DAY = %day %%" -./bart show-backups -s ppas12 -i "test backup" -``` - -**Error messages** - -The following table lists the error messages that may be encountered when using the `BACKUP` subcommand: - -| error message | Cause | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `edb@localhost bin]$ ./bart backup -s mktg -Ft`

`WARNING: xlog_method is empty, defaulting to global policy`

`ERROR: backup failed for server 'mktg'`

`free disk space is not enough to backup the server 'mktg'`

`space available 13.35 GB, approximately required 14.65 GB` | Insufficient free disk space. | -| `ERROR: backup failed for server 'mktg'`

`command failed with exit code 1`

`pg_basebackup: could not get transaction log end position from server: ERROR: requested WAL segment 00000001000000D50000006B has already been removed` | The wal_keep_segments configuration parameter is not set to a sufficiently large value in the postgresql.conf file. | -| `ERROR: backup failed for server 'mktg'`

`connection to the server failed: could not connect to server: Connection refused`

`Is the server running on host "172.16.114.132" and accepting`

`TCP/IP connections on port 5444?` | A connection to a database server listed in the BART configuration file fails. As a result the backup for that database server is skipped, but the backup operation continues for other database servers | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx deleted file mode 100644 index 778efd3d4d6..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_servers.html" ---- - - - -The `SHOW-SERVERS` subcommand displays the information for the managed database servers listed in the BART configuration file. - -**Syntax:** - -`bart SHOW-SERVERS [ –s { | all } ]` - -The following table describes the command options. - -| Options | Description | -| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server whose BART configuration information is to be displayed. If `all` is specified or if the option is omitted, information for all database servers is displayed. | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx deleted file mode 100644 index d006df69db1..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_backups.html" ---- - -The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. - -**Syntax:** - -```text -bart SHOW-BACKUPS [ –s { | all } ] - [ -i { | | all } ] - [ -t ] -``` - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server whose backup information is to be displayed.
If `all` is specified or if the option is omitted, the backup information for all database servers is displayed with the exception as described by the following note:
If `SHOW-BACKUPS` is invoked while the BART `BACKUP` subcommand is in progress, backups affected by the backup process are shown in progress status in the displayed backup information. | -| `-i { \| \| all }`
`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified or if the option is omitted, all backup information for the relevant database server is displayed. | -| `-t`
`--toggle` | Displays more backup information in a list format. If the option is omitted, the default is a tabular format. | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx deleted file mode 100644 index 4ec79d52d62..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/verify_chksum.html" ---- - - - -The `VERIFY-CHKSUM` subcommand verifies the MD5 checksums of the full backups and any user-defined tablespaces for the specified database server or for all database servers. The checksum is verified by comparing the current checksum of the backup against the checksum when the backup was taken. - -!!! Note - The `VERIFY-CHKSUM` subcommand is only used for tar format backups. It is not applicable to plain format backups. - -**Syntax:** - -```text -bart VERIFY-CHKSUM - [ -s { | all } ] - [ -i { | | all } ] -``` - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`

`--server { \| all }` | `` is the name of the database server whose tar backup checksums are to be verified. If `all` is specified or if the `-s` option is omitted, the checksums are verified for all database servers. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is the backup identifier of a tar format full backup whose checksum is to be verified along with any user-defined tablespaces.
`` is the user-defined alphanumeric name for the full backup.
If `all` is specified or if the `-i` option is omitted, the checksums of all tar backups for the relevant database server are verified. | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx deleted file mode 100644 index 52a74badaa7..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/manage.html" ---- - - - -The `MANAGE` subcommand can be invoked to: - -- Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file (See [Managing Backups Using a Retention Policy](../02_managing_backups_using_a_retention_policy/#managing_backups_using_a_retention_policy) for information about retention policy management). - -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file (See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting this parameter). - - **Syntax:** - - ```text - bart MANAGE [ –s { | all} ] - [ -l ] [ -d ] - [ -c { keep | nokeep } - -i { | | all } ] - [ -n ] - ``` - -The following summarizes the actions performed when the `MANAGE` subcommand is invoked: - -- When the `MANAGE` subcommand is invoked with no options or with only the `-s ` or `-s all` option, the following actions are performed: - - For the server specified by the `-s` option, or for all servers (if `-s all` is specified or the `-s` option is omitted), active backups are marked as `obsolete` in accordance with the retention policy. - - All backups that were marked `obsolete` or `keep` prior to invoking the `MANAGE` subcommand remain marked with the same prior status. - - If WAL compression is enabled for the database server, then any uncompressed, archived WAL files in the BART backup catalog of the database server are compressed with gzip. -- When the `MANAGE` subcommand is invoked with any other option besides the `-s` option, the following actions are performed: - - For the server specified by the `-s` option, or for all servers, the action performed is determined by the other specified options (that is, `-l` to list obsolete backups, `-d` to delete obsolete backups, `-c` to keep or to return backups to `active` status, or `-n` to perform a dry run of any action). - - No marking of `active` backups to `obsolete` status is performed regardless of the retention policy. - - All backups that were marked `obsolete` or `keep` prior to invoking the `MANAGE` subcommand remain marked with the same prior status unless the `-c` option (without the `-n` option) is specified to change the backup status of the particular backup or all backups referenced with the `-i` option. - - No compression is applied to any uncompressed, archived WAL file in the BART backup catalog regardless of whether or not WAL compression is enabled. - -The following are additional considerations when using WAL compression: - -- Compression of archived WAL files is not permitted for database servers on which incremental backups are to be taken. -- The gzip compression program must be installed on the BART host and be accessible in the `PATH` of the BART user account. -- When the `RESTORE` subcommand is invoked, if the `-c` option is specified or if the `copy_wals_during_restore` BART configuration parameter is enabled for the database server, then the following actions occur: - - - If compressed, archived WAL files are stored in the BART backup catalog and the location to which the WAL files are to be restored is on a remote host relative to the BART host: - - - the archived WAL files are transmitted across the network to the remote host in compressed format only if the gzip compression program is accessible in the `PATH` of the remote user account that is used to log into the remote host when performing the `RESTORE` operation. - - This remote user is specified with either the `remote_host` parameter in the BART configuration file or the `RESTORE -r` option (see [RESTORE](08_restore/#restore)). - - Transmission of compressed WAL files results in less network traffic. After the compressed WAL files are transmitted across the network, the `RESTORE` subcommand uncompresses the files for the point-in-time recovery operation. - - If the gzip program is not accessible on the remote host in the manner described in the previous bullet point, then the compressed, archived WAL files are first uncompressed while on the BART host, then transmitted across the network to the remote host in uncompressed format. -- When the `RESTORE` subcommand is invoked without the `-c` option and the `copy_wals_during_restore` BART configuration parameter is disabled for the database server, then any compressed, archived WAL files needed for the `RESTORE` operation are uncompressed in the BART backup catalog. The uncompressed WAL files can then be saved to the remote host by the `restore_command` in the `postgresql.auto.conf` file when the database server archive recovery begins. - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `s { \| all }`
`--server { \| all }` | `` is the name of the database server to which the actions are to be applied. If `all` is specified or if the `-s` option is omitted, the actions are applied to all database servers. | -| `-l`
`--list-obsolete` | Lists the backups marked as obsolete. | -| `-d`
`--delete-obsolete` | Delete the backups marked as `obsolete`. This action physically deletes the backup along with its archived WAL files and any MBM files for incremental backups. | -| `-c { keep \| nokeep }`

`--change-status { keep \| nokeep }` | Specify `keep` to change the status of a backup to `keep` to retain it indefinitely.
Specify `nokeep` to change the status of any backup back to active status. The backup can then be re-evaluated and possibly be marked to `obsolete` according to the retention policy by subsequent usage of the `MANAGE` subcommand.
The `–i` option must be included when using the `-c` option. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified, then actions are applied to all backups.
The `–c` option must be included when using the `-i` option. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to actually implementing the actions as if the operation was performed, however, no changes are actually made.
If `-n` is specified with the `-d` option, it displays which backups would be deleted, but does not actually delete the backups.
If `-n` is specified with the `-c` option, it displays the keep or nokeep action, but does not actually change the backup from its current status.
If `-n` is specified alone with no other options, or with only the `-s` option, it displays which active backups would be marked as obsolete, but does not actually change the backup status. In addition, no compression is performed on uncompressed, archived WAL files even if WAL compression is enabled for the database server. | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx deleted file mode 100644 index a7fc6fc64ab..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restore.html" ---- - - - -The `RESTORE` subcommand restores a backup and its archived WAL files for the designated database server to the specified directory location. If the appropriate `RESTORE` options are specified, all recovery settings will be saved in the `postgresql.auto.conf` file. - -**Syntax:** - -```text -bart RESTORE –s -p - [ –i { | } ] - [ -r ] - [ -w ] - [ -t ] - [ { -x | -g } ] - [ -c ] - [ --disable-checksum ] -``` - -For information about using a continuous archive backup for recovery, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/13/static/continuous-archiving.html). This reference material provides detailed information about the underlying point-in-time recovery process and the meaning and usage of the restore options that are generated into the `postgresql.auto.conf` file by BART. - -**Please note**: - -- For special requirements when restoring an incremental backup to a remote database server, see [Restoring an Incremental Backup on a Remote Host](../../02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup/#restoring_an_incremental_backup_on_a_remote_host). -- Check to ensure that the host where the backup is to be restored contains enough disk space for the backup and its archived WAL files. The `RESTORE` subcommand may result in an error while copying files if there is not enough disk space available. -- See [Performing a Restore Operation](../01_bart_management_overview/01_performing_a_restore_operation/#performing_a_restore_operation) to view steps on how to perform a restore operation and see [Point-In-Time Recovery Operation](../01_bart_management_overview/02_point_in_time_recovery_operation/#point_in_time_recovery_operation) to view steps on how to perform a point-in-time recovery operation. -- If the backup is restored to a different database cluster directory than where the original database cluster resided, certain operations dependent upon the database cluster location may fail. This happens if their supporting service scripts are not updated to reflect the new directory location of restored backup. For information about the usage and modification of service scripts, see the *EDB Advanced Server Installation Guide* available at the [EDB website](/epas/latest/). - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server to be restored. | -| `-p `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | -| `-i { \| }`

`--backupid { \| }` | `` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the default is to use the latest backup. | -| `-r or --remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored and `` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `` parameter for this database server is not set in the BART configuration file.
If the BART user account is not the same as the operating system account owning the `` directory given with the `-p` option, use the `` BART configuration parameter or the `RESTORE` subcommand `-r` option to specify the `` directory owner even when restoring to a directory on the same host as the BART host.
See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `` parameter. | -| `-w `
`--workers ` | `` is the specification of the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location.
For example, if 4 worker processes are specified, 4 receiver processes on the restore host and 4 streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process. When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. If the `-w` option is omitted, the default is `1` \| worker process. | -| `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | -| `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. Include either the `-x ` or the `--target-xid ` option if point-in-time recovery is desired. | -| `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. Include either the `--target-timestamp ` or the `-g ` option if point-in-time recovery is desired. | -| `-c`
`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
If recovery settings are saved in the `postgresql.auto.conf` file for point-in-time recovery, the `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, the `restore_command` in the `postgresql.auto.conf` file is generated by default to retrieve the archived WAL files directly from the BART backup catalog. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `copy_wals_during_restore` parameter. | -| `--disable-checksum` | While restoring a backup, specify this option to skip verifying the MD5 or SHA256 checksum files.
If you set the `--checksum-algorithm=NONE` option with the [BART scanner](../04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or while taking a [backup](03_backup/#backup), you must specify the `--disable checksum` option while restoring an incremental backup. | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx deleted file mode 100644 index 7f9836ad724..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/delete.html" ---- - - - -The `DELETE` subcommand removes the subdirectory and data files from the BART backup catalog for the specified backups along with its archived WAL files. - -**Syntax:** - -```text -bart DELETE –s - -i { all | - [']{ | },... }['] - } - [ -n ] -``` - -!!! Note - While invoking the `DELETE` subcommand, you must specify a specific database server. - -For database servers under a retention policy, there are conditions where certain backups may not be deleted. See [Deletions Permitted Under a Retention Policy](../02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy/#deletions_permitted_under_retention_policy) for information about permitted backup deletions. - -The following table describes the command options: - -| Options | Description | -| -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `

`--server ` | `` is the name of the database server whose backups are to be deleted. | -| `-i { all \| [']{ \| },... }['] }`

`--backupid { all \| [']{ \| },... }['] }` | `` is the backup identifier of the backup to be deleted and `` is the user-defined alphanumeric name for the backup.
Multiple backup identifiers and backup names may be specified in a comma-separated list. The list must be enclosed within single quotes if there is any white space appearing before or after each comma.
If `all` is specified, all of the backups and their archived WAL files for the specified database server are deleted. | -| `-n`
`--dry-run` | Displays the results as if the deletions were done, however, no physical removal of the files are actually performed. In other words, a test run is performed so that you can see the potential results prior to actually initiating the action.
After the deletion, the BART backup catalog for the database server no longer contains the corresponding directory for the deleted backup ID. The `archived_wals` subdirectory no longer contains the WAL files of the backup. | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx deleted file mode 100644 index e7d51affa18..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Basic BART Subcommand Usage" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/basic_bart_subcommand_usage.html" ---- - - - -This section briefly describes the BART subcommands and options. You can invoke the `bart` program (located in the `/bin` directory) with the desired options and subcommands to manage your BART installation. - -To view examples of BART subcommands, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -**Syntax for invoking BART**: - - `bart [ general_option ]... [ subcommand ] [subcommand_option ]...` - -- When invoking a subcommand, the subcommand name is not case-sensitive (that is, the subcommand can be specified in uppercase, lowercase, or mixed case). -- Each subcommand has a number of its own applicable options that are specified following the subcommand. All options are available in both single-character and multi-character forms. -- Keywords are case-sensitive; options are generally specified in lowercase unless specified otherwise in this section. -- When invoking BART, the current user must be the BART user account (operating system user account used to run the BART command line program). For example, enterprisedb or postgres can be selected as the BART user account when the managed database servers are Advanced Server or PostgreSQL respectively. -- The chosen operating system user account must own the BART backup catalog directory, be able to run the `bart` program and the `bart scanner` program, and have a passwordless SSH/SCP connection established between database servers managed by BART. - -You can specify one or more of the following general options: - -| Options | Description | -| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on BART usage. All subcommands support a help option (`-h`, `--help`). If the help option is specified, information is displayed regarding that particular subcommand. The subcommand, itself, is not executed. | -| `-v` `--version` | Displays the BART version information. | -| `-d` `--debug` | Displays debugging output while executing BART subcommands. | -| `-c ` `--config-path ` | Specifies `config_file_path` as the full directory path to a BART configuration file. Use this option if you do not want to use the default BART configuration file `/etc/bart.cfg`. | - -**Troubleshooting: Setting Path Environment Variable** - -If execution of BART subcommands fails with the following error message, then you need to set the `LD_LIBRARY_PATH` to include the `libpq` library directory: - - `./bart: symbol lookup error: ./bart: undefined symbol: PQping` - -**Workaround:** Set the `LD_LIBRARY_PATH` environment variable for the BART user account to include the directory containing the `libpq` library. This directory is `POSTGRES_INSTALL_HOME/lib`. - -It is suggested that the `PATH` and the `LD_LIBRARY_PATH` environment variable settings be placed in the BART user account’s profile. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details. - -In the following sections, the `help` option is omitted from the syntax diagrams for the purpose of providing readability for the subcommand options. - -
- -check_config init backup show_servers show_backups verify_chksum manage restore delete - -
diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx deleted file mode 100644 index afd4360481c..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/running_the_bart_wal_scanner.html" ---- - - - -Use the BART WAL scanner to invoke the `bart-scanner` program located in the `BART_HOME/bin` directory. When invoking the WAL scanner, the current user must be the BART user account. - -**Syntax:** - -```text -bart-scanner - [ -d ] - [ -c ] - { –h | - -v | - --daemon | - -p | - | - RELOAD | - STOP - --checksum-algorithm } -``` - -!!! Note - For clarity, the syntax diagram shows only the single-character option form (for example, `-d`), but the multi-character option form (for example, `--debug`) is supported as well. - -The WAL scanner processes each WAL file to find and record modified blocks in a corresponding modified block map (MBM) file. The default approach is that the WAL scanner gets notified whenever a new WAL file is added to the `archived_wals` directory specified in the `archive_path` parameter of the configuration file. It then scans the WAL file and produces the MBM file. - -The default approach does not work in some cases; for example when the WAL files are shipped to the `archive_path` using the Network File System (NFS) and also in case of some specific platforms. This results in the WAL files being copied to the `archived_wals` directory, but the WAL scanner does not scan them (as WAL scanner is not aware of WAL file) and produce the MBM files. This results in the failure of an incremental backup. This can be avoided by using the timer-based WAL scanning approach, which is done by using the `scan_interval` parameter in the BART configuration file. The value for `scan_interval` is the number of seconds after which the WAL scanner will initiate force scanning of the new WAL files. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about `scan_interval` parameter. - -!!! Note - After upgrading to BART 2.6.1, users who have set this parameter to a non-default value may see increased CPU consumption on the part of bart-scanner. If this is an issue, consider increasing the configured value of scan_interval parameter, or removing the setting if it is not required. - -When the `bart-scanner` program is invoked, it forks a separate process for each database server enabled with the `allow_incremental_backups` parameter. - -The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option. Use the `--daemon` option to run the WAL scanner process in the background so that all output messages can be viewed in the BART log file. If the `--daemon` option is omitted, the WAL scanner process runs in the foreground and all output messages can be viewed from the terminal running the program as well as in the BART log file. - -See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for additional information about WAL scanning, `allow_incremental_backups`, and `logfile` parameters. - -!!! Note - The BART user account’s `LD_LIBRARY_PATH` environment variable may need to be set to include the directory containing the `libpq` library if invocation of the WAL scanner program fails. See [Basic BART Subcommand Usage](03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage) for information about setting the `LD_LIBRARY_PATH` environment variable. - -The following table describes the scanner options: - -| Options | Description | -| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on WAL scanner usage. | -| `-v` `--version` | Displays the WAL scanner version information. | -| `-d` `--debug` | Displays debugging output while executing the WAL scanner with any of its options. | -| `-c ` `--config-path ` | Use this option to specify the `config_file_path` of a BART configuration file if you do not want to use the default BART configuration file path `BART_HOME/etc/bart.cfg`. | -| `--daemon` | Runs the WAL scanner as a background process. | -| `-p ` `--print ` | Use this option to specify the full directory path to an MBM file whose content is to be printed. The directory specified in the `archive_path` parameter in the `bart.cfg` file contains the MBM files. | -| `` | Specify the full directory path to a WAL file to be scanned. The directory specified in the `archive_path` parameter in the `bart.cfg` file contains the WAL files. Use this option if a WAL file in the archive path is missing its MBM file. This option is to be used for assisting the EnterpriseDB support team for debugging problems that may have been encountered. | -| `RELOAD` | Reloads the BART configuration file. The keyword `RELOAD` is not case-sensitive. The `RELOAD` option is useful if you make changes to the configuration file after the WAL scanner has been started. It will reload the configuration file and adjust the WAL scanners accordingly. For example, if a server section allowing incremental backups is removed from the BART configuration file, then the process attached to that server will stop. Similarly, if a server allowing incremental backups is added, a new WAL scanner process will be launched to scan the WAL files of that server. | -| `STOP` | Stops the WAL scanner. The keyword `STOP` is not case-sensitive. | -| `--checksum-algorithm` | While invoking the WAL scanner, you can specify one of the following values with the `--checksum-algorithm` option: `--checksum-algorithm=MD5` (default) to generate MD5 checksum files. `--checksum-algorithm=SHA256` to generate SHA256 checksum files. `--checksum-algorithm=NONE` to skip generating checksum files. | diff --git a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/index.mdx b/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/index.mdx deleted file mode 100644 index a076b82b5e9..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/03_using_bart/index.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Using BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_bart.html" ---- - - - -After installing and configuring the BART host and the database servers, you can start using BART. - -This section describes how to perform backup and recovery management operations using BART. Review the sections that follow before proceeding with any BART operation. - -
- -bart_management_overview managing_backups_using_a_retention_policy basic_bart_subcommand_usage running_the_bart_wal_scanner - -
diff --git a/product_docs/docs/bart/2.6.1/bart_user/04_using_tablespaces.mdx b/product_docs/docs/bart/2.6.1/bart_user/04_using_tablespaces.mdx deleted file mode 100644 index 94d5450778a..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/04_using_tablespaces.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Using Tablespaces" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_tablespaces.html" ---- - - - -If the database cluster contains user-defined tablespaces (that is, tablespaces created with the `CREATE TABLESPACE` command): - -- You can take full backups with the `BACKUP` subcommand in either tar (`-Ft`) or plain text (`-Fp`) backup file format. -- You must take incremental backups in the plain text (`-Fp`) backup file format. -- You can take full backups using the transaction log streaming method (xlog_method = stream in the BART configuration file) `--with-pg_basebackup` and the `BACKUP` subcommand in either tar (`-Ft`) or plain text (`-Fp`) backup file format. - -!!! Note - If the particular database cluster you plan to back up contains tablespaces created by the `CREATE TABLESPACE` command, then you must set the `tablespace_path` parameter in the BART configuration file before you perform a BART `RESTORE` operation. - -The `tablespace_path` parameter specifies the directory paths to which you want the tablespaces to be restored. It takes the following format: - - `OID_1=tablespace_path_1;OID_2=tablespace_path_2 ...` - -Where `OID_1`, `OID_2`, … are the Object Identifiers of the tablespaces. You can find the OIDs of the tablespaces and their corresponding soft links to the directories by listing the contents of the `POSTGRES_INSTALL_HOME/data/pg_tblspc` subdirectory as shown in the following example: - -```text -[root@localhost pg_tblspc ]# pwd -/opt/PostgresPlus/9.6AS/data/pg_tblspc -[root@localhost pg_tblspc]# ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Aug 22 16:38 16644 -> /mnt/tablespace_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Aug 22 16:38 16645 -> /mnt/tablespace_2 -``` - -The OIDs are `16644` and `16645` to directories `/mnt/tablespace_1` and `/mnt/tablespace_2`, respectively. - -If you later wish to restore the tablespaces to the same locations as indicated in the preceding example, the BART configuration file must contain the following entry: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -tablespace_path = 16644=/mnt/tablespace_1;16645=/mnt/tablespace_2 -description = "Accounting" -``` - -If you later wish to restore the tablespaces to different locations, specify the new directory locations in the `tablespace_path` parameter. - -In either case, the directories specified in the `tablespace_path` parameter must exist and be empty at the time you perform the `BART RESTORE` operation. - -If the database server is running on a remote host (in other words you are also using the `remote_host` configuration parameter or will specify the `--remote-host` option with the `RESTORE` subcommand), the specified tablespace directories must exist on the specified remote host. - -To view example of backing up and restoring a database cluster on a remote host containing tablespaces, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -The directories must be owned by the user account with which you intend to start the database server (typically the Postgres user account) with no access by other users or groups as is required for the directory path to which the main full backup is to be restored. - -To view a sample BART managed backup and recovery system consisting of both local and remote database servers, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.6.1/bart_user/images/EDB_logo.png b/product_docs/docs/bart/2.6.1/bart_user/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.1/bart_user/images/copy_1.png b/product_docs/docs/bart/2.6.1/bart_user/images/copy_1.png deleted file mode 100644 index e08d97827fb..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/images/copy_1.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:c2b13e1623222f77bce5a2d1be4027a9032c878b05bed7ba1a0873be45257d8c -size 10470 diff --git a/product_docs/docs/bart/2.6.1/bart_user/images/edb.png b/product_docs/docs/bart/2.6.1/bart_user/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.1/bart_user/images/edb_logo.svg b/product_docs/docs/bart/2.6.1/bart_user/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.1/bart_user/index.mdx b/product_docs/docs/bart/2.6.1/bart_user/index.mdx deleted file mode 100644 index 50504d9e3db..00000000000 --- a/product_docs/docs/bart/2.6.1/bart_user/index.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -navTitle: Backup and Recovery Guide -title: "EDB Postgres Backup and Recovery User Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/index.html" ---- - -
- -introduction overview using_bart using_tablespaces conclusion - -
diff --git a/product_docs/docs/bart/2.6.1/index.mdx b/product_docs/docs/bart/2.6.1/index.mdx deleted file mode 100644 index 8993f4a09fd..00000000000 --- a/product_docs/docs/bart/2.6.1/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Backup and Recovery Tool -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.6.1 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." -navigation: - - "#Getting Started" - - bart_inst - - bart_qs_7 - - bart_qs_8 - - "#Guides" - - bart_user - - bart_ref -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.6.1" ---- diff --git a/product_docs/docs/bart/2.6.2/bart_inst/02_installing_bart.mdx b/product_docs/docs/bart/2.6.2/bart_inst/02_installing_bart.mdx deleted file mode 100644 index 20b4b7e19e5..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/02_installing_bart.mdx +++ /dev/null @@ -1,429 +0,0 @@ ---- -title: 'Installing BART' - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/installing_bart.html" ---- - -This section will walk you through performing a fresh installation of BART on a host. Installation instructions are organized into the following platform/installer specific sections: - -- [Installing BART on a CentOS](#installing-bart-on-a-centos-host) -- [Installing BART on a RHEL Host](#installing-bart-on-a-rhel-host) -- [Installing BART on a CentOS or RHEL Host](#installing-bart-on-a-rhelcentos-7-ppcle-host) -- [Installing BART on a Debian or Ubuntu Host](#installing-bart-on-a-debian-or-ubuntu-host) -- [Installing BART on an SLES 12 Host](#installing-bart-on-an-sles-12-host) - -!!! Note - If you are using the pdf version of this document, using cut/paste to copy command may result in extra spaces or carriage returns in the pasted command. If a command fails, check the command carefully for additional characters. - -## Installing BART on a CentOS Host - -The following section demonstrates installing BART on a CentOS host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. To install the repository configuration, assume superuser privileges and invoke one of the following platform-specific commands: - - On CentOS 7: - - ```text - yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - - On CentOS 8: - - ```text - dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Replace the `USERNAME:PASSWORD` in the following command with the username and password of a registered EnterpriseDB user: - - ```text - sed -i "s@:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -3. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - On CentOS 7: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - - On CentOS 8: - - ```text - dnf -y install epel-release - ``` - -4. For CentOS 8, enable the PowerTools repository to satisfy EPEL package dependencies: - - ```text - dnf config-manager --set-enabled PowerTools - ``` - -5. For CentOS 8, disable the built-in PostgreSQL module: - - ```text - dnf -qy module disable postgresql - ``` - -6. Optionally, install the `pg_basebackup` utility program using the server client package. If you do not already have the `pg_basebackup` program installed on the BART host, you can install a limited number of files that include the `pg_basebackup` program by invoking the following command: - - On CentOS 7: - - ```text - yum install edb-as-server-client - ``` - - On CentOS 8: - - ```text - dnf install edb-as-server-client - ``` - - In the above command, replace `` with the required Advanced Server version. The `pg_basebackup` version must be the same or more recent than the database server to be backed up. For example, `pg_basebackup` version 10 can be used to back up database server version 10, but cannot be used to back up database server version 11. - -7. Use the following command to install BART: - - On CentOS 7: - - ```text - yum -y install edb-bart - ``` - - On CentOS 8: - - ```text - dnf -y install edb-bart - ``` - - Repeat the installation process described in this section to install BART on each remote host on which an incremental backup is to be restored. - - To verify the BART installation, navigate to the `/usr/edb/bart/bin` directory and execute the following command: - - ```text - bart --version - ``` - - The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - - - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - Upon successful installation, BART is installed in the `BART_HOME` directory: - - `/usr/edb/bart` - - The installation includes the following files: - -| File Name | Location | Description | -| ------------------- | ----------------- | ------------------------------------- | -| bart | ``/bin | BART command line, executable program | -| bart-scanner | ``/bin | BART WAL scanner program | -| bart.cfg.sample | ``/etc | Sample BART configuration file | -| xlogreader_ident.so | ``/lib | Libraries supporting WAL versions | -| bart_license.txt | `` | License agreement | - -After BART is installed successfully, you need to [configure the installation](03_configuring_bart/#configuration). - -## Installing BART on a RHEL Host - -The following section demonstrates installing BART on a RHEL host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. To install the repository configuration, assume superuser privileges and invoke one of the following platform-specific commands: - - On RHEL 7: - - ```text - yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - - On RHEL 8: - - ```text - dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Replace the `USERNAME:PASSWORD` in the following command with the username and password of a registered EnterpriseDB user: - - ```text - sed -i "s@:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -3. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - On RHEL 7: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - - On RHEL 8: - - ```text - dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - ``` - -4. Enable the repository: - - On RHEL 7, enable the `optional, extras`, and `HA` repositories to satisfy EPEL package dependencies: - - ```text - subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms" - ``` - - On RHEL 8, enable the `codeready-builder-for-rhel-8-*-rpms` repository to satisfy EPEL packages dependency: - - ```text - ARCH=$( /bin/arch ) - - subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms" - ``` - -5. For RHEL 8, disable the built-in PostgreSQL module: - - ```text - dnf -qy module disable postgresql - ``` - -6. Optionally, install the `pg_basebackup` utility program using the server client package. If you do not already have the `pg_basebackup` program installed on the BART host, you can install a limited number of files that include the `pg_basebackup` program by invoking the following command: - - On RHEL 7: - - ```text - yum install edb-as-server-client - ``` - - On RHEL 8: - - ```text - dnf install edb-as-server-client - ``` - - In the above command, replace `` with the required Advanced Server version. The `pg_basebackup` version must be the same or more recent than the database server to be backed up. For example, `pg_basebackup` version 10 can be used to back up database server version 10, but cannot be used to back up database server version 11. - -7. Use the following command to install the BART: - - On RHEL 7: - - ```text - yum -y install edb-bart - ``` - - On RHEL 8: - - ```text - dnf -y install edb-bart - ``` - - Repeat the installation process described in this section to install BART on each remote host on which an incremental backup is to be restored. - - To verify the BART installation, navigate to the `/usr/edb/bart/bin` directory and execute the following command: - - ```text - bart --version - ``` - - The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - - - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - Upon successful installation, BART is installed in the `BART_HOME` directory: - - `/usr/edb/bart` - - The installation includes the following files: - -| File Name | Location | Description | -| ------------------- | ----------------- | ------------------------------------- | -| bart | ``/bin | BART command line, executable program | -| bart-scanner | ``/bin | BART WAL scanner program | -| bart.cfg.sample | ``/etc | Sample BART configuration file | -| xlogreader_ident.so | ``/lib | Libraries supporting WAL versions | -| bart_license.txt | `` | License agreement | - -After BART is installed successfully, you need to [configure the installation](03_configuring_bart/#configuration). - - - -## Installing BART on a RHEL/CentOS 7 PPCLE Host - -The following section demonstrates installing BART on a RHEL host using an RPM package.  This section assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -1. Install Advance Toolchain: - - ```text - rpm --import https://public.dhe.ibm.com/software/server/POWER/Linux/toolchain/at/redhat/RHEL7/gpg-pubkey-6976a827-5164221b - - cat > /etc/yum.repos.d/advance-toolchain.repo <:@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo - ``` - - To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/user). - -4. Before installing BART, execute the following command to install the Extra Packages for Enterprise Linux (EPEL) release package: - - ```text - yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - ``` - -5. On RHEL 7, enable the `optional, extras`, and `HA` repositories to satisfy EPEL package dependencies: - - ```text - subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms" - ``` - -6. Invoke the following command to install BART: - - ```text - yum -y install edb-bart - ``` - - - -## Installing BART on a Debian or Ubuntu Host - -Perform the following steps to install a Debian package using the EnterpriseDB apt repository. - -To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/repository-access-request). - -1. Assume the superuser privileges. - - ```text - sudo su - - ``` - -2. To configure the EnterpriseDB repository on Debian 9, Ubuntu 18, and Ubuntu 20: - - ```text - sh -c 'echo "deb https://username:password@apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' - ``` - - On Debian 10: - - a. Set up the EnterpriseDB repository: - - ```text - sh -c 'echo "deb [arch=amd64] https://apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' - ``` - - b. Substitute your EnterpriseDB credentials for the `username` and `password` placeholders in the following command: - - ```text - sh -c 'echo "machine apt.enterprisedb.com login password " > /etc/apt/auth.conf.d/edb.conf' - ``` - -3. Add support to your system for secure APT repositories. - - ```text - apt-get install apt-transport-https - ``` - -4. Add the EDB signing key; When invoking the command, replace the `username` and `password` with the credentials provided by EnterpriseDB. - - ```text - wget -q -O - https://apt.enterprisedb.com/edb-deb.gpg.key | apt-key add – - ``` - -5. Update the repository metadata. - - ```text - apt-get update - ``` - -6. Install the Debian package. - - ```text - apt-get install edb-bart - ``` - - - -## Installing BART on an SLES 12 Host - -This section provides instructions for installing BART on an SLES 12 SP4 host using the zypper package manager. BART is supported on SLES SP4 and SP5 versions. - -1. Assume superuser privileges. - - ```text - sudo su - - ``` - -2. Use the following command to add the EDB repository to your SLES host: - - ```text - zypper addrepo https://zypp.enterprisedb.com/suse/edb-sles.repo - ``` - -3. Invoke the following command to refresh the metadata: - - ```text - zypper refresh - ``` - -4. Install `SUSEConnect` to register the host with SUSE to allow access to SUSE repositories: - - ```text - zypper install SUSEConnect - ``` - -5. Register the host with SUSE to allow access to SUSE repositories and replace `'REGISTRATION_CODE'` and `'EMAIL'` with your SUSE registration information: - - ```text - SUSEConnect -r 'REGISTRATION_CODE' -e 'EMAIL' - ``` - - ```text - SUSEConnect -p PackageHub/12.4/x86_64 - ``` - - ```text - SUSEConnect -p sle-sdk/12.4/x86_64 - ``` - -6. Install the following repository for PEM dependencies: - - ```text - zypper addrepo https://download.opensuse.org/repositories/Apache:/Modules/SLE_12_SP4/Apache:Modules.repo - ``` - -7. Refresh the metadata: - - ```text - zypper refresh - ``` - -8. Then, use the zypper utility to install BART: - - ```text - zypper -n install edb-bart - ``` diff --git a/product_docs/docs/bart/2.6.2/bart_inst/03_configuring_bart.mdx b/product_docs/docs/bart/2.6.2/bart_inst/03_configuring_bart.mdx deleted file mode 100644 index 0201f230692..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/03_configuring_bart.mdx +++ /dev/null @@ -1,643 +0,0 @@ ---- -title: "Configuring BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/configuring_bart.html" ---- - - - -To configure BART, you must establish the BART user account, [configure the BART host](#configuring-the-bart-host), and [configure the database server](#configuring_database_server) that will be backed up. - - - -## Establishing the BART User Account - -The BART user account is an operating system user that will run the BART command line program. The BART user account must: - -- own the BART backup catalog. -- be able to run the `bart` program and the `bart-scanner` program. -- be able to establish a SSH/SCP connection to and from each database server managed by BART. - -You can optionally use the `enterprisedb` database user as the BART user account for an Advanced Server database and `postgres` database user as the BART user account for a PostgreSQL server. If you do not wish to use an existing database user as the BART user account, you must create an operating system user to assume the role. - - - -## Configuring BART and Database Server - -As stated earlier, to configure BART, you must [configure the BART host](#configuring-the-bart-host) as well as the [database server](#configuring_database_server). The following table acts as a configuration parameter reference listing the mandatory and optional parameters with default values for `[SERVER]` as well as `[BART]` sections. - -- Parameters set in the `[BART]` section are applicable to all BART managed database servers. -- Parameters set in the `Server` section are applicable only to the specific server; the `Server` parameter setting overrides the `[BART]` section setting. - -For information about configuring BART host parameters, see the [BART Host Parameter Reference](#bart) and for information about configuring the database server parameters, see the [Database Server Parameter Reference](#server). - -| **Parameter** | **Type** | **Default** | **\[SERVER]** | **\[BART]** | -| -------------------------- | --------- | ------------------------------------------------------------ | ------------- | ----------- | -| `[BART]` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `` | Mandatory | N/A | N/A | Yes | -| `retention_policy` | Optional | `BACKUPS` | Yes | Yes | -| `wal_compression` | Optional | `Disabled` | Yes | Yes | -| `copy_wals_during_restore` | Optional | `Disabled` | Yes | Yes | -| `xlog_method` | Optional | `fetch` | Yes | Yes | -| `logfile` | Optional | `/tmp/bart.log` | N/A | Yes | -| `scanner_logfile` | Optional | `/tmp/bart_scanner.log` | N/A | Yes | -| `` | Optional | `/tmp` | N/A | Yes | -| `` | Optional | `` | N/A | Yes | -| `` | Optional | `1` | Yes | Yes | -| `` | Optional | `49152` | Yes | Yes | -| `` | Optional | `0` | Yes | Yes | -| `` | Optional | `20 seconds` | Yes | Yes | -| `` | Optional | `1` | Yes | Yes | -| `[Server Name]` | Mandatory | N/A | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `host` | Mandatory | N/A | Yes | N/A | -| `port` | Mandatory | `5444` for EPAS; `5432` for Postgres | Yes | N/A | -| `user` | Mandatory | N/A | Yes | N/A | -| `` | Optional | `BART backup catalog` | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `` | Mandatory | `enterprisedb` for EPAS

`postgres` for PostgreSQL | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `` | Optional | N/A | Yes | N/A | -| `allow_incremental_backup` | Optional | `Disabled` | Yes | N/A | -| `description` | Optional | N/A | Yes | N/A | - - - -### Configuring the BART Host - -To configure the BART host, perform the following steps on the BART host as a root user: - -**Step 1.** Navigate to the `usr/edb/bart/etc` directory and make a copy of the `bart.cfg.sample` file to create the `bart.cfg` file that will contain the parameter settings. - -**Step 2.** Confirm that the Postgres `pg_basebackup` utility program is installed on the BART host. The `pg_basebackup` utility resides in the `bin` directory under your Postgres installation. - - - -**Step 3.** Ensure the `LD_LIBRARY_PATH` environment variable includes the location of the `libpq` library. If your `libpq` library does not reside in the default location (`POSTGRES_INSTALL_HOME/lib`), you must add the library path to the `LD_LIBRARY_PATH` environment variable in the BART user account’s profile (`bash_profile`) located in `/home/`: - -```text -# .bash_profile -# Get the aliases and functions -if [ -f ~/.bashrc ]; then -. ~/.bashrc -fi -# User specific environment and startup programs -export LD_LIBRARY_PATH=/usr/edb/as11/lib:$LD_LIBRARY_PATH -``` - -**Step 4.** Create the BART backup catalog and ensure the BART user account holds privileges on the BART backup catalog. In the following example, the BART configuration file specifies `/opt/backup` as the parent directory for the BART backup catalog in the `` parameter: - -```text -[BART] - -bart_host = bartuser@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -``` - -In the following example, `bartuser` is the BART user account. The example creates and sets the ownership and permissions on the BART backup catalog: - -```text -su root -mkdir /opt/backup -chown bartuser /opt/backup -chgrp bartuser /opt/backup -chmod 700 /opt/backup -``` - -If the subdirectory does not exist, BART creates a subdirectory for each database server listed in the configuration file when you invoke the `bart` command line program. - -**Step 5.** Use your choice of editor to open the BART configuration file (located in the `usr/edb/bart/etc` directory) and edit the configuration as required. You must add the mandatory parameters to the `[BART]` section. Default values may be used for optional parameters. - -The following table describes the `[BART]` host parameters. - - - -| **Parameters/Placeholder** | **Type** | **Description** | -| -------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `[BART}` | Mandatory | Identifies the global section of the configuration file. It must be named BART. | -| `bart_host` | Mandatory | Specify the bart user name and the IP address of the bart host on which the BART utility resides. You must specify it in the form of <bart_user>@<bart_host_address>. | -| `backup_path` | Mandatory | Specify the path to the file system parent directory where all BART backups are stored. | -| `pg_basebackup_path` | Mandatory | Specify the path to the `pg_basebackup` program that you installed on the BART host. For information about `pg_basebackup` version-specific restrictions, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `wal_compression` | Optional | Set this parameter to `enabled` to compress the archived WAL files in gzip format in the BART backup catalog when the `MANAGE` subcommand is invoked. By default it is set to `disabled`. The gzip compression program must be in the BART user account’s `PATH` and the WAL compression setting must not be enabled for those database servers where you need to take incremental backups. | -| `copy_wals_during_restore` | Optional | Set this parameter to `enabled` to copy the archived WAL files from the BART backup catalog to the `restore_path/archived_wals` directory prior to the database server archive recovery. Enabling this option helps you save time during the restore operation. Set this parameter to `disabled` (default) to retrieve the archived WAL files directly from the BART backup catalog during the database server archive recovery. During the restore operation, recovery settings will be saved in the `postgresql.auto.conf` file. The `restore_command` in the `postgresql.auto.conf` file will be determined by the value specified in the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked with the `-c` option, the archived WAL files are copied from the BART backup catalog to the `restore_path/archived_wals` directory, thus overriding any setting of the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked without the `-c` option, the value specified by the `copy_wals_during_restore` parameter is used. | -| `xlog_method` | Optional | Specify how the transaction log is collected during the execution of `pg_basebackup` through the `BACKUP` subcommand. Set `xlog_method` to `fetch` (default) to collect the transaction log files after the backup is completed. Set to `stream` to stream the transaction log in parallel with the full backup creation. | -| `retention_policy` | Optional | Set this parameter to determine when an active backup should be marked as `obsolete` when the `MANAGE` subcommand is used. You can specify the retention policy either in terms of number of backups or duration (days, weeks, or months). ` BACKUPS` (default), ` DAYS`, ` WEEKS`, or ` MONTHS` where `` is a positive integer. For information about managing backups using a retention policy, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `logfile` | Optional | Use this parameter to specify the path to the BART log file. The default log file location is `/tmp/bart.log`. The log file will be created the first time you invoke the `bart` command line program using the sample configuration file value. To change the default setting, you must delete the `bart.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a log file. | -| `scanner_logfile` | Optional | Use this parameter to specify the path to the XLOG/WAL scanner log file. The default location is `/tmp/bart_scanner.log`. The scanner log file will be created the first time you invoke the `bart_scanner` program using the sample configuration file value. To change the default setting, you must delete the `bart_scanner.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a WAL scanner log file. | -| `` | Optional | Specify the socket directory path where all BART sockets will be stored. The default directory is `/tmp`. While specifying the `bart_socket_directory` path, you must ensure that the directory exists and the BART user has the required access permissions to the directory. | -| `` | Optional | Specify a user-friendly BART socket file name. Using this option overrides the default BART socket name generated using MD5 checksum. You must shut down the bart-scanner before setting this option. You can view the `` in the `sockPath` field after starting the bart-scanner in the debug mode. This option helps in preventing the use of MD5 during the bart-scanner startup, thus making BART more compliant in FIPS mode. | -| `` | Optional | Specify the number of worker threads for copying blocks (for incremental backups) or data files (for full backup) from the database server to the `archive_path` when the `BACKUP` subcommand is invoked. The default value is `1`. The same set of worker threads are used for the compression operation when taking full backups in order to provide parallel, compressed backups when the `BACKUP` subcommand is specified with the `-z` or `-c` options. The compression operation does not apply to incremental backups. See [thread count](#thread_count) for more information. | -| `` | Optional | Specify the number of blocks of memory used for copying modified blocks from the database server to the `archive_path` when the `BACKUP` subcommand is invoked for incremental backups. The default value is 49152 blocks; each block is 8192 bytes. The maximum permitted value is 131072 blocks and the minimum permitted value is 1 block. Reduce the `` setting if the server runs out of memory while executing the `pg_read_binary_file()`. | -| `` | Optional | Specify the number of seconds after which the WAL scanner should initiate force scanning of the new WAL files. The default value is 0, which means no brute-force scanning will be started. After upgrading to the latest version of BART, users who have set this parameter to a non-default value may see increased CPU consumption on the part of bart-scanner. If this is an issue, consider increasing the configured value of `scan_interval` parameter, or removing the setting if it is not required. | -| `` | Optional | Specify the number of seconds to wait for MBM files before timing out; this parameter is applicable only for incremental backup. You must set the `scan_interval` to a value significantly less than the MBM scan timeout. The default value is 20 seconds. The `mbm_scan_timeout` parameter value must be greater than 0. If the value is 0 or negative, then an error will be displayed during an incremental backup. | -| `` | Optional | Specify the number of parallel worker processes required to stream the modified blocks of an incremental backup to the restore host. The default value is 1. | - - - -**Thread Count** - -If the `BACKUP` subcommand is invoked with the `--thread-count` option, then the number of worker threads specified by this option overrides any setting of the `thread_count` parameter in the BART configuration file. If the `BACKUP` subcommand is invoked without the `--thread-count` option, then the following determines the number of worker threads used: - -- The setting of the `thread_count` parameter in the server section of the BART configuration file overrides the setting of `thread_count` in the global section for that particular database server. -- If omitted in the server section, the setting of `thread_count` in the global section is used. -- If the `thread_count` parameter is not specified in either section, the default is 1. -- When taking a full backup, if the `thread count` in effect is only 1, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. - -`` will not be effective if the backup is taken on a standby server. - -If parallel backup is run with `N` number of worker threads, then it will initiate `N + 1` concurrent connections with the server. - -**Step 6** Invoke the `CHECK-CONFIG` subcommand, omitting the `-s` option to check the parameter settings in the BART configuration file. It should return the current BART version. - -```text -bart CHECK-CONFIG -``` - -The `CHECK-CONFIG` subcommand displays an error message if the required configuration is not properly set. You need to check the logfile to fix this. - - - -### Configuring the Database Server - -To configure the database server, you must: - -1. [Authorize SSH/SCP access without a password prompt](#authorizing_ssh_scp_access). -2. [Create and configure a replication database user](#setting_up_a_replication_database_user). -3. [Adding the database server to the configuration file (server section)](#adding_a_database_server). -4. [Enable WAL archiving of the server](#enabling_wal_archiving). -5. [Verify the server configuration settings](#verifying_configuration_settings). - -The following section will walk you through the configuration process. - -!!! Note - You must authorize SSH/SCP access and set up a replication database user before restarting the database server with WAL archiving enabled. - - - -**Authorizing SSH/SCP Access** - -BART uses the Secure Shell (`ssh`) and Secure Copy (`scp`) Linux utility programs to copy the backup and WAL files from the BART managed database servers to the BART host as well as to restore backups. - -- The client/server `ssh` and `scp` commands must not prompt for a password when establishing a connection with the target server (the server to which a passwordless connection is being made). -- A passwordless connection uses *authorized public keys* (public key of a client user account) to authenticate with the target server. -- You must add the public key of each client user account to the target user account’s authorized public keys list on the target server. - -For BART usage, there are two scenarios that require a passwordless SSH/SCP connection: - -- When connecting from each BART managed database server (SSH/SCP client) to the BART host (target SSH/SCP server) to support WAL archiving as implemented by the `archive_command` parameter. - - In this case, the database server user account should generate the public key file (`id_rsa.pub`) with the `ssh-keygen –t rsa` command on the database server host. - - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the BART host. The `authorized_keys` file is in the BART user account’s home directory. -- When connecting from the BART host (SSH/SCP client) to each BART managed database server (target SSH/SCP server) for taking incremental backups and for supporting restoration of the full backup, the archived WAL files, and the modified blocks, which occurs when the BART `RESTORE` subcommand is given. - - In this case, the BART user account should generate the public key file (`id_rsa.pub`) with the `ssh-keygen –t rsa` command on the BART host. - - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the database server host. The `authorized_keys` file is in the home directory of the user account that owns the directory where the database backup is to be restored. -- If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -See the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/) to view examples of creating a passwordless connection. - -**Enabling Public Key Authentication** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. - -1. In the SSH server daemon configuration file (`sshd_config`) located in the `/etc/ssh`, set the `PubkeyAuthentication` parameter to `yes`. -2. Reload the configuration file: - -```text -service sshd reload -``` - -If you get any SSH or SCP errors, examine the `/var/log/secure` log file. - -**Creating a Passwordless Connection** - -The following general instructions will walk you through generating a client’s public key file, creating the target server’s authorized public keys file, and creating a passwordless connection. - -**Step 1.** On the client system, log in as the user account that will be initiating the SSH or SCP connection. - -**Step 2.** Navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one and assign the required privileges to the user. - -**Step 3.** Generate the public key file with the following command. Accept all prompted defaults and do not specify a passphrase when prompted for one. - -```text -ssh-keygen –t rsa -``` - -The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -**Step 4.** While logged into the client where you just generated the public key file, use `SCP` to make a temporary copy of it on the target server: - -```text -scp ~/.ssh/id_rsa.pub @:tmp.pub -``` - -**Step 5.** Navigate into the target user account’s home directory and check for an existing `.ssh` subdirectory. If it does not exist, create one and assign the required privileges to the user. - -**Step 6.** Append the temporary, client’s public key file, `tmp.pub`, to the `authorized_keys` file. If an `authorized keys` file does not exist, create a new file, but do not completely replace any existing `authorized keys` file. - -```text -cat tmp.pub >> ~/.ssh/authorized_keys -``` - -Make sure the `authorized_keys` file is only accessible by the file owner and not by groups or other users. If the `authorized_keys` file does not have the required permission setting or it was newly created, change the file permissions as follows: - -```text -chmod 600 ~/.ssh/authorized_keys -``` - -**Step 7.** Delete the temporary public key file: - -```text -rm tmp.pub -``` - -Now, when logged into the client system as `user` there should be no prompt for a password when commands such as the following is given: - -```text -ssh target_user@host_address -``` - - - -**Setting up a Replication Database User** - -For each database server that is to be managed by BART, a database user must be chosen to serve as the *replication database user*. The replication database user sets the Postgres `archive_command` configuration parameter when the `INIT` subcommand in invoked and creates backups when the `BACKUP` subcommand is invoked. The replication database user must be a `superuser`. - -When executed with the PSQL client, the following PostgreSQL command creates a superuser to be the replication database user: - -`CREATE ROLE repuser WITH LOGIN SUPERUSER PASSWORD 'password';` - -The `pg_hba.conf` file must minimally permit the replication database user to have access to the database. - -In the following example, the `pg_hba.conf` file permits the `repuser` (replication database user) to have access to the `template1` database. The IP address from which `repuser` has access to `template1` database is the location of the BART host: - -**For pg_basebackup only:** If `pg_basebackup` is to be used for taking any backups (such as for standby servers), the replication database user must also be included in the `pg_hba.conf` file as a `replication` database connection as shown by the last entry in the following example. - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 repuser 192.168.2.22/32 md5 -host all enterprisedb 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -host replication repuser 192.168.2.22/32 md5 -``` - -The replication database user must be specified for the `user` parameter in the BART configuration file for the database server as shown in the following example: - -```text -[ACCTG] -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -description = "Accounting" -``` - -There must be no password prompt when connecting to the database server with the replication database user. There are several ways to permit this; one recommended method is to use a `.pgpass` file located in the BART user account’s home directory. - -For example, if `bartuser` is the BART user account, then the `.pgpass` file located in the `/home/bartuser` directory must contain the following entry: - -`192.168.2.24:5444::repuser:password` - -When `bartuser` invokes a BART backup, the password for the replication database user, `repuser`, is obtained from the `.pgpass` file of `bartuser` to connect to the database server running at `192.168.2.24` on `port 5444`. - -The `.pgpass` file must contain an entry for each BART managed database server and its corresponding replication database user and password. - - - -**Adding a Database Server to the BART Configuration File** - -To manage the backup and recovery of a database server, you must add entries to the `[SERVER]` section of the BART configuration file, which is located in `/etc` directory. - - - -*Database Server Parameter Reference* - -Set the following parameters in the \[`SERVER`] section of the BART configuration file. The parameter setting in the \[`SERVER`] section overrides the setting in the global \[`BART`] section for that particular database server. If omitted, the default value will be used. - -For each cluster serviced by BART, the following parameters are mandatory: - -```text -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -``` - -!!! Note - The port parameter setting is required only if the database server listens on a port other than the default (for example if Postgres listens on a port other than 5432). - -The following table describes the database server parameters. - - - - - - - - - -| **Parameters/Placeholder** | Type | **Description** | -| --------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `[ServerName]` | Mandatory | Specify the server name that you want to backup using BART. It is not case-sensitive when referenced with BART subcommand options. A lowercase conversion of this name is used to create a subdirectory in the BART backup catalog for storing the backups and WAL files for this database server (for eg., epas12). | -| `` | Optional | Specify a [template](#backup_name_template) for user-defined, friendly names that will be assigned to the backups of the database server. The maximum permitted length of backup name is 49 characters. The `` parameter can be overridden by the `--backup-name` option of the `BACKUP` subcommand. If this parameter is omitted from the BART configuration file, and the `--backup-name` option with a user-defined name is not specified with the `BACKUP` subcommand, then the backup can only be referenced in BART subcommands by the BART assigned, integer backup identifier. | -| `host` | Mandatory | Specify the IP address of the database server to be configured for backup. | -| `port` | Mandatory | Specify the port number identifying the database server instance (that is, the relevant database cluster) to be backed up. The default port number for EPAS is `5444` and for Postgres it is `5432`. The port parameter setting is only required if the database server listens on a port other than the default value. | -| `User` | Mandatory | Specify the replication database user name used by BART to establish the connection to the database server for full backups. See [Setting up a Replication Database User](#setting_up_a_replication_database_user) for more information. | -| `` | Optional | Specify the path where archived WAL files will be stored. The default location is the BART backup catalog (`//archived_wals`). | -| `` | Optional | When the `INIT` subcommand is used, the content and variables specified in the BART `` result in the archive command string to be generated into the `Postgres archive_command` parameter in the `postgresql.auto.conf` file. To configure the BART `` parameter, enclose the command string within single quotes ('). If you do not specify the `` parameter in the configuration file, the default setting is taken as `'scp %p %h:%a/%f'`. See [Archive Command Auto Configuration](#archive_command_auto_configuration) for information about variables. The BART `` parameter in the BART configuration file, and the Postgres `` parameter in the `postgresql.conf` file (or the `postgresql.auto.conf` file) refer to two different parameters that are to be set in different manner. | -| `` | Mandatory | Specify the Linux operating system user account that owns the database cluster. This is typically `enterprisedb` for Advanced Server database clusters installed in the Oracle compatible mode, or `postgres` for Advanced Server database clusters installed in the PostgreSQL compatible mode and PostgreSQL database clusters. | -| `` | Optional | Specify the IP address of the remote server to which a backup is to be restored. Specify this parameter in the form of `@`. `` is the user account on the target database server host that accepts a passwordless SSH/SCP login connection and owns the directory where the backup is to be restored. `` is the IP address of the remote host. For restoring a backup to a remote host or for restoring any backup where `` and the BART user account are not the same users, either this parameter must be set or it may be specified with the `-r` option with the BART `RESTORE` subcommand. | -| `` | Optional | Specify path to which tablespaces are to be restored in the format `OID = `; If the backup is to be restored to a remote host specified by the `` parameter, then the tablespace paths must exist on the remote host. | -| `allow_incremental_backups` | Optional | Set this parameter to `enabled` to enable use of the WAL scanner and permit taking incremental backups when the `BACKUP` subcommand is invoked with the `--parent` option. Set it to `disabled` (default) to disallow incremental backups and thus permit only full backups. For information about using the `BACKUP` subcommand and running the WAL scanner, please see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | -| `Description` | Optional | Specify the description that will be used to identify the database server. | - -For information regarding the following parameters, see [configuring the BART host](#configuring-the-bart-host). - -- `retention_policy` -- `xlog_method` -- `wal_compression` -- `copy_wals_during_restore`. -- `thread_count`. -- `batch_size`. -- `scan_interval`. -- `mbm_scan_timeout`. -- `workers` - - - -**Backup Name Template** - -- The template is an alphanumeric string that may include the following variables that will be replaced with the timestamp values when the backup is taken: - - - `%year` to be replaced by 4-digit year - - `%month` to be replaced by 2-digit month - - `%day` to be replaced by 2-digit day - - `%hour` to be replaced by 2-digit hour - - `%minute` to be replaced by 2-digit minute - - `%second` to be replaced by 2-digit second - -- To include a percent sign (`%`) as a character in the backup name, specify `%%` in the template. - -- Do not enclose the template string in quotes even if you want the template to include space characters, otherwise the enclosing quotes are stored as part of the backup name. However, when referenced with the `-i` option by BART subcommands use of space characters in the backup name requires enclosing the backup name in quotes. - -The following example shows the configuration settings of three database servers: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute:%second -archive_command = 'cp %p %a/%f' -allow_incremental_backups = enabled -retention_policy = 8 BACKUPS -description = "Accounting" - -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -description = "Marketing" - -[HR] - -host = 127.0.0.1 -port = 5432 -user = postgres -cluster_owner = postgres -retention_policy = 4 DAYS -description = "Human Resources" -``` - - - -**Enabling WAL Archiving** - -WAL archiving must be enabled for the database server for which BART is to perform backup and recovery management. - -- The WAL Archiving Configuration section describes the manual WAL archiving configuration process. -- The Archive Command Auto Configuration section describes an automated WAL archiving process. - -*WAL Archiving Configuration* - -Set the following configuration parameters in the `postgresql.conf` file to enable WAL archiving - -- Set `wal_level` to `replica` or higher. -- Set `archive_mode` to `on`. -- Set the PostgreSQL `archive_command` parameter to copy the WAL files to the `archive_path`. The `archive_command` configuration parameter mentioned here is located in the `postgresql.conf` file; the PostgreSQL `archive_command` parameter is used in a different manner than the BART [archive_command](#archive_command). -- Set `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (the setting must be a minimum of 2). See [Configuring the BART host](#configuring-the-bart-host) for information about the `xlog_method` parameter. - -For detailed information about WAL archiving, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). - -The `ARCHIVE PATH` field displayed by the BART `SHOW-SERVERS` subcommand displays the full directory path where the WAL files should be copied as specified in the `archive_command` configuration parameter in the `postgresql.conf` file: - -```text --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : none -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -``` - -The parameter settings in the following example will copy the WAL files to a directory named `/opt/backup/acctg/archived_wals` on the BART host located at `192.168.2.22` as the `bartuser` user account. Using the `bartuser` account ensures that the operation will have sufficient permissions to copy to the BART backup catalog owned by `bartuser`. - -```text -archive_mode = on # allows archiving to be done - # (change requires restart) -archive_command = 'scp %p bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f' - # command to use to archive a logfile segment - # placeholders: %p = path of file to archive - # %f = file name only -... - -max_wal_senders = 1 # max number of walsender processes - # (change requires restart) -``` - -The database server must be restarted in order to initiate WAL archiving, but do not do so until you have verified that the full path of the BART backup catalog has been created by a prior BART subcommand or the archive operation will fail. - -Start the WAL scanner by executing the following command: - -```text -./bart-scanner -``` - - - -*Archive Command Auto Configuration* - -To enable WAL archiving: - -- In the `postgresql.conf` file, set the `wal_level` to `replica` or higher, `archive_mode` to `on`, and `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server as determined in the BART configuration file, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (that is, the setting must be a minimum of `2`). See [Configuring the BART host](#configuring-the-bart-host) for information on the `xlog_method` parameter. - -- Configure the Postgres `archive_command` parameter automatically with the `INIT` subcommand and restart the database server when you are ready to initiate WAL archiving. The `INIT` subcommand invokes the Postgres `ALTER SYSTEM` command to set the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME data directory`. For additional information about the `INIT` subcommand, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - - The archive command string that the `INIT` subcommand generates into the `postgresql.auto.conf` file is determined by the parameter setting of the BART `archive_command` parameter in the server section of the BART configuration file. If the BART `archive_command` parameter is not set in the server section for a given database server, the command string that is configured uses the following default format: - - `'scp %p %h:%a/%f'` - - The following table describes these variables: - -| **Variable** | **Description** | -| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `%p` | The path of the file to archive used by the Postgres archiving process. | -| `%h` | Will be replaced by the `@` as specified in the <bart_host> parameter setting. | -| `%a` | Will be replaced by the BART `archived_wals` directory as specified in the [archive path](#archive_path) parameter setting. If the `` is not specified, then the default directory is `//archived_wals`. `` is the lowercase conversion of the database server name. | -| `%f` | The archived file name used by the Postgres archiving process. | - -The placeholders `%h` and `%a` are replaced by the `INIT` subcommand when creating the archive command string. The placeholders `%p` and `%f` are not replaced by the `INIT` subcommand, but are kept as given to be used by the Postgres archiving process. - -For example, to use the default archive command format, the BART configuration file contains the following settings where the BART `archive_command` parameter is omitted from the server section for `ACCTG`: - -```text -[BART] - -bart_host= bartuser@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -description = "Accounting" -``` - -The `INIT` subcommand is invoked by BART user account `bartuser` as follows: - -```text -[bartuser@localhost ~]$ bart INIT -s acctg -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -``` - -If the BART backup catalog directory is not already complete, it will be completed. - -The resulting archive command string in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME/data directory` appears as follows: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f' -``` - -Run the `INIT` subcommand with the `-o` option to override any existing `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file. In addition, the `-o` option must be used to generate the command string if the `archive_mode` is set to off even if there are no existing settings of the `archive_command` in the `postgresql.conf` or `postgresql.auto.conf` files. - -In this example, the following BART configuration file is used with an explicit setting of the BART `archive_command` parameter: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -The `INIT` subcommand is invoked by BART user account `enterprisedb` as follows: - -```text --bash-4.1$ bart INIT -s acctg -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -``` - -The resulting Postgres `archive_command` parameter in the `postgresql.auto.conf` file appears as follows: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup/acctg/archived_wals/%f' -``` - -When the database server has been restarted, the `ARCHIVE COMMAND` field of the `SHOW-SERVERS` subcommand displays the active Postgres archive command as shown by the following example: - -```text --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : none -DISK UTILIZATION : 48.00 MB -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE SCOMMAND : `cp %p /opt/backup/acctg/archived_wals/%f` -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -``` - - - -**Verifying Configuration Settings** - -To verify the parameter settings of the database server specified, execute tthe `CHECK-CONFIG` subcommand with the `–s` option: - -```text -bart CHECK-CONFIG [ –s server_name ] -``` - -The `CHECK-CONFIG` subcommand confirms the following: - -- The `cluster_owner` parameter is set to the user account owning the database cluster directory. -- A passwordless SSH/SCP connection is set between the BART user and the user account specified by the `cluster_owner` parameter. -- The BART `user` parameter specifies a database superuser. -- The BART `user` has access to the backup directory catalog. -- The `pg_hba.conf` file contains a replication entry for the database superuser specified by the BART `user` parameter. -- The `archive_mode` parameter in the `postgresql.conf` file is enabled. -- The `archive_command` parameter in the `postgresql.auto.conf` or the `postgresql.conf` file is set. -- The `allow_incremental_backups` parameter in the BART configuration file is enabled for database servers for which incremental backups are to be taken. -- Archiving of WAL files to the `archive_path` is in process. -- The WAL scanner program is running. - -After configuring the BART host and the database server(s), you can start using BART. For information about using BART, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). diff --git a/product_docs/docs/bart/2.6.2/bart_inst/04_upgrading_bart.mdx b/product_docs/docs/bart/2.6.2/bart_inst/04_upgrading_bart.mdx deleted file mode 100644 index 7ea815ecd15..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/04_upgrading_bart.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Upgrading BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/upgrading_bart.html" ---- - - - -This section outlines the process of upgrading BART from an existing version to the latest version. - -**Upgrade Restrictions** - -The following restrictions apply with regard to previous BART versions. - -- You can take incremental backups using the latest version only when the parent backup (full or incremental backup) has also been taken with the latest version. -- Using the latest version, you can restore incremental backups that are taken only with the latest version of BART. However, using the latest version you can restore full backups that were taken with older versions. - - - -## Upgrading from Older Versions of BART - -Perform the following steps to upgrade from older versions of BART to the latest version: - -**Step 1:** Assume the identity of the BART user account and invoke the following command to stop the BART WAL scanner program (`bart-scanner`): - -```text -bart-scanner STOP -``` - -**Step 2:** As the `root` user, upgrade to the latest BART version with the `yum upgrade` command. - -- To upgrade the BART RPM package directly from the *EDB Yum Repository* website, specify only the package name: - - On CentOS 7: - - ```text - yum upgrade edb-bart - ``` - - You can also use a downloaded RPM package file to upgrade. To use a downloaded BART RPM package file to upgrade, use the `yum` command, specifying the complete RPM package file name: - - ```text - yum upgrade edb-bart-x.y.z rhel7.x86_64.rpm - ``` - - Where x denotes the major version of BART, and y and z denotes the minor version. - - On a Debian or Ubuntu Host: - - ```text - apt-get upgrade edb-bart - ``` - - On a SLES Host: - - ```text - zypper update edb-bart - ``` - -**Step 3:** Repeat the process described in this section to upgrade to the latest BART version on each remote hosts where an incremental backup will be restored. - -For additional information about restoration of incremental backups on remote hosts, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -**Step 4:** If the `bart --version` command returns an error stating the `PATH` is not available after switching from `root` user to another BART user account, adjust the setting of the `PATH` environment variable to include the location of the BART x.y.z (x denotes the major version of BART, and y and z denotes the minor version) executable (the `bin` subdirectory) in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - -- The BART user account on the BART host. -- The remote user account on the remote host to which incremental backups are to be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The `PATH` setting should be the same as set for BART x.y.z since all versions use `/usr/edb/bart/bin`. - -!!! Note - After upgrading to the latest BART version, you must take a new full backup of your system before performing an incremental backup. - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.2/bart_inst/05_uninstalling_bart.mdx b/product_docs/docs/bart/2.6.2/bart_inst/05_uninstalling_bart.mdx deleted file mode 100644 index 8374221ef88..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/05_uninstalling_bart.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Uninstalling BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/uninstalling_bart.html" ---- - - - -This section walks you through uninstalling BART. - -## Uninstalling BART on a RHEL/CentOS Host - -To uninstall BART on a RHEL/CentOS host, assume the identity of the `root` user and invoke the following command: - -On RHEL/CentOS 7: - -```text -yum remove edb-bart -``` - -On RHEL/CentOS 8: - -```text -dnf remove edb-bart -``` - -Uninstalling BART does not delete the backup files and archived WAL files that reside in the BART backup catalog. To permanently delete the backup files and archived WAL files in the BART backup catalog (`/opt/backup`), use one of the following commands: - -- `rm –rf /opt/backup` -- BART `DELETE` subcommand - -For information about the BART `DELETE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -## Uninstalling BART on an SLES 12 Host - -To uninstall BART on an SLES 12 host, assume the identity of the `root` user and invoke the following command: - -```text -zypper remove edb-bart -``` - -## Uninstalling BART on a Debian/Ubuntu Host - -To uninstall BART on a Debian or Ubuntu host, invoke the following command: - -```text -apt-get remove edb-bart -``` diff --git a/product_docs/docs/bart/2.6.2/bart_inst/images/EDB_logo.png b/product_docs/docs/bart/2.6.2/bart_inst/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.2/bart_inst/images/edb.png b/product_docs/docs/bart/2.6.2/bart_inst/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.2/bart_inst/images/edb_logo.svg b/product_docs/docs/bart/2.6.2/bart_inst/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.2/bart_inst/images/edblogo.png b/product_docs/docs/bart/2.6.2/bart_inst/images/edblogo.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/images/edblogo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.2/bart_inst/index.mdx b/product_docs/docs/bart/2.6.2/bart_inst/index.mdx deleted file mode 100644 index d1abcfedd20..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_inst/index.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -navTitle: Installation Guide -title: "EDB Postgres Backup and Recovery Installation Guide" -legacyRedirects: - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/requirements_overview.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/index.html" ---- - -This guide provides information about how to install and configure the EDB Backup and Recovery Tool (BART) 2.6. - - - -## Requirements Overview - -### Supported Platforms and Database Versions - -- To view a complete list of supported platforms, visit the [EDB website.](https://www.enterprisedb.com/services-support/edb-supported-products-and-platforms) - -!!! Note - BART 2.6 is no longer supported on CentOS/RHEL/OEL 6.x platforms. It is strongly recommended that EDB products running on these platforms be migrated to a supported platform. - -- BART supports the following database versions: - - - Advanced Server versions 9.6, 10, 11, 12, and 13. - - PostgreSQL versions 9.6, 10, 11, 12, and 13. - -### Software Requirements - -You require the following components to install BART. - -- BART Host Components - Use EDB packages to add BART host components; see [Installing BART](02_installing_bart/#installing-bart) for information about how to install these components. - -- Additional Components - In addition to the BART host components, the following components are required: - - - The [Secure Shell (SSH) server daemon and Secure Copy (SCP) client programs](03_configuring_bart/#authorizing_ssh_scp_access) must be enabled and activated on the BART host as well as on the remote database server hosts on which BART will be managing backup and recovery. - - BART uses the `pg_basebackup` utility program when taking full backups. - -### Limitation - -BART supports taking only a full backup of standby servers; it does not support taking incremental or parallel backups of standby servers. diff --git a/product_docs/docs/bart/2.6.2/bart_qs_7/images/EDB_logo.png b/product_docs/docs/bart/2.6.2/bart_qs_7/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_7/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.2/bart_qs_7/images/edb.png b/product_docs/docs/bart/2.6.2/bart_qs_7/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_7/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.2/bart_qs_7/images/edb_logo.svg b/product_docs/docs/bart/2.6.2/bart_qs_7/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_7/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.2/bart_qs_7/images/image2.png b/product_docs/docs/bart/2.6.2/bart_qs_7/images/image2.png deleted file mode 100644 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_7/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.6.2/bart_qs_7/index.mdx b/product_docs/docs/bart/2.6.2/bart_qs_7/index.mdx deleted file mode 100644 index 204cd9ebc2a..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_7/index.mdx +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: "Quick Start Guide for RHEL/CentOS 7" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/index.html" ---- - -This tutorial demonstrates using `yum` to [install](#installing) and [configure](../bart_qs_8/#configuring) Backup and Recovery Tool (BART) 2.6 on a CentOS 7 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. - -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - -- BART is tested with the following database versions: - - - Advanced Server - 9.6, 10, 11, 12, and 13. - - PostgreSQL - 9.6, 10, 11, 12, and 13. - - - -**Installing BART** - -The following steps describe installing BART on CentOS 7.x OS using `yum`. - -1. Assume superuser privileges and use `yum` to create the repository configuration file: - - ```text - yum install -y https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Create an EDB user account to request credentials to the EDB repository; for a user account visit the [EnterpriseDB website](https://www.enterprisedb.com/repository-access-request). - -3. Use your choice of editor to open the repository configuration file (named `edb.repo`, located in `/etc/yum.repos.d`), and set the `enabled` parameter value to `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the username and password of a registered EnterpriseDB user. - -4. Update the cache: - - ```text - yum makecache - ``` - -5. Install an Advanced Server or PostgreSQL database server. - - To install Advanced Server, execute the following command: - - ```text - yum -y install edb-as12-server - ``` - - Use sudo to assume the identity of the `enterprisedb` database superuser - - ```text - sudo su - enterprisedb - ``` - - Create an Advanced Server cluster named `acctg` on listener port `5444`: - - ```text - /usr/edb/as12/bin/initdb -D /var/lib/edb/as12/acctg - ``` - - As the `enterprisedb` user, start the cluster: - - ```text - /usr/edb/as12/bin/pg_ctl start -D /var/lib/edb/as12/acctg - ``` - - You can check the status of the cluster with the following command: - - ```text - /usr/edb/as12/bin/pg_ctl status -D /var/lib/edb/as12/acctg - ``` - - !!! Note - The BART host server is not required to have an Advanced Server or PostgreSQL installation, but must include a copy of the Postgres `libpq` library, the `pg_basebackup` utility program, and Boost Libraries 1.53 version for CentOS 7. - -6. If you do not already have the `pg_basebackup` program installed on the BART host, you can use the following command to install a limited number of files that include the `pg_basebackup` program: - - ```text - yum install edb-as-server-client - ``` - - Where <xx> is the Advanced Server version. - -7. As a root user, execute the following command to install BART: - - ```text - yum install edb-bart - ``` - -BART (the bart program and bart-scanner) is installed in the `/usr/edb/bart/bin` directory, referred to as ``. Repeat the installation process described in this section to install BART on all remote hosts where incremental backups are to be restored. - - - -**Configuring BART** - -Before configuring BART, establish the BART user account (the operating system user) that will run the BART command line program. Then, to configure the BART host and each database server that is to be managed by BART, perform the following steps: - -1. Assume superuser privileges, create the directory that will hold the BART backup catalog, and assign its ownership (with restrictive privileges) to the BART user account: - - In this example, `bartuser` is the BART user account and `/opt/backup` is the BART backup catalog. - - ```text - su root - mkdir /opt/backup - chown bartuser /opt/backup - chgrp bartuser /opt/backup - chmod 700 /opt/backup - ``` - -2. Navigate to the `/usr/edb/bart/etc` directory and copy the `bart.cfg.sample` file to create the BART configuration file (`bart.cfg`): - - ```text - cp bart.cfg.sample bart.cfg - ``` - -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - - Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. - - In the following example, only mandatory parameters are set: - - ```text - [BART] - bart_host= bartuser@192.168.169.199 - backup_path = /opt/backup - pg_basebackup_path = /usr/edb/as12/bin/pg_basebackup - - [EPAS12] - host = 127.0.0.1 - user = repuser - cluster_owner = enterprisedb - ``` - -The following table describes only mandatory parameters: - -| **Parameters/Placeholder** | **Section** | **Description** | -| -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bart_host` | `[BART]` | Use this field to specify the BART user and the IP address of the host on which the BART utility is installed. Specify the value in the form of `@`. | -| `backup_path` | `[BART]` | Use this field to specify the path where all BART backups and archived WAL files will be stored. Ensure the BART user account holds privileges to create subdirectories and files within the location specified in the `backup_path` parameter. The default `backup_path` is BART backup catalog (`/opt/backup`). | -| `pg_basebackup_path` | `[BART]` | Use this field to specify the path to the pg_basebackup utility (`/usr/edb/as/bin/pg_basebackup`). | -| `[ServerName]` | `[ServerName]` | Specify the name of the database server to be backed up (for example, \[EPAS12]). | -| `host` | `[ServerName]` | Specify the IP address of the database server to be configured for backup. | -| `user` | `[ServerName]` | Specify the replication database user name used by BART to establish the connection to the database server for full backups. | -| `cluster_owner` | `[ServerName]` | Specify the Linux operating system user account that owns the database cluster. | - -4. As a BART user, navigate to `/usr/edb/bart/bin` and invoke the following subcommand (omitting the `-s` option) to verify the \[BART] section parameter settings: - - ```text - bart CHECK-CONFIG - ``` - -5. Authorize [SSH/SCP access](../bart_qs_8/#passwordless) between the server and the BART host without a password prompt. - -6. Create a [replication database user](../bart_qs_8/#replication) for each database server that BART manages. - -7. To enable continuous WAL archiving for any database server for which BART is to perform a backup, modify the `postgresql.conf` file, setting: - - - `wal_level` to `replica` or higher (for Postgres 9.6 or later) - - `archive_mode` to `on` - - `archive_command` (if it is not set in the `bart.cfg` file) - - `max_wal_senders` to a value high enough to leave at least one session available for the backup. - - After setting the parameters, restart the database server. - -8. To start the WAL scanner, navigate to `/usr/edb/bart/bin` as a BART user and execute the following command: - - ```text - ./bart-scanner - ``` - -9. If you are using the default `archive_command`, then navigate to `/usr/edb/bart/bin` as a BART user, run the `INIT` subcommand without the `-o` option, and restart the database server: - - ```text - bart INIT [ -s { | all } ] - ``` - - Where `` is the name of the database server to be backed up. - - If you have customized the `archive_command` setting in the `bart.cfg` file, run the `INIT` subcommand with the `-o` option to override any existing Postgresql `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file, and restart the database server. - - ```text - bart INIT [ -s { | all } ] [ -o ] - ``` - -10. To verify the database server parameter settings, as a BART user navigate to `/usr/edb/bart/bin` and invoke the `CHECK-CONFIG` subcommand with the -s option: - - ```text - bart CHECK-CONFIG [ -s ] - ``` - - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide*, available at the [EDB website](/bart/latest/bart_user/). - - - -**Creating a Passwordless Connection** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. You must create a passwordless connection between the BART host (SSH/SCP client) and the database server (target SSH/SCP server), as well as a passwordless connection between the database server (SSH/SCP client) and the BART host (target SSH/SCP server). - -1. Log in as the user account on the BART host that will be initiating the SSH or SCP connection and navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one with the required privileges. - -2. As a root user navigate to `/usr/edb/bart`, open the `/etc/ssh/sshd_config` file and set the `PubkeyAuthentication` parameter to `yes`. - -3. Reload the configuration file: - - ```text - service sshd reload - ``` - - If you get any SSH or SCP errors, examine the log file (`/var/log/secure`). - -4. As a BART user, use the following command to generate the public key file; you can accept the default responses: - - ```text - ssh-keygen -t rsa - ``` - - The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -5. Use `SCP` to make a temporary copy of the public key file on the target server: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -6. As a `target_user`, log into the target server using `ssh target_user@host_address` command and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges. - -7. Append the client’s temporary public key file, `tmp.pub`, to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - - If an `authorized_keys` file does not exist, create a new file, but be careful not to completely replace any existing `authorized_keys` file. - -8. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -9. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the BART host as a user, there should be no prompt for a password when you are connecting to the target database server: - - ```text - ssh target_user@database_server_address - ``` - -**Creating a Passwordless Connection Between the Database Server and the BART Host** - -If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). - -Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. - -1. On the database server, navigate into the target user account’s home directory to check for an existing `.ssh` subdirectory. If it does does not exist, create one in the user account’s home directory with the required privileges. - -2. As a database server user, generate the public key file: - - ```text - ssh-keygen -t rsa - ``` - -3. Create a temporary copy of the public key file: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -4. As a target user, log into the BART host and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges: - - ```text - ssh target_user@host_address - ``` - -5. Append the temporary, client’s public key file to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - -If an `authorized_keys` file does not exist, create a new file, but do not completely replace any existing `authorized_keys` file. - -6. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -7. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the database server as a user, there should be no prompt for a password when you are connecting to the BART host: - - ```text - ssh bart_user@bartip_address - ``` - - - -**Creating a Replication Database User** - -1. To create a replication database user (a superuser), connect to the database server with the psql client, and invoke the following PostgreSQL command: - - ```text - CREATE ROLE WITH LOGIN SUPERUSER PASSWORD ''; - ``` - -2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. - -3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. - -4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.6.2/bart_qs_8/images/EDB_logo.png b/product_docs/docs/bart/2.6.2/bart_qs_8/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_8/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.2/bart_qs_8/images/edb.png b/product_docs/docs/bart/2.6.2/bart_qs_8/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_8/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.2/bart_qs_8/images/edb_logo.svg b/product_docs/docs/bart/2.6.2/bart_qs_8/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_8/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.2/bart_qs_8/images/image2.png b/product_docs/docs/bart/2.6.2/bart_qs_8/images/image2.png deleted file mode 100644 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_8/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.6.2/bart_qs_8/index.mdx b/product_docs/docs/bart/2.6.2/bart_qs_8/index.mdx deleted file mode 100644 index 66f1039827d..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_qs_8/index.mdx +++ /dev/null @@ -1,317 +0,0 @@ ---- -title: "Quick Start Guide for RHEL/CentOS 8" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/index.html" ---- - -This tutorial demonstrates using the `dnf` command to install and configure the EDB Backup and Recovery Tool (BART) 2.6 on a CentOS 8 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures and has administrative privileges on the host. - -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - -- BART is tested with the following database versions: - - - Advanced Server - 9.6, 10, 11, 12, and 13. - - PostgreSQL - 9.6, 10, 11, 12, and 13. - -**Installing BART** - -The following steps describe installing BART on CentOS 8.x OS. - -1. Assume superuser privileges and use `dnf` to create the repository configuration file: - - ```text - dnf install -y https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm - ``` - -2. Create an EDB user account to request credentials to the EDB repository; for a user account visit the [EnterpriseDB website](https://www.enterprisedb.com/repository-access-request). - -3. Use your choice of editor to open the repository configuration file (named `edb.repo`, located in `/etc/yum.repos.d`), set the `enabled` parameter value to `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the username and password of a registered EnterpriseDB user. - -4. Update the cache: - - ```text - dnf makecache - ``` - -5. Install an Advanced Server or PostgreSQL database server. - - To install Advanced Server, execute the following command: - - ```text - dnf -y install edb-as12-server - ``` - - Use sudo to assume the identity of the `enterprisedb` database superuser: - - ```text - sudo su - enterprisedb - ``` - - Create an Advanced Server cluster named `acctg` on listener port `5444`: - - ```text - /usr/edb/as12/bin/initdb -D /var/lib/edb/as12/acctg - ``` - - As the `enterprisedb` user, start the cluster: - - ```text - /usr/edb/as12/bin/pg_ctl start -D /var/lib/edb/as12/acctg - ``` - - You can check the status of the cluster with the following command: - - ```text - /usr/edb/as12/bin/pg_ctl status -D /var/lib/edb/as12/acctg - ``` - - !!! Note - The BART host server is not required to have an Advanced Server or PostgreSQL installation, but must include a copy of the Postgres `libpq` library, the `pg_basebackup` utility program, and Boost Libraries 1.66 version for CentOS 8. - -6. If you do not already have the `pg_basebackup` program installed on the BART host, you can use the following command to install a limited number of files that include the `pg_basebackup` program: - - ```text - dnf install edb-asxx-server-client - ``` - -7. As a root user, use the following command to install the BART RPM package: - - ```text - dnf install edb-bart - ``` - -BART (the `bart` program and `bart-scanner`) is installed in the `/usr/edb/bart/bin` directory, referred to as ``. Repeat the installation process described in this section to install BART on all remote hosts where incremental backups are to be restored. - - - -**Configuring BART** - -Before configuring BART, establish the BART user account (the operating system user) to run the BART command line program. Then, to configure the BART host and each database server that is to be managed by BART, perform the following steps: - -1. Assume superuser privileges, create the directory that will hold the BART backup catalog, and assign its ownership (with restrictive privileges) to the BART user account: - - In this example, `bartuser` is the BART user account and `/opt/backup` is the BART backup catalog. - - ```text - su root - mkdir /opt/backup - chown bartuser /opt/backup - chgrp bartuser /opt/backup - chmod 700 /opt/backup - ``` - -2. Navigate to the `/usr/edb/bart/etc` directory and copy the `bart.cfg.sample` file to create the BART configuration file (`bart.cfg`): - - ```text - cp bart.cfg.sample bart.cfg - ``` - -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - - Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. - - In the following example, only mandatory parameters are set: - - ```text - [BART] - bart_host= bartuser@192.168.169.199 - backup_path = /opt/backup - pg_basebackup_path = /usr/edb/as12/bin/pg_basebackup - - [EPAS12] - host = 127.0.0.1 - user = repuser - cluster_owner = enterprisedb - ``` - -The following table describes only mandatory parameters: - -| **Parameters/Placeholder** | **Section** | **Description** | -| -------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bart_host` | `[BART]` | Use this field to specify the BART user and the IP address of the host on which the BART utility is installed. Specify the value in the form of `@`. | -| `backup_path` | `[BART]` | Use this field to specify the path where all BART backups and archived WAL files will be stored. Ensure the BART user account holds privileges to create subdirectories and files within the location specified in the `backup_path` parameter. The default `backup_path` is BART backup catalog (`/opt/backup`). | -| `pg_basebackup_path` | `[BART]` | Use this field to specify the path to the pg_basebackup utility (`/usr/edb/as/bin/pg_basebackup`). | -| `[ServerName]` | `[ServerName]` | Specify the name of the database server to be backed up (for example, \[EPAS12]). | -| `host` | `[ServerName]` | Specify the IP address of the database server to be configured for backup. | -| `user` | `[ServerName]` | Specify the replication database user name used by BART to establish the connection to the database server for full backups. | -| `cluster_owner` | `[ServerName]` | Specify the Linux operating system user account that owns the database cluster. | - -4. As a BART user, navigate to `/usr/edb/bart/bin` and invoke the following subcommand (omitting the `-s` option) to verify the \[BART] section parameter settings: - - ```text - bart CHECK-CONFIG - ``` - -5. Authorize [SSH/SCP access](#passwordless) between the server and the BART host without a password prompt. - -6. Create a [replication database user](#replication) for each database server that BART manages. - -7. To enable continuous WAL archiving for any database server for which BART is to perform a backup, modify the `postgresql.conf` file, setting: - - - `wal_level` to `replica` or higher (for Postgres 9.6 or later) - - `archive_mode` to `on` - - `archive_command` (if it is not set in the `bart.cfg` file) - - `max_wal_senders` to a value high enough to leave at least one session available for the backup. - - After setting the parameters, restart the database server. - -8. To start the WAL scanner, navigate to `/usr/edb/bart/bin` as a BART user and execute the following command: - - ```text - ./bart-scanner - ``` - -9. If you are using the default `archive_command`, then navigate to `/usr/edb/bart/bin` as a BART user, run the `INIT` subcommand without the `-o` option, and restart the database server: - - ```text - bart INIT [ -s { | all } ] - ``` - - Where `` is the name of the database server to be backed up. - - If you have customized the `archive_command` setting in the `bart.cfg` file, run the `INIT` subcommand with the `-o` option to override any existing Postgresql `archive_command` setting in the `postgresql.conf` or the `postgresql.auto.conf` file, and restart the database server. - - ```text - bart INIT [ -s { | all } ] [ -o ] - ``` - -10. To verify the database server parameter settings, as a BART user navigate to `/usr/edb/bart/bin` and invoke the `CHECK-CONFIG` subcommand with the -s option: - - ```text - bart CHECK-CONFIG [ -s ] - ``` - - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide* available at the [EDB website](/bart/latest/bart_user/). - - - -**Creating a Passwordless Connection** - -The following example enables SSH/SCP access on a CentOS 7.x host; similar (platform-specific) steps will apply to other platforms/versions. You must create a passwordless connection between the BART host (SSH/SCP client) and the database server (target SSH/SCP server), as well as a passwordless connection between the database server (SSH/SCP client) and the BART host (target SSH/SCP server). - -1. Log in as the user account on the BART host that will be initiating the SSH or SCP connection and navigate to the user account’s home directory and check for an existing `.ssh` subdirectory. If the `.ssh` directory does not exist, create one with the required privileges. - -2. As a root user navigate to `/usr/edb/bart`, open the `/etc/ssh/sshd_config` file and set the `PubkeyAuthentication` parameter to `yes`. - -3. Reload the configuration file: - - ```text - service sshd reload - ``` - - If you get any SSH or SCP errors, examine the log file (`/var/log/secure`). - -4. As a BART user, use the following command to generate the public key file; you can accept the default responses: - - ```text - ssh-keygen -t rsa - ``` - - The public key file named `id_rsa.pub` is created in the `.ssh` subdirectory. - -5. Use `SCP` to make a temporary copy of the public key file on the target server: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -6. As a `target_user`, log into the target server using `ssh target_user@host_address` command and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges. - -7. Append the temporary client’s public key file, `tmp.pub`, to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - - If an `authorized_keys` file does not exist, create a new file, but be careful not to completely replace any existing `authorized_keys` file. - -8. Ensure only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -9. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the BART host as a user, there should be no prompt for a password when you are connecting to the target database server: - - ```text - ssh target_user@database_server_address - ``` - -**Creating a Passwordless Connection Between the Database Server and the BART Host** - -If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. - -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). - -Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. - -1. On the database server, navigate into the target user account’s home directory to check for an existing `.ssh` subdirectory. If it does does not exist, create one in the user account’s home directory with the required privileges. - -2. As a database server user, generate the public key file: - - ```text - ssh-keygen -t rsa - ``` - -3. Create a temporary copy of the public key file: - - ```text - scp ~/.ssh/id_rsa.pub target_user@host_address:tmp.pub - ``` - -4. As a target user, log into the BART host and navigate to the user account’s home directory to check if there is an existing `.ssh` subdirectory. If it does not exist, create one with the required privileges: - - ```text - ssh target_user@host_address - ``` - -5. Append the client’s temporary public key file to the `authorized_keys` file: - - ```text - cat tmp.pub >> ~/.ssh/authorized_keys - ``` - -If the `authorized_keys file` does not exist, create a new file, but do not completely replace any existing `authorized_keys` file. - -6. Ensure that only the file owner (and not other groups or users) has access to `authorized_keys` file: - - ```text - chmod 600 ~/.ssh/authorized_keys - ``` - -7. Delete the temporary public key file: - - ```text - rm tmp.pub - ``` - - Now, when logged into the database server as a user, there should be no prompt for a password when you are connecting to the BART host: - - ```text - ssh bart_user@bartip_address - ``` - - - -**Creating a Replication Database User** - -1. To create a replication database user (a superuser), connect to the database server with the psql client, and invoke the following PostgreSQL command: - - ```text - CREATE ROLE WITH LOGIN SUPERUSER PASSWORD ''; - ``` - -2. Specify this replication database user in the `user` parameter of the `bart.cfg` file. - -3. The [pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html) file must minimally permit the replication database user to have access to the database. The IP address from which the replication database user has access to the database is the BART host location. The replication database user must also be included in the `pg_hba.conf` file as a replication database connection if `pg_basebackup` is to be used for taking any backups. - -4. To ensure there is no password prompt when connecting to the database server with the replication database user, a recommended method is to use the `.pgpass` file located in the BART user account’s home directory (if it does not exist, you need to create the `.pgpass` file with the required privileges). The `.pgpass` file must contain an entry for each BART managed database server, and its corresponding replication database user and password. diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/01_backup.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/01_backup.mdx deleted file mode 100644 index 8b8f85eb4d0..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/01_backup.mdx +++ /dev/null @@ -1,271 +0,0 @@ ---- -title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/backup.html" ---- - -Use the `BACKUP` subcommand to create a full or incremental backup. - -**Syntax for a Full Backup:** - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - -[ -z ] [ –c ] - -[ --backup-name ] - -[ --thread-count ] - -[ { --with-pg_basebackup | --no-pg_basebackup } ] -``` - -**Syntax for an Incremental Backup:** - -```text -bart BACKUP –s [-Fp] - -[ --parent { | } ] - -[ --backup-name ] - -[ --thread-count ] - -[ { --checksum-algorithm } ] -``` - -Before performing an incremental backup, you must take a full backup. For more details about incremental backup, refer to *Block-Level Incremental Backup* in the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `BACKUP` options: - -| Options | Description | -| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | Use this option to specify the database server to be backed up.
Specify `` to take a backup of the database server (as specified in the BART configuration file).
Specify `all` to take a backup of all servers. | -| `-F { p \| t }`
`--format { p \| t }` | Use this option to specify the backup file format.
Specify `p` option to take backup in plain text format and specify `t` option to take backup in tar format. If the `p` or `t` option is omitted, the default is tar format.
Use `p` option with the `BACKUP` subcommand when streaming is used as a backup method.
An incremental backup can only be taken in plain text format (`p`). | -| `-z`
`(--gzip)` | This option is applicable only for full backup and `tar` format. Use this option to enable gzip compression of tar files using the default compression level (typically 6). | -| `-c `
`--compress-level ` | This is applicable only for full backup and tar format. Use this option to specify the gzip compression level on the tar file output. `` is a digit from 1 through 9, with 9 being the best compression. | -| `--backup-name ` | Use this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
For detailed information about this parameter, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/).
If the option `--backup-name` is not specified and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to specify the number of worker threads to run in parallel to copy blocks for a backup.
For detailed information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | -| `--with-pg_basebackup` | This is applicable only for full backup. Use this option to specify the use of `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the `--with-pg_basebackup` option is specified with the `BACKUP` subcommand. | -| `--no-pg_basebackup` | This is applicable only for full backup. Use this option to specify that `pg_basebackup` is not to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. | -| `--parent { \| }` | Use this option to take an incremental backup. The parent backup is a backup taken prior to the incremental backup; it can be either a full backup or an incremental backup. `` is the backup identifier of a parent backup and `` is the user-defined alphanumeric name of a parent backup. | -| `--check` | This is applicable only for incremental backup. Use this option to verify if the required MBM files are present in the BART backup catalog before taking an incremental backup. However, an actual incremental backup is not taken when the `--check` option is specified.
The `--parent` option must be used along with the `--check` option. | -| `--checksum-algorithm` | While taking a backup, you can specify one of the following values with the `--checksum-algorithm` option:
`--checksum-algorithm=MD5` (default) to generate MD5 checksum files.
`--checksum-algorithm=SHA256` to generate SHA256 checksum files.
`--checksum-algorithm=NONE` to skip generating checksum files. | - -**Examples** - -The following code sample demonstrates using variables with the `BACKUP` subcommand: - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year MONTH = -%month DAY = %day" -``` - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year MONTH = -%month DAY = %day %%" -``` - -```text -./bart show-backups -s ppas12 -i "test backup" -``` - -The following code sample displays the result of creating a full backup in the default tar format with gzip compression when the `BACKUP` subcommand was invoked. Note that checksums are generated for the full backup and user-defined tablespaces for the tar format backup: - -```text -[edb@localhost bin]$ ./bart BACKUP -s hr -z -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1567591909098 -INFO: creating 5 harvester threads -NOTICE: all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1567591909098 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/hr/1567591909098 -BACKUP SIZE: 13.91 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: America/New_York -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 3 -Oid Name Location -16387 test1 /home/edb/tbl1 -16388 test2 /home/edb/tbl2 -16389 test3 /home/edb/tbl3 - -START WAL LOCATION: 000000010000000000000025 -STOP WAL LOCATION: 000000010000000000000026 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-09-04 06:11:49 EDT -STOP TIME: 2019-09-04 06:11:53 EDT -TOTAL DURATION: 4 sec(s) -``` - -The following code sample displays information about the directory containing the full backup: - -```text -[edb@localhost bin]$number_of_threads> -[edb@localhost bin]$ ls -l /home/edb/bkup_new/hr/ -total 8 -drwxrwxr-x. 3 edb edb 34 Aug 27 05:57 1566899819709 -drwxrwxr-x. 3 edb edb 58 Aug 27 05:57 1566899827751 -drwxrwxr-x. 3 edb edb 4096 Sep 4 06:11 1567591909098 -drwxrwxr-x. 2 edb edb 4096 Sep 4 06:11 archived_wals -[edb@localhost bin]$ -``` - -The following code sample displays information about the creation of a full backup while streaming the transaction log. Note that the `-Fp` option must be specified with the `BACKUP` subcommand when streaming is used as a backup method. - -```text -[edb@localhost bin]$ ./bart BACKUP -s ACCTG -Fp -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1566898964200 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566898964200 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/acctg/1566898964200 -BACKUP SIZE: 46.03 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000017 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:42:44 EDT -STOP TIME: 2019-08-27 05:42:46 EDT -TOTAL DURATION: 2 sec(s) -``` - -The following code sample displays the assignment of a user-defined backup name with the `--backup-name` option: - -```text -[edb@localhost bin]$ ./bart BACKUP -s acctg --backup-name acctg_%year-%month-%day -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: new backup identifier generated 1566899004804 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566899004804 -BACKUP NAME: acctg_2019-08-27 -BACKUP PARENT: none -BACKUP LOCATION: /home/edb/bkup_new/acctg/1566899004804 -BACKUP SIZE: 46.86 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 00000001000000000000001A -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:43:24 EDT -STOP TIME: 2019-08-27 05:43:24 EDT -TOTAL DURATION: 0 sec(s) -``` - -The following code sample displays an incremental backup taken by specifying the `--parent` option. The option `-Fp` must be specified while taking an incremental backup as incremental backup can be taken only in plain text format. - -```text -[edb@localhost bin]$ ./bart BACKUP -s hr -Fp --parent hr_full_1 --backup-name -hr_incr_1 -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: checking /home/edb/bkup_new/hr/archived_wals for MBM files from 0/20000028 to -0/22000000 -INFO: new backup identifier generated 1566899827751 -INFO: creating 5 harvester threads -NOTICE: all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.5 -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1566899827751 -BACKUP NAME: hr_incr_1 -BACKUP PARENT: 1566899819709 -BACKUP LOCATION: /home/edb/bkup_new/hr/1566899827751 -BACKUP SIZE: 7.19 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: America/New_York -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000022 -STOP WAL LOCATION: 000000010000000000000023 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2019-08-27 05:57:07 EDT -STOP TIME: 2019-08-27 05:57:08 EDT -TOTAL DURATION: 1 sec(s) -``` - - - -The following code sample displays an incremental backup taken by specifying the `--checksum-algorithm=NONE` option to skip generating checksum files. - -First, the bart-scanner is started. - -```text -edb@localhost bin]$ -[edb@localhost bin]$ ./bart-scanner -d --checksum-algorithm=NONE -DEBUG: sockPath = /tmp/fc557c1c8853d75f1cb52a8a578f371a -INFO: process created for server 'ppas11', pid = 19012 -DEBUG: could not load XLogReaderLibrary at this time, archived_wals is empty -``` - -Then, an incremental backup is taken with the `--checksum-algorithm=NONE` option to skip generating checksum files. - -```text -[edb@localhost bin]$ ./bart backup -s ppas11 -Fp --parent 1593506709152 --checksum-algorithm=NONE -INFO: DebugTarget - getVar(checkDiskSpace.bytesAvailable) -INFO: checking /home/edb/bkup/ppas11/archived_wals for MBM files from 1/D3000028 to 1/D9000000 -INFO: new backup identifier generated 1593507779811 -INFO: creating 5 harvester threads -NOTICE: pg_stop_backup complete, all required WAL segments have been archived -INFO: backup completed successfully -INFO: -BART VERSION: 2.6devel -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1593507779811 -BACKUP NAME: none -BACKUP PARENT: 1593506709152 -BACKUP LOCATION: /home/edb/bkup/ppas11/1593507779811 -BACKUP SIZE: 7.30 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 0000000100000001000000D9 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2020-06-30 05:02:59 EDT -STOP TIME: 2020-06-30 05:03:05 EDT -TOTAL DURATION: 6 sec(s) -``` - -!!! Note - To restore an incremental backup taken with the `--checksum-algorithm=NONE` option, you must specify [--disable-checksum while restoring](06_restore/#restoring_an_incremental_backup_using_disable_checksum). - -Similarly, you can specify `--checksum-algorithm=MD5` or `--checksum-algorithm=SHA256` while taking an incremental backup if you want to generate MD5 or SHAD256 checksum files. diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/02_check_config.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/02_check_config.mdx deleted file mode 100644 index 69c51d5249e..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/02_check_config.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/check_config.html" ---- - -The `CHECK-CONFIG` subcommand checks the global parameter settings as well as the database server configuration in the BART configuration file. - -The following syntax is used to check the BART configuration file global section settings. - -```text -bart CHECK-CONFIG -``` - -The following syntax is used to check the database server configuration settings. - -```text -bart CHECK-CONFIG [ –s ] -``` - -The following table describes the `CHECK-CONFIG` option: - -| Option | Description | -| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -| `-s ` `--server ` | `` is the name of the database server whose configuration parameter settings are to be checked. | - -**Example** - -The following code sample demonstrates successfully checking the BART configuration file global parameters with the `bart CHECK-CONFIG` command: - -```text -bash-4.1$ bart CHECK-CONFIG -INFO: Verifying that pg_basebackup is executable -INFO: success - -INFO: success - pg_basebackup(/usr/edb/as11/bin/pg_basebackup) returns -version 11.400000 -``` - -The following code sample demonstrates successfully checking the BART configuration file database server parameters with the `bart CHECK-CONFIG` command with the `–s` option: - -```text -[edb@localhost bin]$ ./bart check-config -s hr -INFO: Checking server hr -INFO: Verifying cluster_owner and ssh/scp connectivity -INFO: success -INFO: Verifying user, host, and replication connectivity -INFO: success -INFO: Verifying that user is a database superuser -INFO: success -INFO: Verifying that cluster_owner can read cluster data files -INFO: success -INFO: Verifying that you have permission to write to vault -INFO: success -INFO: /home/edb/bkup_new/hr -INFO: Verifying database server configuration -INFO: success -INFO: Verifying that WAL archiving is working -INFO: waiting 30 seconds for -/home/edb/bkup_new/hr/archived_wals/00000001000000000000001E -INFO: success -INFO: Verifying that bart-scanner is configured and running -INFO: success -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/03_delete.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/03_delete.mdx deleted file mode 100644 index a148c571880..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/03_delete.mdx +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/delete.html" ---- - -The `DELETE` subcommand removes the subdirectory and data files from the BART backup catalog for the specified backups along with archived WAL files. - -**Syntax:** - -```text -bart DELETE –s --i { all | [']{ | },... }['] } -[ -n ] -``` - -Note that when invoking the `DELETE` subcommand, you must specify a database server. - -For database servers under a retention policy, there are conditions where certain backups may not be deleted. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `DELETE` options: - -| Options | Description | -| -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server whose backups are to be deleted. | -| ``-i { all \| [']{ \| }',... }[`] }``

``--backupid { all \| [']{ \| }',... }[`] }`` | `` is the backup identifier of the backup to be deleted. `` is the user-defined alphanumeric name for the backup.
Multiple backup identifiers and backup names may be specified in a comma-separated list. The list must be enclosed within single quotes if there is any white space appearing before or after each comma (see [Example](#deleting_multiple_backups_with_space_characters)).
If `all` is specified, all backups and their archived WAL files for the specified database server are deleted. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to physically removing files; no files are actually deleted. | - -**Example** - -The following code sample demonstrates deleting a backup from the specified database server: - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i acctg_2019-08-27 -INFO: deleting backup 'acctg_2019-08-27' of server 'acctg' -INFO: deleting backup '1566900093665' -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -'/home/edb/bkup_new/acctg/archived_wals/000000010000000000000025' -is required, yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -``` - -After the deletion, the BART backup catalog for the database server no longer contains the corresponding directory for the deleted `backup ID`. The following code sample displays information about `archived_wals` subdirectory that no longer contains the backup WAL files: - -```text -[edb@localhost acctg]$ ls -l -total 16 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900199604 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900204377 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:03 1566900209087 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:05 1566900321228 -drwxrwxr-x. 2 edb edb 6 Aug 27 06:01 archived_wals -``` - -The following code sample demonstrates deleting multiple backups from the database server. - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i `1566988095633,1566988100760, -acctg_2019-08-28` -INFO: deleting backup `1566988095633` of server `acctg` -INFO: deleting backup `1566988095633` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000037` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566988100760` of server `acctg` -INFO: deleting backup `1566988100760` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000039` is -required, yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `acctg_2019-08-28` of server `acctg` -INFO: deleting backup `1566988115512` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000003C` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost acctg]$ -[edb@localhost acctg]$ ls -l -total 8 -drwxrwxr-x. 3 edb edb 4096 Aug 28 06:28 1566988105086 -drwxrwxr-x. 3 edb edb 4096 Aug 28 06:28 1566988109477 -drwxrwxr-x. 2 edb edb 6 Aug 28 06:09 archived_wals -[edb@localhost acctg]$ -``` - - - -**Deleting Multiple Backups with Space Characters** - -The following code sample demonstrates deleting multiple backups; since there are space characters in the comma-separated list, the entire list must be enclosed within single quotes: - -```text -[edb@localhost bin]$ ./bart DELETE -s acctg -i -`1566900199604,1566900204377,1566900209087`; -INFO: deleting backup `1566900199604` of server `acctg` -INFO: deleting backup `1566900199604` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/000000010000000000000028` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566900204377` of server `acctg` -INFO: deleting backup `1566900204377` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000002A` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -INFO: deleting backup `1566900209087` of server `acctg` -INFO: deleting backup `1566900209087` -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or will -be marked unused -WARNING: not marking any WALs as unused WALs, the WAL file -`/home/edb/bkup_new/acctg/archived_wals/00000001000000000000002C` is required, -yet not available in archived_wals directory -INFO: backup(s) deleted -[edb@localhost bin]$ -[edb@localhost bin]$ -[edb@localhost acctg]$ ls -l -total 4 -drwxrwxr-x. 3 edb edb 4096 Aug 27 06:05 1566900321228 -drwxrwxr-x. 2 edb edb 6 Aug 27 06:01 archived_wals -[edb@localhost acctg]$ -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/04_init.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/04_init.mdx deleted file mode 100644 index 9f8b020ac03..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/04_init.mdx +++ /dev/null @@ -1,276 +0,0 @@ ---- -title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/init.html" ---- - - - -The `INIT` subcommand is used to create the BART backup catalog directory, rebuild the BART `backupinfo` file, and set the `archive_command` in the server based on the `archive_command` setting in the `bart.cfg` file. - -**Syntax:** - -```text -bart INIT [ –s { | all } ] [ -o ] - -[ -r [ -i { | | all } ] ] - -[--no-configure] -``` - -The following table describes the `INIT` options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server to which the `INIT` actions are to be applied. If `all` is specified or if the option is omitted, actions are applied to all servers. | -| `-o`
`--override` | Overrides the existing Postgres `archive_command` configuration parameter setting in the `postgresql.conf` file or the `postgresql.auto.conf` file using the BART `archive_command` parameter in the BART configuration file. The `INIT` generated `archive command` string is written to the `postgresql.auto.conf` file. | -| `-r`
`--rebuild` | Rebuilds the `backupinfo` file located in each backup subdirectory. If `all` is specified or if the option is omitted, the `backupinfo` files of all backups for the database servers specified by the `-s` option are recreated. This option is only intended for recovering from a situation where the backupinfo file has become corrupt.
If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild that `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. | -| `-i { \| \| all }`
`--backupid { \| \| all }` | `` is an integer, backup identifier and `` is the user-defined alphanumeric name for the backup. The `-i` option can only be used with the `-r` option. | -| `--no-configure` | Prevents the `archive_command` from being set in the PostgreSQL server. | - -**Examples** - -In the following code sample, you can see that `archive_mode = off` and `archive_command` is not set. After invoking the BART `INIT` subcommand, `archive_mode` is set to `on` and `archive_command` is set: - -```text -archive_mode = off # enables archiving; off, on, or always -# (change requires restart) -archive_command = '' -# command to use to archive a logfile segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_mode/archive_command is set. Restart the PostgreSQL -server using 'pg_ctl restart' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_mode = 'on' -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample, you can see that `archive_mode = on`, and `archive_command` is not set. After invoking the `INIT` subcommand, `archive_command` is set: - -```text -archive_mode = on # enables archiving; off, on, or always -# (change requires restart) -archive_command = '' # command to use to archive a logfile segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_command is set. Reload the configuration in the -PostgreSQL server using pg_reload_conf() or 'pg_ctl reload' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample, you can see that `archive_mode = on` and `archive_command` are already set. After invoking the `INIT` subcommand, there is no change in their settings. Note that to override the existing `archive_command`, you must include the `-o` option. - -```text -archive_mode = on # enables archiving; off, on, or always -# (change requires restart) -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' # command to use -to archive a logfile segment -# placeholders: %p = path of file to archive -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_command is not set for server 'ppas11' -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -``` - -In the following code sample, you can see that `archive_mode = off` and `archive_command` is already set. After invoking the `INIT` subcommand `archive_mode` is set to `on`: - -```text -archive_mode = off # enables archiving; off, on, or always -# (change requires restart) -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' # command to use -to archive a log file segment -[edb@localhost bin]$ ./bart init -s ppas11 -INFO: setting archive_mode/archive_command for server 'ppas11' -WARNING: archive_mode/archive_command is set. Restart the PostgreSQL -server using 'pg_ctl restart' -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -archive_mode = 'on' -archive_command = 'scp %p -edb@127.0.0.1:/home/edb/bkup/ppas11/archived_wals/%f' -``` - -In the following code sample an existing `archive command` setting is overridden by resetting the `archive_command` in the PostgreSQL server with the `archive_command = 'cp %p %a/%f'` parameter from the `bart.cfg` file: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup_edb -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = repuser -cluster_owner = enterprisedb -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -The `archive_mode` and `archive_command` parameters in the database server are set as follows: - -```text -edb=# SHOW archive_mode; -archive_mode --------------- -on -(1 row) -edb=# SHOW archive_command; -archive_command ------------------------------------------------------------------- -scp %p bartuser@192.168.2.22:/opt/backup/acctg/archived_wals/%f - -(1 row) -``` - -Invoke the `INIT` subcommand with the `-o` option to override the current `archive_command` setting in the PostgreSQL server: - -```text --bash-4.1$ bart INIT -s acctg -o -INFO: setting archive_mode/archive_command for server 'acctg' -WARNING: archive_command is set. Reload the configuration in the -PostgreSQL server using pg_reload_conf() or 'pg_ctl reload' -``` - -Reload the database server configuration; a restart of the database server is not necessary to reset only the `archive_command` parameter: - -```text -[root@localhost tmp]# service ppas11 reload -``` - -The `archive_command` in the PostgreSQL server is now set as follows: - -```text -edb=# SHOW archive_command; - archive_command ------------------------------------------------ -cp %p /opt/backup_edb/acctg/archived_wals/%f -(1 row) -``` - -The new command string is written to the `postgresql.auto.conf` file: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup_edb/acctg/archived_wals/%f' -``` - -When you invoke the BART `INIT` command with the `-r` option, BART rebuilds the `backupinfo` file using the content of the backup directory for the server specified or for all servers. The BART `backupinfo` file is initially created by the `BACKUP` subcommand and contains the backup information used by BART. - -!!! Note - If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild the `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. - -The following code sample shows the `backupinfo` file location in a backup subdirectory: - -```text -[root@localhost acctg]# pwd -/opt/backup/acctg -[root@localhost acctg]# ls -l -total 4 -drwx------ 2 enterprisedb enterprisedb 38 Oct 26 10:21 1477491569966 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Oct 26 10:19 archived_wals -[root@localhost acctg]# ls -l 1477491569966 -total 61144 --rw-rw-r-- 1 enterprisedb enterprisedb 703 Oct 26 10:19 backupinfo --rw-rw-r-- 1 enterprisedb enterprisedb 62603776 Oct 26 10:19 base.tar -``` - -The following code sample displays the `backupinfo` file content: - -```text -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1477491569966 -BACKUP NAME: none -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1477491569966 -BACKUP SIZE: 59.70 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -84b3eeb1e3f7b3e75c2f689570d04f10 base.tar -TABLESPACE(s): 0 -START WAL LOCATION: 2/A5000028 (file 0000000100000002000000A5) -STOP WAL LOCATION: 2/A50000C0 (file 0000000100000002000000A5) -CHECKPOINT LOCATION: 2/A5000028 -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2016-10-26 10:19:30 EDT -LABEL: pg_basebackup base backup -STOP TIME: 2016-10-26 10:19:30 EDT -TOTAL DURATION: 0 sec(s) -``` - -The following code sample displays an error message if the `backupinfo` file is missing when invoking a BART subcommand: - -```text --bash-4.2$ bart SHOW-BACKUPS -ERROR: 'backupinfo' file does not exist for backup '1477491569966' -please use 'INIT -r' to generate the file -``` - -The `backupinfo` file may be missing if the `BACKUP` subcommand did not complete successfully. - -The following code sample displays information about rebuilding the `backupinfo` file of the specified backup for database server `acctg`: - -```text --bash-4.1$ bart INIT -s acctg -r -i 1428346620427 -INFO: rebuilding BACKUPINFO for backup '1428346620427' of server 'acctg' -INFO: backup checksum: ced59b72a7846ff8fb8afb6922c70649 of base.tar -``` - -The following code sample displays information about how the `backupinfo` files of all backups are rebuilt for all database servers: - -```text --bash-4.1$ bart INIT -r - -INFO: rebuilding BACKUPINFO for backup '1428347191544' of server 'acctg' -INFO: backup checksum: 1ac5c61f055c910db314783212f2544f of base.tar -INFO: rebuilding BACKUPINFO for backup '1428346620427' of server 'acctg' -INFO: backup checksum: ced59b72a7846ff8fb8afb6922c70649 of base.tar -INFO: rebuilding BACKUPINFO for backup '1428347198335' of server 'dev' -INFO: backup checksum: a8890dd8ab7e6be5d5bc0f38028a237b of base.tar -INFO: rebuilding BACKUPINFO for backup '1428346957515' of server 'dev' -INFO: backup checksum: ea62549cf090573625d4adeb7d919700 of base.tar -``` - -The following code sample displays information about invoking `BART INIT` with the `-r - i` option: - -```text -edb@localhost bin]$ ./bart init -s ppas11 -i 1551778898392 -r -INFO: rebuilding BACKUPINFO for backup '1551778898392' of server -'ppas11' -[edb@localhost bin]$ ls /home/edb/bkup/ppas11/1551778898392/ -backupinfo backup_label base base-1.tar base-2.tar base-3.tar -base-4.tar base-5.tar base.tar -``` - -The following code sample displays information about invoking the `BART INIT` command with the `--no-configure` option. You can use the `--no-configure` option with the `INIT` subcommand to prevent the `archive_command` option from being set in the PostgreSQL server. - -```text -[edb@localhost bin]$ ./bart init -s ppas11 -o --no-configure -[edb@localhost bin]$ -# Do not edit this file manually! -# It will be overwritten by the ALTER SYSTEM command. -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/05_manage.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/05_manage.mdx deleted file mode 100644 index 75e63130a8e..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/05_manage.mdx +++ /dev/null @@ -1,228 +0,0 @@ ---- -title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/manage.html" ---- - -The `MANAGE` subcommand can be invoked to: - -- Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file. -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file. - -**Syntax:** - -```text -bart MANAGE [ –s { | all} ] -[ -l ] [ -d ] -[ -c { keep | nokeep } --i { | | all } ] -[ -n ] -``` - -To view detailed information about the `MANAGE` subcommand and retention policy management, see *the EDB Backup and Recovery User Guide*. For information about setting the `wal_compression` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide*. These guides are available at the [EDB website](/bart/latest/bart_user/). - -The following table describes the `MANAGE` options: - -| Options | Description | -| ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `-s [ \| all ]`
`--server [ \| all ]` | `` is the name of the database server to which the `MANAGE` actions are to be applied.
If `all` is specified or if the `-s` option is omitted, actions are applied to all database servers. | -| `-l`
`--list-obsolete` | Lists the backups marked as obsolete. | -| `-d`
`--delete-obsolete` | Deletes the backups marked as obsolete. This action physically deletes the backup along with its archived WAL files and any MBM files for incremental backups. | -| `-c { keep \| nokeep }`
`--change-status { keep \| nokeep }` | Specify `keep` to change the backup status to `keep` to retain the backup indefinitely.

Specify `nokeep` to change the backup status back to `active`. You can then re-evaluate and possibly mark the backup as `obsolete` (according to the retention policy) using the `MANAGE` subcommand.

The `-c` option can only be used with the `-i` option. | -| `-i { \| \| all` }

`--backupid { \| \| all` } | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified, actions are applied to all backups.
The `-i` option can only be used with the `-c` option. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to actually implementing the actions as if the operation was performed, however, no changes are actually made.
If you specify `-n` with the `-d` option, it displays which backups would be deleted, but does not actually delete the backups.
If you specify `-n` with the `-c` option, it displays the keep or nokeep action, but does not actually change the backup status.
If you specify `-n` alone with no other options or if you specify `-n` with only the `-s` option, it displays which active backups would be marked as obsolete, but does not actually change the backup status. In addition, no compression is performed on uncompressed, archived WAL files even if WAL compression is enabled for the database server. | - -**Example** - -The following code sample performs a dry run for the specified database server displaying which active backups are evaluated as obsolete according to the retention policy, but does not actually change the backup status: - -```text --bash-4.2$ bart MANAGE -s acctg -n -INFO: processing server 'acctg', backup '1482770807519' -INFO: processing server 'acctg', backup '1482770803000' -INFO: marking backup '1482770803000' as obsolete -INFO: 1 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1482770735155' -INFO: marking backup '1482770735155' as obsolete -INFO: 2 incremental(s) of backup '1482770735155' will be marked obsolete -INFO: marking incremental backup '1482770780423' as obsolete -INFO: marking incremental backup '1482770763227' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample marks active backups as obsolete according to the retention policy for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1482770807519' -INFO: processing server 'acctg', backup '1482770803000' -INFO: marking backup '1482770803000' as obsolete -INFO: 1 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1482770735155' -INFO: marking backup '1482770735155' as obsolete -INFO: 2 incremental(s) of backup '1482770735155' will be marked obsolete -INFO: marking incremental backup '1482770780423' as obsolete -INFO: marking incremental backup '1482770763227' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample lists backups marked as obsolete for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -l -SERVER NAME: acctg -BACKUP ID: 1482770803000 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:46:43 EST -BACKUP SIZE: 59.52 MB -WAL FILE(s): 1 -WAL FILE: 000000010000000100000055 -SERVER NAME: acctg -BACKUP ID: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -INCREMENTAL BACKUP(s): 2 -BACKUP ID: 1482770780423 -BACKUP PARENT: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -BACKUP ID: 1482770763227 -BACKUP PARENT: 1482770735155 -BACKUP STATUS: obsolete -BACKUP TIME: 2016-12-26 11:45:35 EST -BACKUP SIZE: 59.52 MB -WAL FILE(s): 3 -WAL FILE: 000000010000000100000054 -WAL FILE: 000000010000000100000053 -WAL FILE: 000000010000000100000052 -UNUSED FILE(s): 2 -UNUSED FILE: 000000010000000100000051 -UNUSED FILE: 0000000100000001510000280000000152000000.mbm -``` - -The following code sample deletes the obsolete backups for the specified database server: - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1482770803000' -INFO: 1 WAL file(s) will be removed -INFO: removing WAL file '000000010000000100000055' -INFO: removing obsolete backup '1482770735155' -INFO: 3 WAL file(s) will be removed -INFO: 2 incremental(s) of backup '1482770735155' will be removed -INFO: removing obsolete incremental backup '1482770780423' -INFO: removing obsolete incremental backup '1482770763227' -INFO: removing WAL file '000000010000000100000054' -INFO: removing WAL file '000000010000000100000053' -INFO: removing WAL file '000000010000000100000052' -INFO: 8 Unused file(s) will be removed -INFO: removing (unused) file '000000010000000100000056.00000028.backup' -INFO: removing (unused) file '000000010000000100000056' -INFO: removing (unused) file '000000010000000100000055.00000028.backup' -INFO: removing (unused) file '000000010000000100000054.00000028.backup' -INFO: removing (unused) file '000000010000000100000053.00000028.backup' -INFO: removing (unused) file '000000010000000100000052.00000028.backup' -INFO: removing (unused) file '000000010000000100000051' -INFO: removing (unused) file -'0000000100000001510000280000000152000000.mbm' -``` - -The following code sample changes the specified backup to keep status to retain it indefinitely: - -```text --bash-4.2$ bart MANAGE -s acctg -c keep -i 1482770807519 -INFO: changing status of backup '1482770807519' of server 'acctg' from -'active' to 'keep' -INFO: 1 WAL file(s) changed --bash-4.2$ bart SHOW-BACKUPS -s acctg -i 1482770807519 -t -SERVER NAME : acctg -BACKUP ID : 1482770807519 -BACKUP NAME : none -BACKUP PARENT : none -BACKUP STATUS : keep -BACKUP TIME : 2016-12-26 11:46:47 EST -BACKUP SIZE : 59.52 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -LAST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -``` - -The following code sample resets the specified backup to active status: - -```text --bash-4.2$ bart MANAGE -s acctg -c nokeep -i 1482770807519 -INFO: changing status of backup '1482770807519' of server 'acctg' from -'keep' to 'active' -INFO: 1 WAL file(s) changed --bash-4.2$ bart SHOW-BACKUPS -s acctg -i 1482770807519 -t -SERVER NAME : acctg -BACKUP ID : 1482770807519 -BACKUP NAME : none -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-12-26 11:46:47 EST -BACKUP SIZE : 59.52 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -LAST WAL FILE : 000000010000000100000057 -CREATION TIME : 2016-12-26 11:52:47 EST -``` - -The following code sample uses the enabled `wal_compression` parameter in the BART configuration file as shown by the following: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -allow_incremental_backups = disabled -wal_compression = enabled -description = "Accounting" -``` - -When the `MANAGE` subcommand is invoked, the following message is displayed indicating that WAL file compression is performed: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: 4 WAL file(s) compressed -WARNING: 'retention_policy' is not set for server 'acctg' -``` - -The following code sample shows the archived WAL files in compressed format: - -```text --bash-4.2$ pwd -/opt/backup/acctg --bash-4.2$ ls -l archived_wals -total 160 --rw------- 1 enterprisedb enterprisedb 27089 Dec 26 12:16 -00000001000000010000005B.gz --rw------- 1 enterprisedb enterprisedb 305 Dec 26 12:17 -00000001000000010000005C.00000028.backup --rw------- 1 enterprisedb enterprisedb 27112 Dec 26 12:17 -00000001000000010000005C.gz --rw------- 1 enterprisedb enterprisedb 65995 Dec 26 12:18 -00000001000000010000005D.gz --rw------- 1 enterprisedb enterprisedb 305 Dec 26 12:18 -00000001000000010000005E.00000028.backup --rw------- 1 enterprisedb enterprisedb 27117 Dec 26 12:18 -00000001000000010000005E.gz -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/06_restore.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/06_restore.mdx deleted file mode 100644 index 52490745796..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/06_restore.mdx +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/restore.html" ---- - -The `RESTORE` subcommand restores a backup and its archived WAL files for the designated database server to the specified directory location. - -**Syntax for Restore**: - -```text -bart RESTORE –s -p -[ –i { | } ] -[ -r @ ] -[ -w ] -[ -t ] -[ { -x | -g } ] -[ -c ] -[ --disable-checksum ] -``` - -To view detailed information about the `RESTORE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -If the backup is restored to a different database cluster directory than where the original database cluster resided, then some operations dependent upon the database cluster location may fail. This happens if the supporting service scripts are not updated to reflect the new directory location of restored backup. - -For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). - -The following table describes the `RESTORE` options: - -| Options | Description | -| --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server to be restored. | -| `-p --restore-path `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | -| `-i { \| }`

`--backupid { \| }` | `backup_id` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the latest backup is restored by default. | -| `-r `

`--remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored.
`` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `remote_host` parameter for this database server is not set in the BART configuration file.
For information about the `remote_host` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). | -| `-w `
`--workers ` | `` is the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location. If the `-w` option is omitted, the default is `1` worker process.
For example, if four worker processes are specified, four receiver processes on the restore host and four streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process.
When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. | -| `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | -| `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. | -| `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. | -| `-c`

`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
The `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, then the `restore_command` in the `postgresql.conf` retrieves the archived WAL files directly from the BART backup catalog.
For information about the `copy_wals_during_restore` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | -| `--disable-checksum` | While restoring a backup, specify this option to skip verifying the MD5 or SHA256 checksum files.
If you set the `--checksum-algorithm=NONE` option with the BART scanner or while taking a backup, you also need to specify the `--disable checksum` option while restoring an incremental backup. | - -**Examples** - -The following code sample restores a database server(named `mktg`) to the `/opt/restore` directory up to timestamp `2015-12-15 10:47:00`: - -```text --bash-4.1$ bart RESTORE -s mktg -i 1450194208824 -p /opt/restore -t 1 -g -'2015-12-15 10:47:00' -INFO: restoring backup '1450194208824' of server 'mktg' -INFO: restoring backup to enterprisedb@192.168.2.24:/opt/restore -INFO: base backup restored -INFO: WAL file(s) will be streamed from the BART host -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: tablespace(s) restored -``` - -The following parameters are set in the `postgresql.auto.conf` file: - -```text -restore_command = 'scp -o BatchMode=yes -o PasswordAuthentication=no -enterprisedb@192.168.2.22:/opt/backup/mktg/archived_wals/%f %p' -recovery_target_time = '2015-12-15 10:47:00' -recovery_target_timeline = 1 -``` - -The following is a list of the restored files and subdirectories: - -```text -[root@localhost restore]# pwd -/opt/restore -[root@localhost restore]# ls -l -total 108 --rw------- 1 enterprisedb enterprisedb 208 Dec 15 10:43 backup_label -drwx------ 6 enterprisedb enterprisedb 4096 Dec 2 10:38 base -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 dbms_pipe -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 global -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_clog\ --rw------- 1 enterprisedb enterprisedb 4438 Dec 2 10:38 pg_hba.conf --rw------- 1 enterprisedb enterprisedb 1636 Nov 10 15:38 pg_ident.conf -drwxr-xr-x 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_log -drwx------ 4 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_multixact -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_notify -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_serial -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_snapshots -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:42 pg_stat -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 10:43 pg_stat_tmp -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_subtrans -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 pg_tblspc -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_twophase --rw------- 1 enterprisedb enterprisedb 4 Nov 10 15:38 PG_VERSION -drwx------ 2 enterprisedb enterprisedb 4096 Dec 15 11:00 pg_xlog --rw------- 1 enterprisedb enterprisedb 23906 Dec 15 11:00 -postgresql.conf --rw-r--r-- 1 enterprisedb enterprisedb 217 Dec 15 11:00 -postgresql.auto.conf -``` - -**Example** - -The following code sample performs a `RESTORE` operation with the `copy_wals_during_restore` parameter enabled to copy the archived WAL files to the local `/archived_wals` directory: - -```text --bash-4.1$ bart RESTORE -s hr -i hr_2017-03-29T13:50 -p -/opt/restore_pg96 -t 1 -g '2017-03-29 14:01:00' -INFO: restoring backup 'hr_2017-03-29T13:50' of server 'hr' -INFO: base backup restored -INFO: copying WAL file(s) to -postgres@192.168.2.24:/opt/restore_pg96/archived_wals -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: restore completed successfully -``` - -The following parameters are set in the `postgresql.auto.conf` file: - -```text -restore_command = 'cp archived_wals/%f %p' -recovery_target_time = '2017-03-29 14:01:00' -recovery_target_timeline = 1 -``` - -The following is a list of the restored files and subdirectories: - -```text --bash-4.1$ pwd -/opt/restore_pg96 --bash-4.1$ ls -l -total 128 -drwxr-xr-x 2 postgres postgres 4096 Mar 29 14:27 archived_wals --rw------- 1 postgres postgres 206 Mar 29 13:50 backup_label -drwx------ 5 postgres postgres 4096 Mar 29 12:25 base -drwx------ 2 postgres postgres 4096 Mar 29 14:27 global -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_clog -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_commit_ts -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_dynshmem --rw------- 1 postgres postgres 4212 Mar 29 13:18 pg_hba.conf --rw------- 1 postgres postgres 1636 Mar 29 12:25 pg_ident.conf -drwxr-xr-x 2 postgres postgres 4096 Mar 29 13:45 pg_log -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_logical -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_multixact -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_notify -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_replslot -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_serial -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_snapshots -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_stat -drwx------ 2 postgres postgres 4096 Mar 29 13:50 pg_stat_tmp -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_subtrans -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_tblspc -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_twophase --rw------- 1 postgres postgres 4 Mar 29 12:25 PG_VERSION -drwx------ 3 postgres postgres 4096 Mar 29 14:27 pg_xlog --rw------- 1 postgres postgres 169 Mar 29 13:24 postgresql.auto.conf --rw-r--r-- 1 postgres postgres 21458 Mar 29 14:27 postgresql.conf --rw-r--r-- 1 postgres postgres 118 Mar 29 14:27 postgresql.auto.conf -``` - - - -The following code sample displays restoring an [incremental backup](01_backup/#incremental_backup_using_checksum_algorithm) taken using `--checksum-algorithm=NONE` option. To restore this incremental backup, you must specify the `--disable-checksum` option to skip verifying MD5 or SHA256 checksum files. - -```text -[edb@localhost bin]$ ./bart restore -s ppas11 -i 1593507779811 -p /home/edb/RESTORE/ --disable-checksum -INFO: restoring incremental backup '1593507779811' of server 'ppas11' -INFO: base backup restored -INFO: writing recovery.conf file -INFO: WAL file(s) will be streamed from the BART host -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: incremental restore completed successfully -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx deleted file mode 100644 index 8ada69b5622..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_servers.html" ---- - -The `SHOW-SERVERS` subcommand displays information for the managed database servers listed in the BART configuration file. - -**Syntax:** - -```text -bart SHOW-SERVERS [ –s { | all } ] -``` - -The following table describes the `SHOW-SERVERS` option: - -| Option | Description | -| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all` }
`--server { \| all` } | `` is the name of the database server to which the `SHOW-SERVERS` actions are to be applied.
If `all` is specified or if the `-s` option is omitted, the actions are applied to all database servers. | - -**Example** - -The following code sample shows all the database servers managed by BART as returned by the `SHOW-SERVERS` subcommand: - -```text --bash-4.2$ bart SHOW-SERVERS -SERVER NAME : acctg -BACKUP FRIENDLY NAME: acctg_%year-%month-%dayT%hour:%minute -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -SERVER NAME : hr -BACKUP FRIENDLY NAME: hr_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : postgres@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Human Resources" -SERVER NAME : mktg -BACKUP FRIENDLY NAME: mktg_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : enterprisedb@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/mktg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED\ -DESCRIPTION : "Marketing" -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx deleted file mode 100644 index 03b7727add3..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_backups.html" ---- - -The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. - -**Syntax:** - -```text -bart SHOW-BACKUPS [ –s { | all } ] -[ -i { | | all } ] -[ -t ] -``` - -The following table describes the `SHOW-BACKUPS` options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all` }

`--server { \| all` } | `` is the name of the database server whose backup information is to be displayed.
If `all` is specified or if the option is omitted, the backup information for all database servers is displayed. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified or if the option is omitted, all backup information for the relevant database server is displayed. | -| `-t`
`--toggle` | Displays detailed backup information in list format. If the option is omitted, the default is a tabular format. | - -**Example** - -The following code sample shows the backup from database server `dev`: - -```text --bash-4.2$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -dev 1477579596637 dev_2016-10-27T10:46:36 none -2016-10-27 10:46:37 EDT 54.50 MB 96.00 MB 6 active -``` - -The following code sample shows detailed information using the `-t` option: - -```text --bash-4.2$ bart SHOW-BACKUPS -s dev -i 1477579596637 -t -SERVER NAME : dev -BACKUP ID : 1477579596637 -BACKUP NAME : dev_2016-10-27T10:46:36 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:46:37 EDT -BACKUP SIZE : 54.50 MB -WAL(S) SIZE : 80.00 MB -NO. OF WALS : 5 -FIRST WAL FILE : 0000000100000001000000EC -CREATION TIME : 2016-10-27 10:46:37 EDT -LAST WAL FILE : 0000000100000001000000F0 -CREATION TIME : 2016-10-27 11:22:01 EDT -``` - -The following code sample shows a listing of an incremental backup along with its parent backup: - -```text --bash-4.2$ bart SHOW-BACKUPS -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -acctg 1477580293193 acctg_2016-10-27 none -2016-10-27 10:58:13 EDT 16.45 MB 16.00 MB 1 active -acctg 1477580111358 acctg_2016-10-27 none 2016-10-27 10:55:11 EDT 59.71 -MB 16.00 MB 1 active -``` - -The following code sample shows the complete, detailed information of the incremental backup and the parent backup: - -```text --bash-4.2$ bart SHOW-BACKUPS -t -SERVER NAME : acctg -BACKUP ID : 1477580293193 -BACKUP NAME : none -BACKUP PARENT : acctg_2016-10-27 -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:58:13 EDT -BACKUP SIZE : 16.45 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 0000000100000002000000D9 -CREATION TIME : 2016-10-27 10:58:13 EDT -LAST WAL FILE : 0000000100000002000000D9 -CREATION TIME : 2016-10-27 10:58:13 EDT -SERVER NAME : acctg -BACKUP ID : 1477580111358 -BACKUP NAME : acctg_2016-10-27 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2016-10-27 10:55:11 EDT -BACKUP SIZE : 59.71 MB -WAL(S) SIZE : 16.00 MB -NO. OF WALS : 1 -FIRST WAL FILE : 0000000100000002000000D8 -CREATION TIME : 2016-10-27 10:55:12 EDT -LAST WAL FILE : 0000000100000002000000D8 -CREATION TIME : 2016-10-27 10:55:12 EDT -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx deleted file mode 100644 index 973ae05dc7d..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/verify_chksum.html" ---- - -The `VERIFY-CHKSUM` subcommand verifies the MD5 checksums of the full backups and any user-defined tablespaces for the specified database server or for all database servers. The checksum is verified by comparing the current checksum of the backup against the checksum when the backup was taken. - -!!! Note - The `VERIFY-CHKSUM` subcommand is only used for tar format backups. - -**Syntax:** - -```text -bart VERIFY-CHKSUM -[ –s { | all } ] -[ -i { | | all } ] -``` - -The following table describes the `VERIFY-CHKSUM` options: - -| Options | Description | -| ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all` } | `` is the name of the database server whose tar backup checksums are to be verified.
If `all` is specified or if the `-s` option is omitted, the checksums of all tar backups are verified for all database servers. | -| `-i { \| \| all` }

`--backupid { \| \| all` } | `` is the backup identifier of a tar format full backup whose checksum is to be verified along with any user-defined tablespaces. `` is the user-defined alphanumeric name for the full backup.
If `all` is specified or if the `-i` option is omitted, the checksums of all tar backups for the relevant database server are verified. | - -**Example** - -The following code sample verifies the checksum of all tar format backups of the specified database server: - -```text --bash-4.1$ bart VERIFY-CHKSUM -s acctg -i all -SERVER NAME BACKUP ID VERIFY -acctg 1430239348243 OK -acctg 1430232284202 OK -acctg 1430232016284 OK -acctg 1430231949065 OK -acctg 1429821844271 OK -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx deleted file mode 100644 index 12305fb7733..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx +++ /dev/null @@ -1,168 +0,0 @@ ---- -title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/running_the_bart_wal_scanner.html" ---- - -The BART WAL scanner is used to process each WAL file to find and record modified blocks in a corresponding MBM file. As a BART account user, use the BART WAL scanner to invoke the `bart-scanner` program located in the `/bin` directory. - -For detailed information about the WAL scanner and its usage, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -**Syntax:** - -```text -bart-scanner -[ -d ] -[ -c ] -{ –h | --v | ---daemon | --p | - | -RELOAD | -STOP ---checksum-algorithm } -``` - -When the `bart-scanner` program is invoked, it forks a separate process for each database server enabled with the `allow_incremental_backups` parameter. - -The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option: - -- If the `--daemon` option is specified, the WAL scanner process runs in the background. All output messages can be viewed in the BART log file. -- If the `--daemon` option is omitted, the WAL scanner process runs in the foreground. All output messages can be viewed from the terminal running the program as well as in the BART log file. - -The following table describes the `VERIFY-CHKSUM` options. - -| Options | Description | -| ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on WAL scanner usage. | -| `-v` `--version` | Displays the WAL scanner version information. | -| `-d` `--debug` | Displays debugging output while executing the WAL scanner with any of its options. | -| `-c ` `--config-path ` | Specifies `` as the full directory path to a BART configuration file. Use this option if you do not want to use the default BART configuration file `/etc/bart.cfg` | -| `--daemon` | Runs the WAL scanner as a background process. | -| `-p ` `--print ` | Specifies the full directory path to an MBM file whose content is to be printed. The `archived_wals` directory as specified in the the `archive_path` parameter in the `bart.cfg` file contains the MBM files. | -| `` | Specifies the full directory path to a WAL file to be scanned. The archive path directory contains the WAL files. Use it if a WAL file in the archive path is missing its MBM file. This option is to be used for assisting the EnterpriseDB support team for debugging problems that may have been encountered. | -| `RELOAD` | Reloads the BART configuration file. The keyword `RELOAD` is case-insensitive. The `RELOAD` option is useful if you make changes to the configuration file after the WAL scanner has been started. It will reload the configuration file and adjust the WAL scanners accordingly. For example, if a server section allowing incremental backups is removed from the BART configuration file, then the process attached to that server will stop. Similarly, if a server allowing incremental backups is added, a new WAL scanner process will be launched to scan the WAL files of that server. | -| `STOP` | Stops the WAL scanner. The keyword `STOP` is not case-sensitive. | -| `--checksum-algorithm` | While invoking the WAL scanner, you can specify one of the following values with the `--checksum-algorithm` option: `--checksum-algorithm=MD5` (default) to generate MD5 checksum files. `--checksum-algorithm=SHA256` to generate SHA256 checksum files. `--checksum-algorithm=NONE` to skip generating checksum files. | - -**Example** - -The following code sample demonstrates starting the WAL scanner to run interactively. The WAL scanner begins scanning existing WAL files in the archive path that have not yet been scanned (that is, there is no corresponding MBM file for the WAL file): - -```text --bash-4.2$ bart-scanner -INFO: process created for server 'acctg', pid = 5287 -INFO: going to parse backlog of WALs, if any. -INFO: WAL file to be processed: 0000000100000000000000ED -INFO: WAL file to be processed: 0000000100000000000000EE -INFO: WAL file to be processed: 0000000100000000000000EF -INFO: WAL file to be processed: 0000000100000000000000F0 -INFO: WAL file to be processed: 0000000100000000000000F1 -``` - -The following code sample is the content of the archive path showing the MBM files created for the WAL files. (The user name and group name of the files have been removed from the example to list the WAL files and MBM files in a more readable manner): - -```text -[root@localhost archived_wals]# pwd -/opt/backup/acctg/archived_wals -[root@localhost archived_wals]# ls -l -total 81944 --rw------- 1 ... ... 16777216 Dec 20 09:10 0000000100000000000000ED --rw------- 1 ... ... 16777216 Dec 20 09:06 0000000100000000000000EE --rw------- 1 ... ... 16777216 Dec 20 09:11 0000000100000000000000EF --rw------- 1 ... ... 16777216 Dec 20 09:15 0000000100000000000000F0 --rw------- 1 ... ... 16777216 Dec 20 09:16 0000000100000000000000F1 --rw------- 1 ... ... 305 Dec 20 09:16 0000000100000000000000F1.00000028.backup --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000ED00002800000000EE000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000EE00002800000000EF000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000EF00002800000000F0000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000F000002800000000F1000000.mbm --rw-rw-r-- 1 ... ... 161 Dec 20 09:18 -0000000100000000F100002800000000F2000000.mbm -``` - -To stop the interactively running WAL scanner, either enter `ctrl-C` at the terminal running the WAL scanner or invoke the `bart-scanner` program from another terminal with the `STOP` option: - -```text --bash-4.2$ bart-scanner STOP --bash-4.2$ -``` - -The terminal on which the WAL scanner was running interactively appears as follows after it has been stopped: - -```text --bash-4.2$ bart-scanner -INFO: process created for server 'acctg', pid = 5287 -INFO: going to parse backlog of WALs, if any. -INFO: WAL file to be processed: 0000000100000000000000ED -INFO: WAL file to be processed: 0000000100000000000000EE -INFO: WAL file to be processed: 0000000100000000000000EF -INFO: WAL file to be processed: 0000000100000000000000F0 -INFO: WAL file to be processed: 0000000100000000000000F1 -INFO: bart-scanner stopped --bash-4.2$ -``` - -The following code sample demonstrates invoking the WAL scanner to run as a background process with the `--daemon` option: - -```text --bash-4.2$ bart-scanner --daemon --bash-4.2$ -``` - -The WAL scanner runs as a background process. There is also a separate background process for each database server that has been enabled for WAL scanning with the `allow_incremental_backups` parameter in the BART configuration file: - -```text --bash-4.2$ ps -ef | grep bart - enterpr+ 4340 1 0 09:48 ? 00:00:00 bart-scanner --daemon - enterpr+ 4341 4340 0 09:48 ? 00:00:00 bart-scanner --daemon - enterpr+ 4415 3673 0 09:50 pts/0 00:00:00 grep --color=auto bart -``` - -To stop the WAL scanner processes, invoke the WAL scanner with the `STOP` option: - -```text --bash-4.2$ bart-scanner STOP --bash-4.2$ -``` - -The following command demonstrates scanning an individual WAL file: - -```text --bash-4.2$ bart-scanner /opt/backup/acctg/archived_wals/0000000100000000000000FF --bash-4.2$ -``` - -To print the content of an MBM file for assisting the EnterpriseDB support team for debugging problems that may have been encountered, use the `-p` option to specify the file as shown in the following code sample: - -```text --bash-4.2$ bart-scanner -p -/opt/backup/acctg/archived_wals/0000000100000000FF0000280000000100000000.mbm - -Header: -Version: 1.0:90500:1.2.0 -Scan Start: 2016-12-20 10:02:11 EST, Scan End: 2016-12-20 10:02:11 EST, Diff: 0 sec(s) -Start LSN: ff000028, End LSN: 100000000, TLI: 1 -flags: 0, Check Sum: f9cfe66ae2569894d6746b61503a767d - -Path: base/14845/16384 -NodeTag: BLOCK_CHANGE -Relation: relPath base/14845/16384, isTSNode 0, Blocks -*............................................................................. -First modified block: 0 -Total modified blocks: 1 - -Path: base/14845/16391 -NodeTag: BLOCK_CHANGE -Relation: relPath base/14845/16391, isTSNode 0, Blocks -*.............................................................................. -First modified block: 0 -Total modified blocks: 1 -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/index.mdx b/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/index.mdx deleted file mode 100644 index 20c71192ef2..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/01_bart_subcommands_examples/index.mdx +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: "BART Subcommand Syntax and Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/bart_subcommands_examples.html" ---- - - - -This section briefly describes each BART subcommand and provides an example. - -**Invoking BART** - -BART subcommands are invoked at the Linux command line as a BART user. You can invoke the `bart` program (located in the `/bin` directory) with the desired options to manage your BART installation. - -The following examples demonstrate ways of invoking BART. In these examples, the BART user account is named `bartuser`. - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ ./bart SHOW-SERVERS -``` - -To run BART from any current working directory: - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ bart SHOW-SERVERS -``` - -**Syntax for invoking BART** - -```text -bart [ ]... [ ] []... -``` - -You can use either abbreviated or long option forms on the command line (for example `-h` or `--help`). - -**General Options** - -You can specify the following general options with `bart`. - -`-h` or (`--help`) - -- Displays general syntax and information about BART usage. -- All subcommands support a help option (`-h, --help`). If the help option is specified, information is displayed regarding that particular subcommand. The subcommand, itself, is not executed. - -The following code sample displays the result of invoking the `--help` option for the `BACKUP` subcommand: - -```text --bash-4.2$ bart BACKUP --help -bart: backup and recovery tool - -Usage: -bart BACKUP [OPTION]... - -Options: --h, --help Show this help message and exit --s, --server Name of the server or 'all' (full backups only) to specify all servers --F, --format=p|t Backup output format (tar (default) or plain) --z, --gzip Enables gzip compression of tar files --c, --compress-level Specifies the compression level (1 through 9, 9 being - best compression) ---backup-name Specify a friendly name for the current backup ---parent Specify parent backup for incremental backup ---check Verify checksum of required mbm files -``` - -`-v` (or `--version`) - -The following code sample displays information returned by the `bart --version` subcommand: - -```text -[edb@localhost bin]$ bart --version -bart (EnterpriseDB) 2.5.2 -[edb@localhost bin]$ -``` - -`-d` (or `--debug`) - -The following code sample displays debugging output returned by the `bart MANAGE` subcommand: - -```text --bash-4.1$ bart -d MANAGE -n -DEBUG: Server: acctg, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -259200 (secs) ==> 72 hour(s) -DEBUG: Server: dev, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -1814400 (secs) ==> 504 hour(s) -DEBUG: Server: hr, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -7776000 (secs) ==> 2160 hour(s) -``` - -`-c` (or `--config-path) ` - -The following code sample demonstrates using the `-c` option to specify a non-default configuration file name and installation location: - -```text -$ su bartuser -Password: -$ export -LD_LIBRARY_PATH=/opt/PostgresPlus/9.6AS/lib/:$LD_LIBRARY_PATH -$ bart -c /home/bartuser/bart.cfg SHOW-SERVERS -``` - -
- -backup check_config delete init manage restore show_servers show_backups verify_chksum running_the_bart_wal_scanner - -
diff --git a/product_docs/docs/bart/2.6.2/bart_ref/02_additional_examples.mdx b/product_docs/docs/bart/2.6.2/bart_ref/02_additional_examples.mdx deleted file mode 100644 index 38a519f727d..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/02_additional_examples.mdx +++ /dev/null @@ -1,1473 +0,0 @@ ---- -title: "Additional Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/additional_examples.html" ---- - - - -This section lists examples of the following BART operations. - -- Restoring a database cluster with tablespaces. -- Restoring an incremental backup. -- Managing backups. -- Managing incremental backups. - -## Restoring a Database Cluster with Tablespaces - -The following code sample illustrates taking a backup and restoring a database cluster on a remote host containing tablespaces. For detailed information regarding using tablespaces, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -On an Advanced Server database running on a remote host, the following tablespaces are created for use by two tables: - -```text -edb=# CREATE TABLESPACE tblspc_1 LOCATION '/mnt/tablespace_1'; -CREATE TABLESPACE -edb=# CREATE TABLESPACE tblspc_2 LOCATION '/mnt/tablespace_2'; -CREATE TABLESPACE -edb=# \db - List of tablespaces -Name | Owner | Location -------------+-----------------+------------------- -pg_default | enterprisedb | -pg_global | enterprisedb | -tblspc_1 | enterprisedb | /mnt/tablespace_1 -tblspc_2 | enterprisedb | /mnt/tablespace_2 -(4 rows) - -edb=# CREATE TABLE tbl_tblspc_1 (c1 TEXT) TABLESPACE tblspc_1; -CREATE TABLE -edb=# CREATE TABLE tbl_tblspc_2 (c1 TEXT) TABLESPACE tblspc_2; -CREATE TABLE -edb=# \d tbl_tblspc_1 -Table "enterprisedb.tbl_tblspc_1" -Column | Type | Modifiers --------+------+----------- -c1 | text | -Tablespace: "tblspc_1" - -edb=# \d tbl_tblspc_2 -Table "enterprisedb.tbl_tblspc_2" -Column | Type | Modifiers --------+------+----------- -c1 | text | -Tablespace: "tblspc_2" -``` - -The following code sample shows the OIDs assigned to the tablespaces and the symbolic links to the tablespace directories: - -```text --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS/data/pg_tblspc --bash-4.1$ ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Nov 16 16:17 16587 ->/mnt/tablespace_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Nov 16 16:17 16588 ->/mnt/tablespace_2 -``` - -The BART configuration file contains the following settings. Note that the `tablespace_path` parameter does not have to be set at this point. - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -tablespace_path = -description = "Accounting" -``` - -After the necessary configuration steps are performed to ensure BART manages the remote database server, a full backup is taken as shown in the following code sample: - -```text --bash-4.1$ bart BACKUP -s acctg - -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1447709811516' -54521/54521 kB (100%), 3/3 tablespaces - -INFO: backup completed successfully -INFO: backup checksum: 594f69fe7d26af991d4173d3823e174f of 16587.tar -INFO: backup checksum: 7a5507567729a21c98a15c948ff6c015 of base.tar -INFO: backup checksum: ae8c62604c409635c9d9e82b29cc0399 of 16588.tar -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1447709811516 -BACKUP NAME: none -BACKUP LOCATION: /opt/backup/acctg/1447709811516 -BACKUP SIZE: 53.25 MB -BACKUP FORMAT: tar -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 3 -ChkSum File -594f69fe7d26af991d4173d3823e174f 16587.tar -7a5507567729a21c98a15c948ff6c015 base.tar -ae8c62604c409635c9d9e82b29cc0399 16588.tar - -TABLESPACE(s): 2 -Oid Name Location -16587 tblspc_1 /mnt/tablespace_1 -16588 tblspc_2 /mnt/tablespace_2 -START WAL LOCATION: 00000001000000000000000F -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2015-11-16 16:36:51 EST -STOP TIME: 2015-11-16 16:36:52 EST -TOTAL DURATION: 1 sec(s) -``` - -Note that in the output from the preceding example, checksums are generated for the tablespaces as well as the full backup. - -Within the backup subdirectory `1447709811516` of the BART backup catalog, the tablespace data is stored with file names `16587.tar.gz` and `16588.tar.gz` as shown below: - -```text --bash-4.1$ pwd -/opt/backup/acctg --bash-4.1$ ls -l -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 16:36 1447709811516 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 16:43 archived_wals --bash-4.1$ ls -l 1447709811516 -total 54536 --rw-rw-r-- 1 enterprisedb enterprisedb 19968 Nov 16 16:36 16587.tar --rw-rw-r-- 1 enterprisedb enterprisedb 19968 Nov 16 16:36 16588.tar --rw-rw-r-- 1 enterprisedb enterprisedb 949 Nov 16 17:05 backupinfo --rw-rw-r-- 1 enterprisedb enterprisedb 55792640 Nov 16 16:36 base.tar -``` - -When you are ready to restore the backup, in addition to creating the directory to which the main database cluster is to be restored, you must prepare the directories to which the tablespaces are to be restored. - -On the remote host, directories `/opt/restore_tblspc_1` and `/opt/restore_tblspc_2` are created and assigned the proper ownership and permissions as shown by the following example. The main database cluster is to be restored to `/opt/restore`. - -```text -[root@localhost opt]# mkdir restore_tblspc_1 -[root@localhost opt]# chown enterprisedb restore_tblspc_1 -[root@localhost opt]# chgrp enterprisedb restore_tblspc_1 -[root@localhost opt]# chmod 700 restore_tblspc_1 - -[root@localhost opt]# mkdir restore_tblspc_2 -[root@localhost opt]# chown enterprisedb restore_tblspc_2 -[root@localhost opt]# chgrp enterprisedb restore_tblspc_2 -[root@localhost opt]# chmod 700 restore_tblspc_2 -[root@localhost opt]# ls -l -total 20 -drwxr-xr-x 3 root daemon 4096 Nov 10 15:38 PostgresPlus -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:40 restore -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:40 -restore_tblspc_1 -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:41 -restore_tblspc_2 -drwxr-xr-x. 2 root root 4096 Nov 22 2013 rh -``` - -Set the `tablespace_path` parameter in the BART configuration file to specify the tablespace directories. The remote host user and IP address are specified by the `remote_host` configuration parameter. - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -tablespace_path = -16587=/opt/restore_tblspc_1;16588=/opt/restore_tblspc_2 - -description = "Accounting" -``` - -The following code sample demonstrates invoking the `RESTORE` subcommand: - -```text --bash-4.1$ bart RESTORE -s acctg -i 1447709811516 -p /opt/restore -INFO: restoring backup '1447709811516' of server 'acctg' -INFO: restoring backup to enterprisedb@192.168.2.24:/opt/restore -INFO: base backup restored -INFO: archiving is disabled -INFO: tablespace(s) restored -``` - -The following code sample shows the restored full backup (including the restored tablespaces): - -```text -bash-4.1$ pwd -/opt --bash-4.1$ ls -l restore -total 104 --rw------- 1 enterprisedb enterprisedb 206 Nov 16 16:36 backup_label.old -drwx------ 6 enterprisedb enterprisedb 4096 Nov 10 15:38 base -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:46 global -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_clog --rw------- 1 enterprisedb enterprisedb 4438 Nov 10 16:23 pg_hba.conf --rw------- 1 enterprisedb enterprisedb 1636 Nov 10 15:38 pg_ident.conf -drwxr-xr-x 2 enterprisedb enterprisedb 4096 Nov 16 17:45 pg_log -drwx------ 4 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_multixact -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:45 pg_notify -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_serial -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_snapshots -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_stat -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_stat_tmp -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_subtrans -drwx------ 2 enterprisedb enterprisedb 4096 Nov 16 17:42 pg_tblspc -drwx------ 2 enterprisedb enterprisedb 4096 Nov 10 15:38 pg_twophase --rw------- 1 enterprisedb enterprisedb 4 Nov 10 15:38 PG_VERSION -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 17:47 pg_xlog --rw------- 1 enterprisedb enterprisedb 23906 Nov 16 17:42 postgresql.conf --rw------- 1 enterprisedb enterprisedb 61 Nov 16 17:45 postmaster.opts --bash-4.1$ --bash-4.1$ ls -l restore_tblspc_1 -total 4 -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 16:18 -PG_9.6_201306121 --bash-4.1$ ls -l restore_tblspc_2 -total 4 -drwx------ 3 enterprisedb enterprisedb 4096 Nov 16 16:18 -PG_9.6_201306121 -``` - -The symbolic links in the `pg_tblspc` subdirectory point to the restored directory location: - -```text -bash-4.1$ pwd -/opt/restore/pg_tblspc --bash-4.1$ ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 21 Nov 16 17:42 16587 -> -/opt/restore_tblspc_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 21 Nov 16 17:42 16588 -> -/opt/restore_tblspc_2 -``` - -`psql` queries also show the restored tablespaces: - -```text -edb=# \db - - List of tablespaces -Name | Owner | Location -------------+--------------+----------------------- -pg_default | enterprisedb | -pg_global | enterprisedb | -tblspc_1 | enterprisedb | /opt/restore_tblspc_1 -tblspc_2 | enterprisedb | /opt/restore_tblspc_2 -``` - -## Restoring an Incremental Backup - -Restoring an incremental backup may require additional setup steps depending upon the host on which the incremental backup is to be restored. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -This section provides an example of creating backup chains and then restoring an incremental backup. - -**Creating a Backup Chain** - -A *backup chain* is the set of backups consisting of a full backup and all of its successive incremental backups. Tracing back on the parent backups of all incremental backups in the chain eventually leads back to that single, full backup. - -In the following example, the `allow_incremental_backups` parameter is set to `enabled` in the BART configuration file to permit incremental backups on the listed database server: - -```text -[BART] - -bart_host= enterprisedb@192.168.2.27 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -allow_incremental_backups = enabled -description = "Accounting" -``` - -After the database server has been started with WAL archiving enabled to the BART backup catalog, the WAL scanner is started: - -```text --bash-4.2$ bart-scanner --daemon -``` - -First, a full backup is taken. - -```text --bash-4.2$ bart BACKUP -s acctg --backup-name full_1 -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1490649204327'\ -63364/63364 kB (100%), 1/1 tablespace -INFO: backup completed successfully -INFO: backup checksum: aae27d4a7c09dffc82f423221154db7e of base.tar -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490649204327 -BACKUP NAME: full_1 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1490649204327 -BACKUP SIZE: 61.88 MB -BACKUP FORMAT: tar -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -aae27d4a7c09dffc82f423221154db7e base.tar -TABLESPACE(s): 0 -START WAL LOCATION: 00000001000000000000000E -BACKUP METHOD: streamed -BACKUP FROM: master -START TIME: 2017-03-27 17:13:24 EDT -STOP TIME: 2017-03-27 17:13:25 EDT -TOTAL DURATION: 1 sec(s) -``` - -A series of incremental backups are taken. The first incremental backup specifies the full backup as the parent. Each successive incremental backup then uses the preceding incremental backup as its parent. - -```text --bash-4.2$ bart BACKUP -s acctg -F p --parent full_1 --backup-name -incr_1-a -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649255649 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490649255649 -BACKUP NAME: incr_1-a -BACKUP PARENT: 1490649204327 -BACKUP LOCATION: /opt/backup/acctg/1490649255649 -BACKUP SIZE: 16.56 MB -BACKUP FORMAT: plain -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 0 -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000010 -STOP WAL LOCATION: 000000010000000000000010 -BACKUP METHOD: pg_start_backup -BACKUP FROM: master -START TIME: 2017-03-27 17:14:15 EDT -STOP TIME: 2017-03-27 17:14:16 EDT -TOTAL DURATION: 1 sec(s) --bash-4.2$ bart BACKUP -s acctg -F p --parent incr_1-a --backup-name -incr_1-b -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649336845 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -. -. -. --bash-4.2$ bart BACKUP -s acctg -F p --parent incr_1-b --backup-name -incr_1-c -INFO: creating incremental backup for server 'acctg' -INFO: checking mbm files /opt/backup/acctg/archived_wals -INFO: new backup identifier generated 1490649414316 -INFO: reading directory /opt/backup/acctg/archived_wals -INFO: all files processed -NOTICE: pg_stop_backup complete, all required WAL segments have been -archived -INFO: incremental backup completed successfully -. -. -. -``` - -The following output of the `SHOW-BACKUPS` subcommand lists the backup chain, which are backups `full_1, incr_1-a, incr_1-b, and incr_1-c`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -For the `full backup full_1`, the `BACKUP PARENT` field contains `none`. For each incremental backup, the `BACKUP PARENT` field contains the backup identifier or name of its parent backup. - -A second backup chain is created in the same manner with the `BACKUP` subcommand. The following example shows the addition of the resulting, second backup chain consisting of full backup `full_2` and incremental backups `incr_2-a` and `incr_2-b`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649605607 incr_2-b incr_2-a 2017-03-27 17:20:06 ... -acctg 1490649587702 incr_2-a full_2 2017-03-27 17:19:48 ... -acctg 1490649528633 full_2 none 2017-03-27 17:18:49 ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -The following additional incremental backups starting with `incr_1-b-1`, which designates `incr_1-b` as the parent, results in the forking from that backup into a second line of backups in the chain consisting of `full_1, incr_1-a, incr_1-b, incr_1-b-1, incr_1-b-2`, and `incr_1-b-3` as shown in the following list: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT BACKUP TIME ... -acctg 1490649791430 incr_1-b-3 incr_1-b-2 2017-03-27 17:23:12 ... -acctg 1490649763929 incr_1-b-2 incr_1-b-1 2017-03-27 17:22:44 ... -acctg 1490649731672 incr_1-b-1 incr_1-b 2017-03-27 17:22:12 ... -acctg 1490649605607 incr_2-b incr_2-a 2017-03-27 17:20:06 ... -acctg 1490649587702 incr_2-a full_2 2017-03-27 17:19:48 ... -acctg 1490649528633 full_2 none 2017-03-27 17:18:49 ... -acctg 1490649414316 incr_1-c incr_1-b 2017-03-27 17:16:55 ... -acctg 1490649336845 incr_1-b incr_1-a 2017-03-27 17:15:37 ... -acctg 1490649255649 incr_1-a full_1 2017-03-27 17:14:16 ... -acctg 1490649204327 full_1 none 2017-03-27 17:13:25 ... -``` - -**Restoring an Incremental Backup** - -Restoring an incremental backup is done with the `RESTORE` subcommand in the same manner as for restoring a full backup. Specify the backup identifier or backup name of the incremental backup to be restored as shown in the following example. - -```text --bash-4.2$ bart RESTORE -s acctg -p /opt/restore -i incr_1-b -INFO: restoring incremental backup 'incr_1-b' of server 'acctg' -INFO: base backup restored -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: incremental restore completed successfully -``` - -Restoring incremental backup `incr_1-b` as shown by the preceding example results in the restoration of full backup `full_1`, then incremental backups `incr_1-a` and finally, `incr_1-b`. - -## Managing Backups - -This section illustrates evaluating, marking, and deleting backups using the `MANAGE` subcommand using a redundancy retention policy and a recovery window retention policy. For detailed information about the `MANAGE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - - - -### Using a Redundancy Retention Policy - -The following code sample uses a redundancy retention policy to evaluate, mark, and delete backups as shown by the following server configuration: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The following list is the set of backups. Note that the last backup in the list has been marked as `keep`. - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 active -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -Invoke the `MANAGE` subcommand with the `-n` option to perform a dry run to observe which active backups would be changed to obsolete according to the retention policy as shown in the following code sample: - -```text --bash-4.1$ bart MANAGE -s acctg -n -INFO: processing server 'acctg', backup '1428768344061' -INFO: processing server 'acctg', backup '1428684537299' -INFO: processing server 'acctg', backup '1428589759899' -INFO: processing server 'acctg', backup '1428502049836' -INFO: marking backup '1428502049836' as obsolete -INFO: 6 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428422324880' -INFO: marking backup '1428422324880' as obsolete -INFO: 2 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428355371389' -``` - -The dry run shows that backups `1428502049836` and `1428422324880` would be marked as `obsolete`. - -!!! Note - A dry run does not change the backup status. The two backups that would be considered obsolete are still marked as `active`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 active -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -Invoke the `MANAGE` subcommand omitting the `-n` option to change and mark the status of the backups as `obsolete`: - -```text --bash-4.1$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1428768344061' -INFO: processing server 'acctg', backup '1428684537299' -INFO: processing server 'acctg', backup '1428589759899' -INFO: processing server 'acctg', backup '1428502049836' -INFO: marking backup '1428502049836' as obsolete -INFO: 6 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428422324880' -INFO: marking backup '1428422324880' as obsolete -INFO: 2 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1428355371389' -``` - -The obsolete backups can be observed in a number of ways. Use the `MANAGE` subcommand with the `-l` option to list the `obsolete` backups: - -```text --bash-4.1$ bart MANAGE -s acctg -l -INFO: 6 WAL file(s) will be removed -SERVER NAME: acctg -BACKUP ID: 1428502049836 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-08 10:07:30 EDT -BACKUP SIZE: 55.25 MB -WAL FILE(s): 6 -WAL FILE: 000000010000000100000003 -WAL FILE: 000000010000000100000002 -WAL FILE: 000000010000000100000001 -WAL FILE: 000000010000000100000000 -WAL FILE: 0000000100000000000000E3 -WAL FILE: 0000000100000000000000E2 -INFO: 2 WAL file(s) will be removed -SERVER NAME: acctg -BACKUP ID: 1428422324880 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-07 11:58:45 EDT -BACKUP SIZE: 54.53 MB -WAL FILE(s): 2 -WAL FILE: 0000000100000000000000E1 -WAL FILE: 0000000100000000000000E0 -``` - -The `STATUS` field of the `SHOW-BACKUPS` subcommand displays the current status: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428502049836 2015-04-08 10:07:30 EDT 55.25 MB 96.00 MB -6 obsolete -acctg 1428422324880 2015-04-07 11:58:45 EDT 54.53 MB 32.00 MB -2 obsolete -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - -The details of an individual backup can be displayed using the `SHOW-BACKUPS` subcommand with the `-t` option. Note the status in the `BACKUP STATUS` field. - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -i 1428502049836 -t -SERVER NAME : acctg -BACKUP ID : 1428502049836 -BACKUP NAME : none -BACKUP STATUS : obsolete -BACKUP TIME : 2015-04-08 10:07:30 EDT -BACKUP SIZE : 55.25 MB -WAL(S) SIZE : 96.00 MB -NO. OF WALS : 6 -FIRST WAL FILE : 0000000100000000000000E2 -CREATION TIME : 2015-04-08 10:07:30 EDT -LAST WAL FILE : 000000010000000100000003 -CREATION TIME : 2015-04-09 10:25:46 EDT -``` - -Use the `MANAGE` subcommand with the `-d` option to physically delete the `obsolete` backups including the unneeded WAL files. - -```text --bash-4.1$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1428502049836' -INFO: 6 WAL file(s) will be removed -INFO: removing WAL file '000000010000000100000003' -INFO: removing WAL file '000000010000000100000002' -INFO: removing WAL file '000000010000000100000001' -INFO: removing WAL file '000000010000000100000000' -INFO: removing WAL file '0000000100000000000000E3' -INFO: removing WAL file '0000000100000000000000E2' -INFO: removing obsolete backup '1428422324880' -INFO: 2 WAL file(s) will be removed -INFO: removing WAL file '0000000100000000000000E1' -INFO: removing WAL file '0000000100000000000000E0' -``` - -The `SHOW-BACKUPS` subcommand now displays the remaining backups marked as `active` or `keep`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -acctg 1428768344061 2015-04-11 12:05:46 EDT 5.72 MB 48.00 MB -3 active -acctg 1428684537299 2015-04-10 12:49:00 EDT 5.72 MB 272.00 MB -17 active -acctg 1428589759899 2015-04-09 10:29:27 EDT 5.65 MB 96.00 MB -6 active -acctg 1428355371389 2015-04-06 17:22:53 EDT 5.71 MB 16.00 MB -1 keep -``` - - - -### Using a Recovery Window Retention Policy - -This section illustrates the evaluation, marking, and deletion of backup using a recovery window retention policy. To use the recovery window retention policy, set the `retention_policy` parameter to the desired length of time for the recovery window. - -This section provides examples of the following: - -- How to view the calculated recovery window. -- How to evaluate, mark, and delete backup using a recovery window retention policy. - -#### Viewing the Recovery Window - -You can view the actual, calculated recovery window by invoking any of the following subcommands: - -- `MANAGE` subcommand in debug mode (along with the `-n` option). -- `SHOW-SERVERS` subcommand. - -##### Viewing the Recovery Window Using the Manage Subcommand - -When invoking BART in debug mode with the `MANAGE` subcommand and the `-n` option, the length of the recovery window is calculated based on the `retention_policy` setting and the current date/time. - -For example, using the following `retention_policy` settings: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -backup-name = acctg_%year-%month-%dayT%hour:%minute:%second -description = "Accounting" - -[DEV] - -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 WEEKS -description = "Development" - -[HR] - -host = 127.0.0.1 -port = 5432 -user = postgres -retention_policy = 3 MONTHS -description = "Human Resources" -``` - -If the `MANAGE` subcommand is invoked in debug mode along with the `-n` option on 2015-04-17, the following results are displayed: - -```text --bash-4.1$ bart -d MANAGE -n -DEBUG: Server: acctg, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -259200 (secs) ==> 72 hour(s) -DEBUG: Server: dev, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -1814400 (secs) ==> 504 hour(s) -DEBUG: Server: hr, Now: 2015-04-17 16:34:03 EDT, RetentionWindow: -7776000 (secs) ==> 2160 hour(s) -``` - -For server `acctg`, 72 hours translates to a recovery window of 3 days. - -For server `dev`, 504 hours translates to a recovery window of 21 days (3 weeks). - -For server `hr`, 2160 hours translates to a recovery window of 90 days (3 months). - -For a setting of ` MONTHS`, the calculated total number of days for the recovery window is dependent upon the actual number of days in the preceding months from the current date/time. Thus, ` MONTHS` is not always exactly equivalent to ` x 30 DAYS`. For example, if the current date/time is in the month of March, a 1-month recovery window would be equivalent to only 28 days because the preceding month is February. Thus, for a current date of March 31, a 1-month recovery window would start on March 3. However, the typical result is that the day of the month of the starting recovery window boundary will be the same day of the month of when the `MANAGE` subcommand is invoked. - -##### Viewing the Recovery Window Using the Show-Servers Subcommand - -This section provides an example of viewing the recovery window using the `SHOW-SERVERS` subcommand; the `RETENTION POLICY` field displays the start of the recovery window. - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-day recovery window as the active backups. - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -description = "Accounting" -``` - -The start of the 3-day recovery window displayed in the `RETENTION POLICY` field is `2015-04-07 14:57:36 EDT` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-04-07 14:57:36 EDT` would be considered active. Backups taken prior to `2015-04-07 14:57:36 EDT` would be considered obsolete except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 14:57:33 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 2015-04-07 14:57:36 EDT -DISK UTILIZATION : 824.77 MB -NUMBER OF ARCHIVES : 37 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/acctg/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Accounting" -``` - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-week recovery window as the `active` backups. - -```text -[DEV] -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 WEEKS -description = "Development" -``` - -The start of the 3-week recovery window displayed in the `RETENTION POLICY` field is `2015-03-20 14:59:42 EDT` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-03-20 14:59:42 EDT` would be considered `active`. Backups taken prior to `2015-03-20 14:59:42 EDT` would be considered `obsolete` except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 14:59:39 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s dev -SERVER NAME : dev -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5445 -REMOTE HOST : -RETENTION POLICY : 2015-03-20 14:59:42 EDT -DISK UTILIZATION : 434.53 MB -NUMBER OF ARCHIVES : 22 -ARCHIVE PATH : /opt/backup/dev/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/dev/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Development" -``` - -In the following code sample, the recovery window retention policy setting considers the backups taken within a 3-month recovery window as the `active` backups. - -```text -[HR] -host = 127.0.0.1 -port = 5432 -user = postgres -retention_policy = 3 MONTHS -description = "Human Resources" -``` - -The start of the 3-month recovery window displayed in the `RETENTION POLICY` field is `2015-01-10 14:04:23 EST` when the `SHOW-SERVERS` subcommand is invoked on `2015-04-10`. - -At this current point in time, backups taken on or after `2015-01-10 14:04:23 EST` would be considered `active`. Backups taken prior to `2015-01-10 14:04:23 EST` would be considered `obsolete`, except for backups marked as `keep`. - -```text --bash-4.1$ date -Fri Apr 10 15:04:19 EDT 2015 --bash-4.1$ --bash-4.1$ bart SHOW-SERVERS -s hr -SERVER NAME : hr -HOST NAME : 127.0.0.1 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : -RETENTION POLICY : 2015-01-10 14:04:23 EST -DISK UTILIZATION : 480.76 MB -NUMBER OF ARCHIVES : 26 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Human Resources" -``` - -#### Evaluating, Marking, and Deleting Backup Using a Recovery Window Retention Policy - -The following code sample uses a recovery window retention policy to evaluate, mark, and delete backups as shown by the following server configuration: - -```text -[DEV] -host = 127.0.0.1 -port = 5445 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 DAYS -description = "Development" -``` - -The following is the current set of backups. Note that the last backup in the list has been marked as `keep`. - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB -14 active -dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB -3 active -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -The current date and time is `2015-04-13 16:46:35 EDT` as shown below: - -```text --bash-4.1$ date -Mon Apr 13 16:46:35 EDT 2015 -``` - -Thus, a 3-day recovery window would evaluate backups prior to `2015-04-10 16:46:35 EDT` as `obsolete` except for those marked as `keep`. - -Invoke the `MANAGE` subcommand with the `-n` option to perform a dry run to observe which active backups would be changed to `obsolete` according to the retention policy. - -```text --bash-4.1$ bart MANAGE -s dev -n -INFO: processing server 'dev', backup '1428933278236' -INFO: processing server 'dev', backup '1428862187757' -INFO: processing server 'dev', backup '1428768351638' -INFO: processing server 'dev', backup '1428684544008' -INFO: marking backup '1428684544008' as obsolete -INFO: 14 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428590536488' -INFO: marking backup '1428590536488' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428502171990' -``` - -The dry run shows that backups `1428684544008` and `1428590536488` would be marked as `obsolete`. - -Also note that a dry run does not change the backup status. The two backups that would be considered obsolete are still marked as `active`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev\ - SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE - WAL FILES STATUS - dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB - 1 active - dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB - 2 active - dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB - 2 active - dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB - 14 active - dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB - 3 active - dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB - 5 keep -``` - -Invoke the `MANAGE` subcommand omitting the `-n` option to change and mark the status of the backups as `obsolete`: - -```text --bash-4.1$ bart MANAGE -s dev -INFO: processing server 'dev', backup '1428933278236' -INFO: processing server 'dev', backup '1428862187757' -INFO: processing server 'dev', backup '1428768351638' -INFO: processing server 'dev', backup '1428684544008' -INFO: marking backup '1428684544008' as obsolete -INFO: 14 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428590536488' -INFO: marking backup '1428590536488' as obsolete -INFO: 3 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: processing server 'dev', backup '1428502171990' -``` - -The obsolete backups can be observed in a number of ways. Use the `MANAGE` subcommand with the `-l` option to list the `obsolete` backups: - -```text --bash-4.1$ bart MANAGE -s dev -l -INFO: 14 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -SERVER NAME: dev -BACKUP ID: 1428684544008 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-10 12:49:06 EDT -BACKUP SIZE: 5.65 MB -WAL FILE(s): 14 -UNUSED WAL FILE(s): 1 -WAL FILE: 00000001000000000000002E -WAL FILE: 00000001000000000000002D -WAL FILE: 00000001000000000000002C -WAL FILE: 00000001000000000000002B -WAL FILE: 00000001000000000000002A -WAL FILE: 000000010000000000000029 -WAL FILE: 000000010000000000000028 -WAL FILE: 000000010000000000000027 -WAL FILE: 000000010000000000000026 -WAL FILE: 000000010000000000000025 -WAL FILE: 000000010000000000000024 -WAL FILE: 000000010000000000000023 -WAL FILE: 000000010000000000000022 -WAL FILE: 000000010000000000000021 -UNUSED WAL FILE: 00000001000000000000000F.00000028 -INFO: 3 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -SERVER NAME: dev -BACKUP ID: 1428590536488 -BACKUP STATUS: obsolete -BACKUP TIME: 2015-04-09 10:42:18 EDT\ -BACKUP SIZE: 5.65 MB -WAL FILE(s): 3 -UNUSED WAL FILE(s): 1 -WAL FILE: 000000010000000000000020 -WAL FILE: 00000001000000000000001F -WAL FILE: 00000001000000000000001E -UNUSED WAL FILE: 00000001000000000000000F.00000028 -``` - -The `STATUS` field of the `SHOW-BACKUPS` subcommand displays the current status: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428684544008 2015-04-10 12:49:06 EDT 5.65 MB 224.00 MB -14 obsolete -dev 1428590536488 2015-04-09 10:42:18 EDT 5.65 MB 48.00 MB -3 obsolete -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -The details of an individual backup can be displayed using the `SHOW-BACKUPS` subcommand with the `-t` option. Note the status in the `BACKUP STATUS` field. - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -i 1428684544008 -t -SERVER NAME : dev -BACKUP ID : 1428684544008 -BACKUP NAME : none -BACKUP STATUS : obsolete -BACKUP TIME : 2015-04-10 12:49:06 EDT -BACKUP SIZE : 5.65 MB -WAL(S) SIZE : 224.00 MB -NO. OF WALS : 14 -FIRST WAL FILE : 000000010000000000000021 -CREATION TIME : 2015-04-10 12:49:06 EDT -LAST WAL FILE : 00000001000000000000002E -CREATION TIME : 2015-04-11 12:02:15 EDT -``` - -Use the `MANAGE` subcommand with the `-d` option to physically delete the obsolete backups including the unneeded WAL files. - -```text --bash-4.1$ bart MANAGE -s dev -d -INFO: removing all obsolete backups of server 'dev' -INFO: removing obsolete backup '1428684544008' -INFO: 14 WAL file(s) will be removed -INFO: 1 Unused WAL file(s) will be removed -INFO: removing WAL file '00000001000000000000002E' -INFO: removing WAL file '00000001000000000000002D' -INFO: removing WAL file '00000001000000000000002C' -INFO: removing WAL file '00000001000000000000002B' -INFO: removing WAL file '00000001000000000000002A' -INFO: removing WAL file '000000010000000000000029' -INFO: removing WAL file '000000010000000000000028' -INFO: removing WAL file '000000010000000000000027' -INFO: removing WAL file '000000010000000000000026' -INFO: removing WAL file '000000010000000000000025' -INFO: removing WAL file '000000010000000000000024' -INFO: removing WAL file '000000010000000000000023' -INFO: removing WAL file '000000010000000000000022' -INFO: removing WAL file '000000010000000000000021' -INFO: removing (unused) WAL file '00000001000000000000000F.00000028' -INFO: removing obsolete backup '1428590536488' -INFO: 3 WAL file(s) will be removed -INFO: removing WAL file '000000010000000000000020' -INFO: removing WAL file '00000001000000000000001F' -INFO: removing WAL file '00000001000000000000001E' -``` - -The `SHOW-BACKUPS` subcommand now displays the remaining backups marked as `active` or `keep`: - -```text --bash-4.1$ bart SHOW-BACKUPS -s dev -SERVER NAME BACKUP ID BACKUP TIME BACKUP SIZE WAL(s) SIZE -WAL FILES STATUS -dev 1428933278236 2015-04-13 09:54:40 EDT 5.65 MB 16.00 MB -1 active -dev 1428862187757 2015-04-12 14:09:50 EDT 5.65 MB 32.00 MB -2 active -dev 1428768351638 2015-04-11 12:05:54 EDT 5.65 MB 32.00 MB -2 active -dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB -5 keep -``` - -## Managing Incremental Backups - -This section illustrates evaluating, marking, and deleting incremental backups using the `MANAGE` and `DELETE` subcommands utilizing redundancy retention policy and recovery window retention policy. For detailed information about the `MANAGE` and `DELETE` subcommands, as well as the redundancy retention and recovery window retention policy, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - -- [Using a Redundancy Retention Policy](#redundancy_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 3 backup redundancy retention policy is in effect. -- [Using a Recovery Window Retention Policy](#recovery_window_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 1-day recovery window retention policy is in effect. - - - -### Using a Redundancy Retention Policy - -The following code sample uses the `MANAGE` and `DELETE` subcommands to evaluate, mark, and delete incremental backups when a 3 backup redundancy retention policy is in effect. The example uses the following server configuration: - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The example uses the following set of backups. In these code samples, some columns have been omitted from the `SHOW-BACKUPS` output to display the relevant information in a more observable manner. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -There is one backup chain. The first backup is the initial full backup. - -Backup chain: `1481749619582 => 1481749651927 => 1481749673603 => 1481749696905` - -The `MANAGE` subcommand is invoked as shown by the following: - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481749619582' -INFO: 2 Unused WAL file(s) present -INFO: 4 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The following code sample shows the resulting status of the backups: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -The status remains active for all backups. Even though the total number of backups exceeds the 3 backup redundancy retention policy, it is only the total number of full backups that is used to determine if the redundancy retention policy has been exceeded. Additional full backups are added including a second backup chain. The following example shows the resulting list of backups: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... active -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... active -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... active -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... active -``` - -Second backup chain: `1481749997807 => 1481750098924` - -The `MANAGE` subcommand is invoked, but now with a total of four active full backups. - -```text --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481750365397' -INFO: processing server 'acctg', backup '1481749997807' -INFO: processing server 'acctg', backup '1481749992003' -INFO: processing server 'acctg', backup '1481749619582' -INFO: marking backup '1481749619582' as obsolete -INFO: 3 incremental(s) of backup '1481749619582' will be marked obsolete -INFO: marking incremental backup '1481749696905' as obsolete -INFO: marking incremental backup '1481749673603' as obsolete -INFO: marking incremental backup '1481749651927' as obsolete -INFO: 4 WAL file(s) marked obsolete -INFO: 2 Unused WAL file(s) present -INFO: 4 Unused file(s) (WALs included) present, use 'MANAGE -l' for the -list -``` - -The oldest full backup and its chain of incremental backups are now marked as obsolete. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -acctg 1481749696905 ... 1481749673603 2016-12-14 16:08:17 EST ... obsolete -acctg 1481749673603 ... 1481749651927 2016-12-14 16:07:53 EST ... obsolete -acctg 1481749651927 ... 1481749619582 2016-12-14 16:07:32 EST ... obsolete -acctg 1481749619582 ... none 2016-12-14 16:07:00 EST ... obsolete -``` - -Invoking the `MANAGE` subcommand with the `-d` option deletes the entire obsolete backup chain. - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1481749619582' -INFO: 4 WAL file(s) will be removed -INFO: 3 incremental(s) of backup '1481749619582' will be removed -INFO: removing obsolete incremental backup '1481749696905' -INFO: removing obsolete incremental backup '1481749673603' -INFO: removing obsolete incremental backup '1481749651927' -INFO: removing WAL file '000000010000000100000000' -INFO: removing WAL file '0000000100000000000000FF' -INFO: removing WAL file '0000000100000000000000FE' -INFO: removing WAL file '0000000100000000000000FD' -INFO: 16 Unused file(s) will be removed -INFO: removing (unused) file '000000010000000100000004.00000028.backup' -. -. -. -INFO: removing (unused) file -'0000000100000000FB00002800000000FC000000.mbm' -``` - -The following code sample shows the remaining full backups and the second backup chain. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481750365397 ... none 2016-12-14 16:19:26 EST ... active -acctg 1481750098924 ... 1481749997807 2016-12-14 16:14:59 EST ... active -acctg 1481749997807 ... none 2016-12-14 16:13:18 EST ... active -acctg 1481749992003 ... none 2016-12-14 16:13:12 EST ... active -``` - - - -### Using a Recovery Window Retention Policy - -The following example demonstrates using the `MANAGE` and `DELETE` subcommands to evaluate, mark, and delete incremental backups when a 1-day recovery window retention policy is in effect. The example uses the following server configuration: - -```text -[ACCTG] - -host = 192.168.2.24 -port = 5445 -user = enterprisedb -cluster_owner = enterprisedb -remote_host = enterprisedb@192.168.2.24 -allow_incremental_backups = enabled -retention_policy = 1 DAYS -description = "Accounting" -``` - -The example uses the following set of backups. In the samples, some columns have been omitted from the `SHOW-BACKUPS` output to display the relevant information in a more observable manner. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST ... active -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -There are two backup chains. In each of the following chains, the first backup is the initial full backup. - -First backup chain: `1481552078404 => 1481553088053 => 1481553914533 => 1481554802918 => 1481559014359` - -Second backup chain: `1481553651165 => 1481554203288 => 1481559303348` - -The `MANAGE` subcommand is invoked when the first full backup `1481552078404` falls out of the recovery window. When the `MANAGE` subcommand is invoked, it is `2016-12-13 09:20:03 EST`, thus making the start of the 1-day recovery window at `2016-12-12 09:20:03 EST` exactly one day earlier. This backup was taken at `2016-12-12 09:14:39 EST`, which is about 5 ½ minutes before the start of the recovery window, thus making the backup obsolete. - -```text --bash-4.2$ date -Tue Dec 13 09:20:03 EST 2016 --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481553651165' -INFO: processing server 'acctg', backup '1481552078404' -INFO: marking backup '1481552078404' as obsolete -INFO: 4 incremental(s) of backup '1481552078404' will be marked obsolete -INFO: marking incremental backup '1481559014359' as obsolete -INFO: marking incremental backup '1481554802918' as obsolete -INFO: marking incremental backup '1481553914533' as obsolete -INFO: marking incremental backup '1481553088053' as obsolete -INFO: 7 WAL file(s) marked obsolete -INFO: 1 Unused WAL file(s) present -INFO: 2 Unused file(s) (WALs included) present, use 'MANAGE -l' for the list -``` - -The incremental backup date and time are within the recovery window since they were taken after the start of the recovery window of `2016-12-12 09:20:03 EST`, but all backups in the chain are marked as `obsolete`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg\ -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST -... obsolete -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST -... obsolete -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -The following code sample shows how the entire backup chain is changed back to active status by invoking the `MANAGE` subcommand with the `-c nokeep` option on the full backup of the chain. - -```text --bash-4.2$ bart MANAGE -s acctg -c nokeep -i 1481552078404 -INFO: changing status of backup '1481552078404' of server 'acctg' from -'obsolete' to 'active' -INFO: status of 4 incremental(s) of backup '1481552078404' will be -changed -INFO: changing status of incremental backup '1481559014359' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481554802918' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481553914533' of server -'acctg' from 'obsolete' to 'active' -INFO: changing status of incremental backup '1481553088053' of server -'acctg' from 'obsolete' to 'active' -INFO: 7 WAL file(s) changed -``` - -The backup chain has now been reset to active status. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481559014359 ... 1481554802918 2016-12-12 11:10:14 EST ... active -acctg 1481554802918 ... 1481553914533 2016-12-12 10:00:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -The following code sample shows usage of the `DELETE` subcommand on an incremental backup. The specified incremental backup `1481554802918` in the first backup chain as well as its successive incremental backup `1481559014359` are deleted. - -```text --bash-4.2$ bart DELETE -s acctg -i 1481554802918 -INFO: deleting backup '1481554802918' of server 'acctg' -INFO: deleting backup '1481554802918' -INFO: 1 incremental backup(s) will be deleted -INFO: deleting incremental backup '1481559014359' -INFO: WALs of deleted backup(s) will belong to prior backup(if any), or -will be marked unused -INFO: 2 Unused file(s) will be removed -INFO: removing (unused) file '0000000100000000000000BA' -INFO: removing (unused) file -'0000000100000000BA00002800000000BB000000.mbm' -INFO: backup(s) deleted -``` - -The results show that the backups `1481554802918` and `1481559014359` are no longer listed by the `SHOW-BACKUPS` subcommand. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME ... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST ... active -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST ... active -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST ... active -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST ... active -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST ... active -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST ... active -``` - -The `MANAGE` subcommand is invoked again. This time both backup chains are marked `obsolete` since the full backups of both chains fall out of the start of the recovery window, which is now `2016-12-12 09:55:03 EST`. - -```text --bash-4.2$ date -Tue Dec 13 09:55:03 EST 2016 --bash-4.2$ bart MANAGE -s acctg -INFO: processing server 'acctg', backup '1481553651165' -INFO: marking backup '1481553651165' as obsolete -INFO: 2 incremental(s) of backup '1481553651165' will be marked obsolete -INFO: marking incremental backup '1481559303348' as obsolete -INFO: marking incremental backup '1481554203288' as obsolete -INFO: 38 WAL file(s) marked obsolete -INFO: processing server 'acctg', backup '1481552078404' -INFO: marking backup '1481552078404' as obsolete -INFO: 2 incremental(s) of backup '1481552078404' will be marked obsolete -INFO: marking incremental backup '1481553914533' as obsolete -INFO: marking incremental backup '1481553088053' as obsolete -INFO: 7 WAL file(s) marked obsolete -``` - -The following code sample shows both backup chains marked as `obsolete`. - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... obsolete -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... obsolete -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... obsolete -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -The following code sample demonstrates using the `MANAGE` subcommand with the `-c keep` option to keep a backup chain indefinitely. The `MANAGE` subcommand with the `-c keep` option must specify the backup identifier or backup name of the full backup of the chain, and not any incremental backup. - -```text --bash-4.2$ bart MANAGE -s acctg -c keep -i 1481553651165 -INFO: changing status of backup '1481553651165' of server 'acctg' from -'obsolete' to 'keep' -INFO: status of 2 incremental(s) of backup '1481553651165' will be -changed -INFO: changing status of incremental backup '1481559303348' of server -'acctg' from 'obsolete' to 'keep' -INFO: changing status of incremental backup '1481554203288' of server -'acctg' from 'obsolete' to 'keep' -INFO: 38 WAL file(s) changed -``` - -The full backup `1481553651165` and its successive incremental backups `1481554203288` and `1481559303348` have been changed to `keep` status: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... keep -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... keep -acctg 1481553914533 ... 1481553088053 2016-12-12 09:45:14 EST -... obsolete -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... keep -acctg 1481553088053 ... 1481552078404 2016-12-12 09:31:28 EST -... obsolete -acctg 1481552078404 ... none 2016-12-12 09:14:39 EST -... obsolete -``` - -Finally, the `MANAGE` subcommand with the `-d` option is used to delete the `obsolete` backup chain: - -```text --bash-4.2$ bart MANAGE -s acctg -d -INFO: removing all obsolete backups of server 'acctg' -INFO: removing obsolete backup '1481552078404' -INFO: 7 WAL file(s) will be removed -INFO: 2 incremental(s) of backup '1481552078404' will be removed -INFO: removing obsolete incremental backup '1481553914533' -INFO: removing obsolete incremental backup '1481553088053' -INFO: removing WAL file '0000000100000000000000C1' -INFO: removing WAL file '0000000100000000000000C0' -INFO: removing WAL file '0000000100000000000000BF' -INFO: removing WAL file '0000000100000000000000BE' -INFO: removing WAL file '0000000100000000000000BD' -INFO: removing WAL file '0000000100000000000000BC' -INFO: removing WAL file '0000000100000000000000BB' -INFO: 48 Unused file(s) will be removed -INFO: removing (unused) file '0000000100000000000000FA' -. -. -. -INFO: removing (unused) file '0000000100000000000000BB.00000028.backup' -``` - -Only the backup chain with the `keep` status remains as shown below: - -```text --bash-4.2$ bart SHOW-BACKUPS -s acctg -SERVER NAME BACKUP ID ... BACKUP PARENT BACKUP TIME -... STATUS -acctg 1481559303348 ... 1481554203288 2016-12-12 11:15:03 EST -... keep -acctg 1481554203288 ... 1481553651165 2016-12-12 09:50:03 EST -... keep -acctg 1481553651165 ... none 2016-12-12 09:40:51 EST -... keep -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx b/product_docs/docs/bart/2.6.2/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx deleted file mode 100644 index b1527216806..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx +++ /dev/null @@ -1,1385 +0,0 @@ ---- -title: "Sample BART System with Local and Remote Database Servers" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/sample_bart_system_with_local_and_remote_database_servers.html" ---- - - - -This section describes a sample BART managed backup and recovery system consisting of both local and remote database servers. The complete steps to configure and operate the system are provided. - -For detailed information about configuring a BART system, see the *EDB Backup and Recovery Installation and Upgrade Guide*. For detailed information about the operational procedures and BART subcommands, see the *EDB Backup and Recovery User Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). - -The environment for this sample system is as follows: - -- BART on host `192.168.2.22` running with BART user account `enterprisedb` -- Local Advanced Server on host `192.168.2.22` running with user account `enterprisedb` -- Remote Advanced Server on host `192.168.2.24` running with user account `enterprisedb` -- Remote PostgreSQL server on host `192.168.2.24` running with user account `postgres` - -Passwordless SSH/SCP connections are required between the following: - -- BART on host `192.168.2.22` and the local Advanced Server on the same host `192.168.2.22` -- BART on host `192.168.2.22` and the remote Advanced Server on host `192.168.2.24` -- BART on host `192.168.2.22` and the remote PostgreSQL server on host `192.168.2.24` - -The following sections demonstrate configuring and taking full backups only. To support incremental backups as well, enable the `allow_incremental_backups` parameter for the desired database servers and use the `WAL scanner` program. - -- [The BART Configuration File](#bart_configuration_file) shows the settings used in the BART configuration file. -- [Establishing SSH/SCP Passwordless Connections](#establishing-sshscp-passwordless-connections) provides an example of how to establish an SSH/SCP passwordless connection. -- [Configuring a Replication Database User](#configuring-a-replication-database-user) provides an example of how to configure the replication database user. -- [WAL Archiving Configuration Parameters](#wal-archiving-configuration-parameters) provides an example of how to configure WAL archiving. -- [Creating the BART Backup Catalog](#creating-the-bart-backup-catalog-backup_path) provides information about creating a BART Backup Catalog. -- [Starting the Database Servers with WAL Archiving](#starting-the-database-servers-with-wal-archiving) provides example of starting the database servers with WAL archiving. -- [Taking a Full Backup](#taking-a-full-backup) illustrates taking the first full backup of the database servers. -- [Using Point-In-Time Recovery](#using-point-in-time-recovery) demonstrates the point-in-time recovery operation on the remote PostgreSQL database server. - - - -## The BART Configuration File - -The following code sample shows the settings used in the BART configuration file for the examples that follow: - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" - -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" - -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - - - -## Establishing SSH/SCP Passwordless Connections - -This section demonstrates how passwordless SSH/SCP connections are established with the authorized public keys files. - - - -### Generating a Public Key File for the BART User Account - -The BART user account is `enterprisedb` with a home directory of `/opt/PostgresPlus/9.6AS`. - -To generate the public key file, as a root user, first create the `.ssh` subdirectory in the BART user’s home directory and assign ownership of this directory to the `enterprisedb` user, ensuring there are no groups or other users that can access the `.ssh` directory. - -```text -[root@localhost 9.6AS]# pwd -/opt/PostgresPlus/9.6AS -[root@localhost 9.6AS]# mkdir .ssh -[root@localhost 9.6AS]# chown enterprisedb .ssh -[root@localhost 9.6AS]# chgrp enterprisedb .ssh -[root@localhost 9.6AS]# chmod 700 .ssh -[root@localhost 9.6AS]# ls -la | grep ssh -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 13:02 .ssh -``` - -Generate the public key file: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key -(/opt/PostgresPlus/9.6AS/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa. -Your public key has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa.pub. -The key fingerprint is: -de:65:34:d6:b1:d2:32:3c:b0:43:c6:a3:c0:9f:f4:64 -enterprisedb@localhost.localdomain -The key's randomart image is: -+----[ RSA 2048]----+ -| . .+ . | -| o .oE+ o o | -| + * o.X + | -| + .+ * | -| S o | -| . . o | -| . . | -| - | -| | -+-------------------+ -``` - -The following are the resulting files. `id_rsa.pub` is the public key file of BART user account `enterprisedb`. - -```text --bash-4.1$ ls -l .ssh -total 8 --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -### Configuring Access between Local Advanced Server and the BART Host - -Even when the Advanced Server database is on the same host as the BART user account, and the Advanced Server database cluster owner is also the BART user account (`enterprisedb` is this case), a passwordless SSH/SCP connection must be established from the same user account to itself. - -On the BART host where the public key file was just generated (as shown in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account)), create the authorized keys file by appending the public key file to any existing authorized keys file. - -Log into the BART host as the BART user account and append the public key file, `id_rsa.pub` onto the `authorized_keys` file in the same `.ssh` directory. - -```text -[user@localhost ~]$ su - enterprisedb -Password: -Last login: Thu Mar 23 10:27:35 EDT 2017 on pts/0 --bash-4.2$ pwd -/opt/PostgresPlus/9.6AS --bash-4.2$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts --bash-4.2$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys --bash-4.2$ ls -l .ssh -total 16 --rw-rw-r-- 1 enterprisedb enterprisedb 416 Mar 23 10:33 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts -``` - -The `authorized_keys` file must have file permission `600` as set by the following `chmod 600` command, or the passwordless connection will fail: - -```text --bash-4.2$ chmod 600 ~/.ssh/authorized_keys --bash-4.2$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 416 Mar 23 10:33 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Mar 23 09:54 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Mar 23 09:54 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 345 Mar 23 10:05 known_hosts -``` - -Test the passwordless connection. Use the `ssh` command to verify that you can access the same user account as you are currently logged in as (`enterprisedb`) without being prompted for a password: - -```text --bash-4.2$ ssh enterprisedb@127.0.0.1 -Last login: Thu Mar 23 10:27:50 2017 --bash-4.2$ exit -logout -Connection to 127.0.0.1 closed. -``` - -### Configuring Access from Remote Advanced Server to BART Host - -On the remote host `192.168.2.24`, create the public key file for the remote database server user account, `enterprisedb`, for access to the BART user account, `enterprisedb`, on the BART host 192.168.2.22. - -Create the `.ssh` directory for user account `enterprisedb` on the remote host: - -```text -[root@localhost 9.6AS]# pwd -/opt/PostgresPlus/9.6AS -[root@localhost 9.6AS]# mkdir .ssh -[root@localhost 9.6AS]# chown enterprisedb .ssh -[root@localhost 9.6AS]# chgrp enterprisedb .ssh -[root@localhost 9.6AS]# chmod 700 .ssh -[root@localhost 9.6AS]# ls -la | grep ssh -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 13:08 .ssh -``` - -Generate the public key file on the remote host for user account `enterprisedb`: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key -(/opt/PostgresPlus/9.6AS/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa. -Your public key has been saved in -/opt/PostgresPlus/9.6AS/.ssh/id_rsa.pub. -The key fingerprint is: -15:27:1e:1e:61:4b:48:66:67:0b:b2:be:fc:ea:ea:e6 -enterprisedb@localhost.localdomain -The key's randomart image is: -+--[ RSA 2048]---+ -| ..=.@.. | -| =.O O | -| . * | -| . . | -| . S | -| . . | -| o | -| . . | -| +Eoo.. | -+----------------+ -``` - -Copy the generated public key file, `id_rsa.pub`, to the BART user account, `enterprisedb`, on the BART host, `192.168.2.22`: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.22:/tmp/tmp.pub -The authenticity of host '192.168.2.22 (192.168.2.22)' can't be -established. -RSA key fingerprint is b8:a9:97:31:79:16:b8:2b:b0:60:5a:91:38:d7:68:22. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.22' (RSA) to the list of known hosts. -enterprisedb@192.168.2.22's password: -id_rsa.pub -``` - -Log into the BART host as the BART user account and append the temporary public key file, `/tmp/tmp.pub` onto the `authorized_keys` file owned by the BART user account. - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -enterprisedb@192.168.2.22's password: -Last login: Tue Apr 21 17:03:24 2015 from 192.168.2.22 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 12 --rw-rw-r-- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -The `authorized_keys` file must have file permission `600` as set by the following `chmod 600` command, otherwise the passwordless connection fails: - -```text --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -Test the passwordless connection. From the remote host, verify that you can log into the BART host with the BART user account without being prompted for a password: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -Last login: Thu Apr 23 13:14:48 2015 from 192.168.2.24 --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -### Configuring Access from the BART Host to a Remote Advanced Server - -On the BART host `192.168.2.22`, copy the public key file for the BART user account, `enterprisedb`, for access to the remote database server user account, `enterprisedb`, on the remote host `192.168.2.24`. - -The following lists the current SSH keys files in the BART user’s `.ssh` directory on the BART host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:15 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub -``` - -The public key file, `id_rsa.pub`, for BART user account `enterprisedb` on the BART host that was earlier generated in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account), is now copied to the remote Advanced Server host on `192.168.2.24`: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.24:/tmp/tmp.pub -The authenticity of host '192.168.2.24 (192.168.2.24)' can't be -established. -RSA key fingerprint is 59:41:fb:0c:ae:64:3d:3f:a2:d9:90:95:cf:2c:99:f2. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.24' (RSA) to the list of known -hosts. -enterprisedb@192.168.2.24's password: -id_rsa.pub -``` - -Log into the `enterprisedb` user account on the remote host and copy the public key file onto the `authorized_keys` file of the remote `enterprisedb` user account under its `.ssh` directory: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.24 -enterprisedb@192.168.2.24's password: -Last login: Tue Apr 21 09:53:18 2015 from 192.168.2.22 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ ls -l .ssh -total 12 --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:11 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:11 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:12 known_hosts --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys -``` - -Adjust the file permission on `authorized_keys`: - -```text --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 416 Apr 23 13:26 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:11 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:11 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:12 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -While logged into the BART host, test the passwordless connection from the BART host to the remote Advanced Server host: - -```text --bash-4.1$ ssh enterprisedb@192.168.2.24 -Last login: Thu Apr 23 13:25:53 2015 from 192.168.2.22 --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -### Configuring Access from a Remote PostgreSQL Server to a BART Host - -On the remote host (192.168.2.24), create a public key file owned by the database server user account (`postgres`), allowing access to the BART user account (`enterprisedb`) on the BART host (192.168.2.22). - -Create the `.ssh` directory for the `postgres` user account on the remote host: - -```text -[root@localhost 9.6]# cd /opt/PostgreSQL/9.6 -[root@localhost 9.6]# mkdir .ssh -[root@localhost 9.6]# chown postgres .ssh -[root@localhost 9.6]# chgrp postgres .ssh -[root@localhost 9.6]# chmod 700 .ssh -[root@localhost 9.6]# ls -la | grep ssh -drwx------ 2 postgres postgres 4096 Apr 23 13:32 .ssh -``` - -Create and copy the generated public key file, `id_rsa.pub`, to the BART user account (`enterprisedb`), on the BART host (`192.168.2.22`): - -```text -[user@localhost ~]$ su - postgres -Password: --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ ssh-keygen -t rsa -Generating public/private rsa key pair. -Enter file in which to save the key (/opt/PostgreSQL/9.6/.ssh/id_rsa): -Enter passphrase (empty for no passphrase): -Enter same passphrase again: -Your identification has been saved in /opt/PostgreSQL/9.6/.ssh/id_rsa. -Your public key has been saved in /opt/PostgreSQL/9.6/.ssh/id_rsa.pub. -The key fingerprint is: -1f:f8:76:d6:fc:a5:1a:c5:5a:66:66:01:d0:a0:ca:ba -postgres@localhost.localdomain -The key's randomart image is: -+--[ RSA 2048]----+ -| o+. | -| . .. | -| . . | -| . . . . . | -| o S . O | -| . o . @ | -| . + = o .| -| . . o . o.| -| E ... .| -+-----------------+ --bash-4.1$ ls -l .ssh -total 8 --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --bash-4.1$ scp ~/.ssh/id_rsa.pub enterprisedb@192.168.2.22:/tmp/tmp.pub -The authenticity of host '192.168.2.22 (192.168.2.22)' can't be -established. -RSA key fingerprint is b8:a9:97:31:79:16:b8:2b:b0:60:5a:91:38:d7:68:22. -Are you sure you want to continue connecting (yes/no)? yes -Warning: Permanently added '192.168.2.22' (RSA) to the list of known -hosts. -enterprisedb@192.168.2.22's password: -id_rsa.pub -``` - -Log into the BART host as the BART user account and append the temporary public key file, `/tmp/tmp.pub`, onto the `authorized_keys` file owned by the BART user account. - -```text --bash-4.1$ ssh enterprisedb@192.168.2.22 -enterprisedb@192.168.2.22's password: -Last login: Thu Apr 23 13:19:25 2015 from 192.168.2.24 --bash-4.1$ pwd -/opt/PostgresPlus/9.6AS --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 828 Apr 23 13:40 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:24 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -Make sure the `authorized_keys` file has file permission 600 as shown, or the passwordless connection will fail. Test the passwordless connection; from the remote host, while logged in as user account `postgres`, verify that you can log into the BART host with the BART user account without being prompted for a password: - -```text --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ ssh enterprisedb@192.168.2.22 -Last login: Thu Apr 23 13:40:10 2015 from 192.168.2.24 --bash-4.1$ exit -logout -Connection to 192.168.2.22 closed. -``` - -### Configuring Access from the BART Host to Remote PostgreSQL - -Copy the public key file on the BART host that is owned by the BART user account (`enterprisedb`) to the remote database server user account (`postgres`), on the remote host (192.168.2.24). - -The following lists the current SSH keys files in the BART user’s `.ssh` directory on the BART host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 enterprisedb enterprisedb 828 Apr 23 13:40 authorized_keys --rw------- 1 enterprisedb enterprisedb 1675 Apr 23 13:04 id_rsa --rw-r--r-- 1 enterprisedb enterprisedb 416 Apr 23 13:04 id_rsa.pub --rw-r--r-- 1 enterprisedb enterprisedb 394 Apr 23 13:24 known_hosts -``` - -The public key file, `id_rsa.pub`, for BART user account `enterprisedb` on the BART host that was earlier generated in [Generating a Public Key File for the BART User Account](#generating-a-public-key-file-for-the-bart-user-account), now resides on the remote PostgreSQL host: - -```text --bash-4.1$ scp ~/.ssh/id_rsa.pub postgres@192.168.2.24:/tmp/tmp.pub -postgres@192.168.2.24's password: -id_rsa.pub -``` - -Log into the `postgres` user account on the remote host and copy the public key file onto the `authorized_keys` file of `postgres` under its `.ssh` directory: - -```text --bash-4.1$ ssh postgres@192.168.2.24 -postgres@192.168.2.24's password: -Last login: Mon Jan 26 18:08:36 2015 from 192.168.2.19 --bash-4.1$ pwd -/opt/PostgreSQL/9.6 --bash-4.1$ cat /tmp/tmp.pub >> ~/.ssh/authorized_keys -``` - -Adjust the file permissions on `authorized_keys`: - -```text --bash-4.1$ ls -l .ssh -total 16 --rw-rw-r-- 1 postgres postgres 416 Apr 23 13:52 authorized_keys --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --rw-r--r-- 1 postgres postgres 394 Apr 23 13:36 known_hosts --bash-4.1$ chmod 600 ~/.ssh/authorized_keys --bash-4.1$ ls -l .ssh -total 16 --rw------- 1 postgres postgres 416 Apr 23 13:52 authorized_keys --rw------- 1 postgres postgres 1671 Apr 23 13:36 id_rsa --rw-r--r-- 1 postgres postgres 412 Apr 23 13:36 id_rsa.pub --rw-r--r-- 1 postgres postgres 394 Apr 23 13:36 known_hosts --bash-4.1$ rm /tmp/tmp.pub --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - -Test the passwordless connection from the BART host to the remote PostgreSQL host: - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ ssh postgres@192.168.2.24 -Last login: Thu Apr 23 13:52:25 2015 from 192.168.2.22 --bash-4.1$ exit -logout -Connection to 192.168.2.24 closed. -``` - - - -## Configuring a Replication Database User - -This section demonstrates how a replication database user is established. - -**All database servers must use a superuser as the replication database user.** - -The replication database user for each database server is specified by the `user` parameter in the BART configuration file as shown by the following: - -```text -[ACCTG] - -host = 127.0.0.1 -port = 5444 -user = enterprisedb <=== Replication Database User -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" - -[MKTG] -host = 192.168.2.24 -port = 5444 -user = repuser <=== Replication Database User -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" - -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres <=== Replication Database User -cluster_owner = enterprisedb -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -Add entries to the `.pgpass` file on each server to allow the BART user account to initiate a backup without being prompted for credentials. The `.pgpass` file is located in `/opt/PostgresPlus/9.6AS/.pgpass`: - -```text -127.0.0.1:5444:*:enterprisedb:password -192.168.2.24:5444:*:repuser:password -192.168.2.24:5432:*:postgres:password -``` - -For more information about using a `.pgpass` file, please see the [PostgreSQL documentation](https://www.postgresql.org/docs/current/libpq-pgpass.html). - -While connected to `MKTG` on 192.168.2.24, execute the following `CREATE ROLE` command to create the replication database superuser: - -```text -CREATE ROLE repuser WITH LOGIN SUPERUSER PASSWORD 'password'; -``` - -Access is granted in the `pg_hba.conf` file for the local Advanced Server: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 enterprisedb 127.0.0.1/32 md5 -host edb enterprisedb 127.0.0.1/32 md5 -#host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -#local replication enterprisedb md5 -host replication enterprisedb 127.0.0.1/32 md5 -``` - -Similarly, access is granted in the `pg_hba.conf` file for the remote Advanced Server installation: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 repuser 192.168.2.22/32 md5 -host all enterprisedb 127.0.0.1/32 md5 -#host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -# replication privilege. -#local replication enterprisedb md5 -host replication repuser 192.168.2.22/32 md5 -``` - -Access is also granted in the `pg_hba.conf` file for the remote PostgreSQL server: - -```text -# TYPE DATABASE USER ADDRESS METHOD -# "local" is for Unix domain socket connections only -local all all md5 -# IPv4 local connections: -host template1 postgres 192.168.2.22/32 md5 -host all all 127.0.0.1/32 md5 -# IPv6 local connections: -host all all ::1/128 md5 -# Allow replication connections from localhost, by a user with the -q# replication privilege. -#local replication postgres md5 -host replication postgres 192.168.2.22/32 md5 -``` - - - -## WAL Archiving Configuration Parameters - -Use the following parameters in the `postgresql.conf` file to enable WAL archiving. The `postgresql.conf` file for the local Advanced Server database (`ACCTG`) is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -#archive_command = '' # command to use to archive - a logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set based on the BART `archive_command` parameter located in the BART configuration file. - -!!! Note - If the Postgres `archive_command` is already set, invoke the `INIT` subcommand with the `-- no-configure` option to prevent the `archive_command` from being reset. For details, see [INIT](../bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init/#init). - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log - -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -backup_name = acctg_%year-%month-%dayT%hour:%minute -archive_command = 'cp %p %a/%f' -description = "Accounting" -``` - -When the `INIT` subcommand is invoked, the `postgresql.auto.conf` file contains the following: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'cp %p /opt/backup/acctg/archived_wals/%f' -``` - -The `archive_command` uses the `cp` command instead of `scp` since the BART backup catalog is local to this database cluster and the BART user account (the account that owns the backup catalog, `enterprisedb`), is the same user account running Advanced Server. The result is that there is no directory permission conflict during the archive operation. - -The `postgresql.conf` file for the remote Advanced Server, `MKTG` is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -archive_command = '' # command to use to archive a - logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set by the default BART format of the BART `archive_command` parameter (since it is not explicitly set for this database server in the BART configuration file). - -```text -[BART] -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -. -. -. -[MKTG] - -host = 192.168.2.24 -port = 5444 -user = repuser -cluster_owner = enterprisedb -backup_name = mktg_%year-%month-%dayT%hour:%minute -remote_host = enterprisedb@192.168.2.24 -description = "Marketing" -``` - -The default BART `archive_command` format is: - -```text -archive_command = 'scp %p %h:%a/%f' -``` - -The `postgresql.auto.conf` file contains the following after the `INIT` subcommand is invoked: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f' -``` - -The `archive_command` uses the `scp` command since the BART backup catalog is remote relative to this database cluster. The BART user account, `enterprisedb`, is specified on the `scp` command since this is the user account owning the BART backup catalog where the archived WAL files are to be copied. The result is that there is no directory permission conflict during the archive operation. - -The `postgresql.conf` file for the remote PostgreSQL server (`HR`) is set as follows: - -```text -wal_level = archive -archive_mode = on # allows archiving to be done - # (change requires restart) -#archive_command = '' # command to use to archive a - logfile segment - # placeholders: %p = path of - file to archive - # %f = file name only -max_wal_senders = 3 -``` - -When the `INIT` subcommand is invoked, the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file will be set by the default BART format of the BART `archive_command` parameter (since it is not explicitly set for this database server in the BART configuration file): - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -. -. -. -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -The default BART `archive_command` format is: - -```text -archive_command = 'scp %p %h:%a/%f' -``` - -The `postgresql.auto.conf` file contains the following after the `INIT` subcommand is invoked: - -```text -# Do not edit this file manually! -# It will be overwritten by ALTER SYSTEM command. -archive_command = 'scp %p -enterprisedb@192.168.2.22:/opt/backup/hr/archived_wals/%f' -``` - -The `archive_command` uses the `scp` command since the BART backup catalog is remote relative to this database cluster. The BART user account, `enterprisedb`, is specified on the `scp` command since this is the user account owning the BART backup catalog where the archived WAL files are to be copied. The result is that there is no directory permission conflict during the archive operation. - - - -## Creating the BART Backup Catalog (backup_path) - -Create the directory specified by the `backup_path` configuration parameter. - -```text -[BART] - -bart_host= enterprisedb@192.168.2.22 -backup_path = /opt/backup -pg_basebackup_path = /usr/edb/as11/bin/pg_basebackup -retention_policy = 6 BACKUPS -logfile = /tmp/bart.log -scanner_logfile = /tmp/bart_scanner.log -``` - -Ensure that the directory is owned by the BART user account: - -```text -[root@localhost opt]# pwd -/opt -[root@localhost opt]# mkdir backup -[root@localhost opt]# chown enterprisedb backup -[root@localhost opt]# chgrp enterprisedb backup -[root@localhost opt]# chmod 700 backup -[root@localhost opt]# ls -l | grep backup -drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 15:36 backup -``` - -Use the BART `INIT` subcommand to complete the directory structure and set the Postgres `archive_command` configuration parameter. - -Before invoking any BART subcommands, set up a profile under the BART user account’s home directory to set the `LD_LIBRARY_PATH` and `PATH` environment variables. For more information regarding setting this variable, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -The `-o` option is specified with the `INIT` subcommand to force the setting of the Postgres `archive_command` configuration parameter when `archive_mode` is `off` or if the Postgres `archive_command` parameter is already set and needs to be overridden. - -```text -[user@localhost ~]$ su - enterprisedb -Password: --bash-4.1$ bart INIT -o -INFO: setting archive_command for server 'acctg' -WARNING: archive_command is set. server restart is required -INFO: setting archive_command for server 'hr' -WARNING: archive_command is set. server restart is required -INFO: setting archive_command for server 'mktg' -WARNING: archive_command is set. server restart is required -``` - -The BART `SHOW-SERVERS` subcommand displays the following: - -```text --bash-4.1$ bart SHOW-SERVERS -SERVER NAME : acctg -BACKUP FRIENDLY NAME: acctg_%year-%month-%dayT%hour:%minute -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Accounting" -SERVER NAME : hr -BACKUP FRIENDLY NAME: hr_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : postgres -PORT : 5432 -REMOTE HOST : postgres@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/hr/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Human Resources" -SERVER NAME : mktg -BACKUP FRIENDLY NAME: mktg_%year-%month-%dayT%hour:%minute -HOST NAME : 192.168.2.24 -USER NAME : repuser -PORT : 5444 -REMOTE HOST : enterprisedb@192.168.2.24 -RETENTION POLICY : 6 Backups -DISK UTILIZATION : 0.00 bytes -NUMBER OF ARCHIVES : 0 -ARCHIVE PATH : /opt/backup/mktg/archived_wals -ARCHIVE COMMAND : (disabled) -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -INCREMENTAL BACKUP : DISABLED -DESCRIPTION : "Marketing" --bash-4.1$ cd /opt/backup --bash-4.1$ pwd -/opt/backup --bash-4.1$ ls -l -total 12 -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 acctg -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 hr -drwxrwxr-x 3 enterprisedb enterprisedb 4096 Mar 29 13:16 mktg --bash-4.1$ ls -l acctg -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals --bash-4.1$ ls -l hr -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals --bash-4.1$ ls -l mktg -total 4 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:16 archived_wals -``` - -The `ARCHIVE PATH` field displays the full directory path to where the WAL files are copied. This directory path must match the directory path specified in the Postgres `archive_command` parameter of the `postgresql.conf` file or the `postgresql.auto.conf` file of each database server. - - - -### Starting the Database Servers with WAL Archiving - -After the BART backup catalog directory structure has been configured, start the archiving of WAL files from the database servers by restarting each database server. - -On BART host 192.168.2.22: - -```text -[root@localhost data]# service ppas-9.6 restart -``` - -On remote host 192.168.2.24: - -```text -[root@localhost data]# service ppas-9.6 restart - -[root@localhost data]# service postgresql-9.6 restart -``` - -In the BART backup catalog, verify that the WAL files are archiving. - -Archived WAL files may not appear very frequently depending upon how often WAL archiving is set to switch to a new segment file with the `archive_timeout` parameter in your database server configuration settings. - -Verify that there are no archiving-related errors in the database server log files. - -## Taking a Full Backup - -The following code sample shows the first full backup of the database servers. - -```text --bash-4.1$ bart BACKUP -s acctg -z -INFO: creating backup for server 'acctg' -INFO: backup identifier: '1490809695281' -60776/60776 kB (100%), 1/1 tablespace - -INFO: backup completed successfully -INFO: backup checksum: 37f3defb98ca88dcf05079815555dfc2 of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809695281 -BACKUP NAME: acctg_2017-03-29T13:48 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/acctg/1490809695281 -BACKUP SIZE: 6.10 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -37f3defb98ca88dcf05079815555dfc2 base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000004 -STOP WAL LOCATION: 000000010000000000000004 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:48:15 EDT -STOP TIME: 2017-03-29 13:48:17 EDT -TOTAL DURATION: 2 sec(s) - --bash-4.1$ bart BACKUP -s mktg -z -INFO: creating backup for server 'mktg' -INFO: backup identifier: '1490809751193' -61016/61016 kB (100%), 1/1 tablespace - -INFO: backup completed successfully -INFO: backup checksum: 8b010e130a105e76d01346bb56dfcf14 of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809751193 -BACKUP NAME: mktg_2017-03-29T13:49 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/mktg/1490809751193 -BACKUP SIZE: 6.13 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -8b010e130a105e76d01346bb56dfcf14 base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000100000085 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:49:11 EDT -STOP TIME: 2017-03-29 13:49:14 EDT -TOTAL DURATION: 3 sec(s) - --bash-4.1$ bart BACKUP -s hr -z -INFO: creating backup for server 'hr' -INFO: backup identifier: '1490809824946' -38991/38991 kB (100%), 1/1 tablespace -INFO: backup completed successfully -INFO: backup checksum: 277e8a1a80ba3474f541eb316a417c9a of base.tar.gz -INFO: -BACKUP DETAILS: -BACKUP STATUS: active -BACKUP IDENTIFIER: 1490809824946 -BACKUP NAME: hr_2017-03-29T13:50 -BACKUP PARENT: none -BACKUP LOCATION: /opt/backup/hr/1490809824946 -BACKUP SIZE: 2.59 MB -BACKUP FORMAT: tar.gz -BACKUP TIMEZONE: US/Eastern -XLOG METHOD: fetch -BACKUP CHECKSUM(s): 1 -ChkSum File -277e8a1a80ba3474f541eb316a417c9a base.tar.gz - -TABLESPACE(s): 0 -START WAL LOCATION: 000000010000000000000002 -BACKUP METHOD: streamed -BACKUP FROM: primary -START TIME: 2017-03-29 13:50:25 EDT -STOP TIME: 2017-03-29 13:50:26 EDT -TOTAL DURATION: 1 sec(s) -``` - -The following code sample shows the backup directories created for each backup of each database server. The backup ID is used as the backup directory name. - -```text --bash-4.1$ cd /opt/backup --bash-4.1$ ls -l -total 12 -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:48 acctg -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:50 hr -drwxrwxr-x 4 enterprisedb enterprisedb 4096 Mar 29 13:49 mktg --bash-4.1$ ls -l acctg -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:48 1490809695281 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:48 archived_wals --bash-4.1$ ls -l hr -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:50 1490809824946 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:50 archived_wals --bash-4.1$ ls -l mktg -total 8 -drwx------ 2 enterprisedb enterprisedb 4096 Mar 29 13:49 1490809751193 -drwxrwxr-x 2 enterprisedb enterprisedb 4096 Mar 29 13:49 archived_wals -``` - - - -## Using Point-In-Time Recovery - -This section demonstrates using the point-in-time recovery operation on the remote PostgreSQL database server. - -The following tables were created about two minutes apart with WAL archiving enabled: - -```text -postgres=# \dt - - List of relations -Schema | Name | Type | Owner - ---------+----------------+---------+--------- -public | hr_rmt_t1_1356 | table | postgres -public | hr_rmt_t1_1358 | table | postgres -public | hr_rmt_t1_1400 | table | postgres -public | hr_rmt_t1_1402 | table | postgres -public | hr_rmt_t1_1404 | table | postgres -public | hr_rmt_t1_1406 | table | postgres -(6 rows) -``` - -In the table name `hr_rmt_t_, n` represents the active timeline. `` is the approximate time the table was created. For example, `hr_rmt_t1_1356` was created at approximately 1:56 PM while timeline #1 is active. - -The PostgreSQL database server was then stopped. WAL files that have been created, but not yet archived must be identified, and then saved. The following archived WAL files are in the BART backup catalog: - -```text --bash-4.1$ ls -l hr/archived_wals -total 49156 --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 13:50 -000000010000000000000001 --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 13:50 -000000010000000000000002 --rw------- 1 enterprisedb enterprisedb 302 Mar 29 13:50 -000000010000000000000002.00000028.backup --rw------- 1 enterprisedb enterprisedb 16777216 Mar 29 14:07 -000000010000000000000003 -``` - -The following sample lists the current PostgreSQL server WAL files. The unarchived WAL files are marked with two stars (\*\*). - -```text --bash-4.1$ cd /opt/PostgreSQL/9.6/data/pg_xlog --bash-4.1$ pwd -/opt/PostgreSQL/9.6/data/pg_xlog --bash-4.1$ ls -l -total 49160 --rw------- 1 postgres postgres 302 Mar 29 13:50 -000000010000000000000002.00000028.backup --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000003 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -**000000010000000000000004** --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -**000000010000000000000005** -drwx------ 2 postgres postgres 4096 Mar 29 14:07 archive_status -``` - -Copies of the unarchived WAL files are saved to a temporary location: - -```text --bash-4.1$ mkdir /tmp/unarchived_pg96_wals --bash-4.1$ pwd -/opt/PostgreSQL/9.6/data/pg_xlog -bash-4.1$ cp -p 000000010000000000000004 /tmp/unarchived_pg96_wals -bash-4.1$ cp -p 000000010000000000000005 /tmp/unarchived_pg96_wals -bash-4.1$ ls -l /tmp/unarchived_pg96_wals -total 32768 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 000000010000000000000005 -``` - -On the remote host, a directory is created to which the PostgreSQL database cluster is to be restored. This restore path is named `/opt/restore_pg96` and is owned by user account `postgres`. - -```text -[user@localhost ~]$ su root -Password: -[root@localhost user]# cd /opt -[root@localhost opt]# mkdir restore_pg96 -[root@localhost opt]# chown postgres restore_pg96 -[root@localhost opt]# chgrp postgres restore_pg96 -[root@localhost opt]# chmod 700 restore_pg96 -[root@localhost opt]# ls -l -total 16 -drwxr-xr-x 4 root daemon 4096 Mar 29 12:10 PostgresPlus -drwxr-xr-x 3 root daemon 4096 Mar 29 12:25 PostgreSQL -drwx------ 2 postgres postgres 4096 Mar 29 14:15 restore_pg96 -drwxr-xr-x. 2 root root 4096 Nov 22 2013 rh -``` - -In the BART configuration file, the remote user and remote host IP address, `postgres@192.168.2.24`, have been set with the `remote_host` parameter. If not given in the BART configuration file, this information must then be specified by the `--remote-host` option when giving the `RESTORE` subcommand (for example, `bart RESTORE --remote-host postgres@192.168.2.24 …`). - -```text -[HR] - -host = 192.168.2.24 -port = 5432 -user = postgres -cluster_owner = postgres -backup_name = hr_%year-%month-%dayT%hour:%minute -remote_host = postgres@192.168.2.24 -copy_wals_during_restore = enabled -description = "Human Resources" -``` - -Use the `SHOW-BACKUPS` subcommand to identify the backup to use with the `RESTORE` subcommand. - -```text -SERVER NAME BACKUP ID BACKUP NAME BACKUP PARENT -BACKUP TIME -BACKUP SIZE WAL(s) SIZE WAL FILES STATUS -acctg 1490809695281 acctg_2017-03-29T13:48 none -2017-03-29 13:48:17 EDT -6.10 MB 32.00 MB 2 active -hr 1490809824946 hr_2017-03-29T13:50 none -2017-03-29 13:50:26 EDT -2.59 MB 32.00 MB 2 active -mktg 1490809751193 mktg_2017-03-29T13:49 none -2017-03-29 13:49:14 EDT -6.13 MB 64.00 MB 4 active -``` - -The `-t` option with the `SHOW-BACKUPS` subcommand displays additional backup information: - -```text --bash-4.1$ bart SHOW-BACKUPS -s hr -i 1490809824946 -t -SERVER NAME : hr -BACKUP ID : 1490809824946 -BACKUP NAME : hr_2017-03-29T13:50 -BACKUP PARENT : none -BACKUP STATUS : active -BACKUP TIME : 2017-03-29 13:50:26 EDT -BACKUP SIZE : 2.59 MB -WAL(S) SIZE : 32.00 MB -NO. OF WALS : 2 -FIRST WAL FILE : 000000010000000000000002 -CREATION TIME : 2017-03-29 13:50:31 EDT -LAST WAL FILE : 000000010000000000000003 -CREATION TIME : 2017-03-29 14:07:35 EDT -``` - -A recovery is made using timeline `1` to `2017-03-29 14:01:00`. - -```text --bash-4.1$ bart RESTORE -s hr -i hr_2017-03-29T13:50 -p -/opt/restore_pg96 -t 1 -g '2017-03-29 14:01:00' -INFO: restoring backup 'hr_2017-03-29T13:50' of server 'hr' -INFO: base backup restored -INFO: copying WAL file(s) to -postgres@192.168.2.24:/opt/restore_pg96/archived_wals -INFO: writing recovery settings to postgresql.auto.conf file -INFO: archiving is disabled -INFO: permissions set on $PGDATA -INFO: restore completed successfully -``` - -The following example shows the restored backup files in the restore path directory, `/opt/restore_pg96`: - -```text --bash-4.1$ pwd -/opt/restore_pg96 --bash-4.1$ ls -l -total 128 -drwxr-xr-x 2 postgres postgres 4096 Mar 29 14:27 archived_wals --rw------- 1 postgres postgres 206 Mar 29 13:50 backup_label -drwx------ 5 postgres postgres 4096 Mar 29 12:25 base -drwx------ 2 postgres postgres 4096 Mar 29 14:27 global -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_clog -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_commit_ts -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_dynshmem --rw------- 1 postgres postgres 4212 Mar 29 13:18 pg_hba.conf --rw------- 1 postgres postgres 1636 Mar 29 12:25 pg_ident.conf -drwxr-xr-x 2 postgres postgres 4096 Mar 29 13:45 pg_log -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_logical -drwx------ 4 postgres postgres 4096 Mar 29 12:25 pg_multixact -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_notify -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_replslot -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_serial -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_snapshots -drwx------ 2 postgres postgres 4096 Mar 29 13:43 pg_stat -drwx------ 2 postgres postgres 4096 Mar 29 13:50 pg_stat_tmp -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_subtrans -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_tblspc -drwx------ 2 postgres postgres 4096 Mar 29 12:25 pg_twophase --rw------- 1 postgres postgres 4 Mar 29 12:25 PG_VERSION -drwx------ 3 postgres postgres 4096 Mar 29 14:27 pg_xlog --rw------- 1 postgres postgres 169 Mar 29 13:24 postgresql.auto.conf --rw-r--r-- 1 postgres postgres 21458 Mar 29 14:27 postgresql.conf --rw-r--r-- 1 postgres postgres 118 Mar 29 14:27 postgresql.auto.conf -``` - -Copy the saved, unarchived WAL files to the restore path `pg_xlog` subdirectory (`/opt/restore_pg96/pg_xlog`): - -```text --bash-4.1$ pwd -/opt/restore_pg96/pg_xlog --bash-4.1$ ls -l -total 16388 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000002 -drwx------ 2 postgres postgres 4096 Mar 29 14:27 archive_status --bash-4.1$ ls -l /tmp/unarchived_pg96_wals -total 32768 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000005 --bash-4.1$ cp -p /tmp/unarchived_pg96_wals/* . --bash-4.1$ ls -l -total 49156 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000002 --rw------- 1 postgres postgres 16777216 Mar 29 14:07 -000000010000000000000004 --rw------- 1 postgres postgres 16777216 Mar 29 13:50 -000000010000000000000005 -drwx------ 2 postgres postgres 4096 Mar 29 14:27 archive_status -``` - -Inspect the `/opt/restore_pg96/postgresql.auto.conf` file to verify that it contains the correct recovery settings: - -```text -restore_command = 'cp archived_wals/%f %p' -recovery_target_time = '2017-03-29 14:01:00' -recovery_target_timeline = 1 -``` - -Note that the command restores from the `archived_wals` subdirectory of `/opt/restore_pg96` since the `copy_wals_during_restore` parameter in the BART configuration file is set to `enabled` for database server `hr`. - -Start the database server to initiate the point-in-time recovery operation: - -```text -[user@localhost ~]$ su postgres -Password: -bash-4.1$ cd /opt/restore_pg96 -bash-4.1$ /opt/PostgreSQL/9.6/bin/pg_ctl start -D /opt/restore_pg96 -l -/opt/restore_pg96/pg_log/logfile -server starting -``` - -Inspect the database server log file to ensure the operation did not result in any errors: - -```text -2017-03-29 14:33:23 EDT LOG: database system was interrupted; last known -up at 2017-03-29 13:50:25 EDT -2017-03-29 14:33:23 EDT LOG: starting point-in-time recovery to -2017-03-29 14:01:00-04 -2017-03-29 14:33:23 EDT LOG: restored log file -"000000010000000000000002" from archive -2017-03-29 14:33:23 EDT LOG: redo starts at 0/2000098 -2017-03-29 14:33:23 EDT LOG: consistent recovery state reached at -0/20000C0 -2017-03-29 14:33:23 EDT LOG: restored log file -"000000010000000000000003" from archive -2017-03-29 14:33:23 EDT LOG: recovery stopping before commit of -transaction 1762, time 2017-03-29 14:02:28.100072-04 -2017-03-29 14:33:23 EDT LOG: redo done at 0/303F390 -2017-03-29 14:33:23 EDT LOG: last completed transaction was at log time -2017-03-29 14:00:43.351333-04 -cp: cannot stat `archived_wals/00000002.history': No such file or -directory -2017-03-29 14:33:23 EDT LOG: selected new timeline ID: 2 -cp: cannot stat `archived_wals/00000001.history': No such file or -directory -2017-03-29 14:33:23 EDT LOG: archive recovery complete -2017-03-29 14:33:23 EDT LOG: MultiXact member wraparound protections are -now enabled -2017-03-29 14:33:23 EDT LOG: database system is ready to accept -connections -2017-03-29 14:33:23 EDT LOG: autovacuum launcher started -``` - -The tables that exist in the recovered database cluster are: - -```text -postgres=# \dt - List of relations -Schema | Name | Type | Owner ---------+----------------+-------+---------- -public | hr_rmt_t1_1356 | table | postgres -public | hr_rmt_t1_1358 | table | postgres -public | hr_rmt_t1_1400 | table | postgres -(3 rows) -``` - -Since recovery was up to and including 2017-03-29 14:01:00, the following tables created after 14:01 are not present: - -```text -public | hr_rmt_t1_1402 | table | postgres -public | hr_rmt_t1_1404 | table | postgres -public | hr_rmt_t1_1406 | table | postgres -``` - -The BART `RESTORE` operation stops WAL archiving by adding an `archive_mode = off` parameter at the very end of the `postgresql.conf` file. This last parameter in the file overrides any other previous setting of the same parameter in the file. Delete the last setting and restart the database server to start WAL archiving. - -```text -# Add settings for extensions here -archive_mode = off -``` diff --git a/product_docs/docs/bart/2.6.2/bart_ref/images/EDB_logo.png b/product_docs/docs/bart/2.6.2/bart_ref/images/EDB_logo.png deleted file mode 100755 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.2/bart_ref/images/edb.png b/product_docs/docs/bart/2.6.2/bart_ref/images/edb.png deleted file mode 100755 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.2/bart_ref/images/edb_logo.svg b/product_docs/docs/bart/2.6.2/bart_ref/images/edb_logo.svg deleted file mode 100755 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.2/bart_ref/images/image2.png b/product_docs/docs/bart/2.6.2/bart_ref/images/image2.png deleted file mode 100755 index edc64a0ff46..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/images/image2.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:50824c247a9be22f3c0e10a02d4ed308dce6ce9a86adfd87bb439a00d8c121c1 -size 92905 diff --git a/product_docs/docs/bart/2.6.2/bart_ref/index.mdx b/product_docs/docs/bart/2.6.2/bart_ref/index.mdx deleted file mode 100644 index 6a8817bd039..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_ref/index.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -navTitle: Reference Guide -title: "EDB Postgres Backup and Recovery Reference Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/index.html" ---- - -This guide acts as a quick reference for BART subcommands and provides comprehensive examples of the following BART operations: - -- Performing a full backup of database servers -- Performing a point-in-time recovery (PITR) on a remote PostgreSQL database server -- Restoring an incremental backup -- Restoring a database cluster with tablespaces -- Evaluating, marking, and deleting backups and incremental backups -- Configuring and operating local and remote database servers - -For detailed information about BART subcommands and operations, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). - -The document is organized as follows: - -- See [Subcommands](01_bart_subcommands_examples/#using_bart_subcommands) to view BART subcommand examples. -- See [Examples](02_additional_examples/#examples) to view BART operations examples. -- See [Sample BART System](03_sample_bart_system_with_local_and_remote_database_servers/#a_sample_bart_system_with_local_and_remote_database_servers) to view examples of both local and remote database server configuration and operation. - -
- -bart_subcommands_examples additional_examples sample_bart_system_with_local_and_remote_database_servers conclusion - -
diff --git a/product_docs/docs/bart/2.6.2/bart_user/01_introduction.mdx b/product_docs/docs/bart/2.6.2/bart_user/01_introduction.mdx deleted file mode 100644 index 1212b2847bf..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/01_introduction.mdx +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Introduction" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" ---- - -The EDB Backup and Recovery Tool (BART) is an administrative utility that provides simplified backup and recovery management for multiple local or remote EDB Advanced Server and PostgreSQL database servers. - -BART provides the following features: - -- Support for complete, hot, physical backups of multiple Advanced Servers and PostgreSQL database servers -- Support for two types of backups – full base backups and block-level incremental backups -- Backup and recovery management of database servers on local or remote hosts -- A single, centralized catalog for backup data -- Retention policy support for defining and managing how long backups should be kept -- The capability to store the backup data in compressed format -- Verified backup data with checksums -- Backup information displayed in an easy-to-read format -- A simplified point-in-time recovery process - -This guide provides the following information about using BART: - -- an [overview](02_overview/#overview) of the BART components and concepts. -- [backup and recovery management process](03_using_bart/#using_bart). -- [using tablespaces](04_using_tablespaces/#using_tablespaces). - -For information about installing BART, see the *EDB Backup and Recovery Installation and Upgrade Guide*; for examples of BART operations and subcommand usage, see the *EDB Backup and Recovery Reference Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). - - - -## Conventions Used in this Guide - -The following is a list of conventions used throughout this document. - -- Much of the information in this document applies interchangeably to the PostgreSQL and EDB Advanced Server database systems. The term *Advanced Server* is used to refer to EDB Advanced Server. The term *Postgres* is used to generically refer to both PostgreSQL and Advanced Server. When a distinction needs to be made between these two database systems, the specific names, PostgreSQL or Advanced Server are used. - -- The installation directory of the PostgreSQL or Advanced Server products is referred to as `POSTGRES_INSTALL_HOME`: - - - For PostgreSQL Linux installations, this defaults to `/opt/PostgreSQL/` for version 10 and earlier. For later versions, the installation directory is `/var/lib/pgsql/`. - - For Advanced Server Linux installations performed using the interactive installer for version 10 and earlier, this defaults to `/opt/PostgresPlus/AS` or `/opt/edb/as`. For Advanced Server Linux installations performed with an RPM package, this defaults to `/usr/ppas-` or `/usr/edb/as`. For Advanced Server Linux installations performed with an RPM package for version 11 or later, this defaults to `/usr/edb/as`. - -## Restrictions on pg_basebackup - -BART takes full backups using the `pg_basebackup` utility program under the following conditions: - -- The backup is taken on a standby server. -- The `--with-pg_basebackup` option is specified with the `BACKUP` subcommand (see [Backup](03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup)). -- The number of thread count in effect is 1, and the `with-pg_basebackup` option is not specified with the `BACKUP` subcommand. -- Database servers can only be backed up using `pg_basebackup` utility program of the same or later version than the database server version. - -In the global section of the BART configuration file, the `pg_basebackup_path` parameter specifies the complete directory path to the `pg_basebackup` program. For information about the `pg_basebackup_path` parameter and the `thread_count`, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - -For information about `pg_basebackup`, see the [PostgreSQL Core Documentation](https://postgresql.org/docs/current/static/app-pgbasebackup.html). diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx deleted file mode 100644 index a3fe8894d09..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Incremental Backup Limitations and Requirements" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/incremental_backup_limitations_and_requirements.html" ---- - - - -The following limitations apply to incremental backup: - -- If you have restored a full or incremental backup, you must take a full backup before enabling incremental backup. -- If a standby node has been promoted to the role of a primary node, you must take a full backup before enabling incremental backup on the cluster. -- On a standby database server, you cannot take an incremental backup. - -You must meet the following requirements before implementing incremental backup: - -- You must create or select an operating system account to be used as the BART user account. - -- You must create or select the replication database user, which must be a superuser. - -- In the BART configuration file: - - - You must set the `cluster_owner` parameter to the Linux operating system user account that owns the database cluster directory from which incremental backups are to be taken. - - You must enable the `allow_incremental_backups` parameter. - -- A passwordless SSH/SCP connection must be established between the BART user account on the BART host and the `cluster_owner` user account on the database server. - - It must be noted that a passwordless SSH/SCP connection must be established even if BART and the database server are running on the same host and the BART user account and the `cluster_owner` user account are the same account. - -- In addition to the BART host (where the BART backup catalog resides), the BART package must also be installed on every remote database server on which incremental backups are to be restored. To restore an incremental backup, the `bart` program must be executable on the remote host by the remote user (the remote user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup). - -- When [restoring incremental backups on a remote database server](05_restoring_an_incremental_backup/#restoring-an-incremental-backup-on-a-remote-host), a passwordless SSH/SCP connection must be established from the BART user account on the BART host to the remote user on the remote host (the remote user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup). - -- Compression of archived WAL files in the BART backup catalog is not permitted for database servers on which incremental backups are to be taken. The `wal_compression` setting in the BART configuration file must be disabled for those database servers. - -- The incremental backup must be on the same timeline as the parent backup. The timeline changes after each recovery operation so an incremental backup cannot use a parent backup from an earlier timeline. - -For information about configuring these requirements, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -The following section provides an overview of the basic incremental backup concepts. diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx deleted file mode 100644 index 8183d4802bd..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Concept Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/concept_overview.html" ---- - - - -Using incremental backups involves the following sequence of steps: - -1. Configure BART, and enable and initiate archiving of WAL files to the `archive_path` in the same manner as done for full backups. - - The default `archive_path` is the BART backup catalog (`//archived_wals`). Using the `` parameter in the server section of the BART configuration file, you can specify the location where WAL files will be archived. - - For more information about the `archive_path` parameter and configuring BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -2. Take an initial full backup with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. - -3. Scan all WAL files produced by database servers on which incremental backups are to be taken. These WAL files are scanned once they have been archived to the `archive_path`. - - Each scanned WAL file results in a modified block map (MBM) file that records the location of modified blocks obtained from the corresponding WAL file. The BART WAL scanner program `bart-scanner` performs this process. - -4. Take incremental backups using the `BACKUP` subcommand with the `--parent` option to specify the backup identifier or name of a previous, full backup or an incremental backup. Any previous backup may be chosen as the parent as long as all backups belong to the same timeline. - -5. The incremental backup process identifies which WAL files may contain changes from when the parent backup was taken to the starting point of the incremental backup. The corresponding MBM files are used to locate and copy the modified blocks to the incremental backup directory along with other database cluster directories and files. Instead of backing up all, full relation files, only the modified blocks are copied and saved. In addition, the relevant MBM files are condensed into one consolidated block map (CBM) file that is stored with the incremental backup. - - Multiple block copier threads can be used to copy the modified blocks to the incremental backup directory. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting the `thread_count` parameter in the BART configuration file. See [Backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for information about using the `--thread-count` option with the `BACKUP` subcommand. - -6. Invoke the restore process for an incremental backup using the `RESTORE` subcommand in the same manner as restoring a full backup. The `-i` option specifies the backup identifier or name of the incremental backup to restore. The restore process begins by going back through the chain of past, parent incremental backups until the initial full backup starting the chain is identified. This full backup provides the initial set of directories and files to be restored to the location specified with the `-p` option. Each subsequent incremental backup in the chain is then restored. Restoration of an incremental backup uses its CBM file to restore the modified blocks from the incremental backup. - -The following sections provide some additional information on these procedures. diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx deleted file mode 100644 index 5264499e13e..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "WAL Scanning – Preparation for an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/wal_scanning_preparation_for_an_incremental_backup.html" ---- - - - -The WAL scanner program (`bart-scanner`) scans the WAL files created from the time of the parent backup up to the start of the incremental backup to determine which blocks have modified since the parent backup, and records the information in a file called the *modified block map (MBM) file*. One MBM file is created for each WAL file. - -The MBM file is stored in the directory where archived_wals will be stored, as specified in the `archive_path` parameter in the `bart.cfg` file. If the `archive_path` is not specified, the default `archived_wals` directory is: - -`//` - -Where: - -`` is the BART backup catalog parent directory specified in the global section of the BART configuration file. - -`` is the lowercase conversion of the database server name specified in the server section of the BART configuration file. - -The following code snippet is the content of the archive path showing the MBM files created for the WAL files. (The user name and group name of the files have been removed from the example to list the WAL files and MBM files in a more comparable manner): - -```text -[root@localhost archived_wals]# pwd -/opt/backup/acctg/archived_wals -[root@localhost archived_wals]# ls -l -total 131104 --rw------- 1 ... ... 16777216 Oct 12 09:38 000000010000000100000078 --rw------- 1 ... ... 16777216 Oct 12 09:38 000000010000000100000079 --rw------- 1 ... ... 16777216 Oct 12 09:38 00000001000000010000007A --rw------- 1 ... ... 16777216 Oct 12 09:35 00000001000000010000007B --rw------- 1 ... ... 16777216 Oct 12 09:38 00000001000000010000007C --rw------- 1 ... ... 16777216 Oct 12 09:39 00000001000000010000007D --rw------- 1 ... ... 16777216 Oct 12 09:42 00000001000000010000007E --rw------- 1 ... ... 16777216 Oct 12 09:47 00000001000000010000007F --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 0000000100000001780000280000000179000000.mbm --rw-rw-r-- 1 ... ... 684 Oct 12 09:49 000000010000000179000028000000017A000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017A000028000000017B000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017B000028000000017C000000.mbm --rw-rw-r-- 1 ... ...1524 Oct 12 09:49 00000001000000017C000028000000017D000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017D000028000000017E000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017E000028000000017F000000.mbm --rw-rw-r-- 1 ... ... 161 Oct 12 09:49 00000001000000017F0000280000000180000000.mbm -``` - -MBM files have the suffix, `.mbm`. - -In preparation for any incremental backup, the WAL files should be scanned as soon as they are copied to the `archive_path`. Thus, the WAL scanner should be running as soon as the WAL files from the database cluster are archived to the `archive_path`. If the `archive_path` contains WAL files that have not yet been scanned, starting the WAL scanner begins scanning these files. If WAL file fails to be scanned (resulting in a missing MBM file), you can use the WAL scanner to specify an individual WAL file. - -Under certain conditions such as when the Network File System (NFS) is used to copy WAL files to the `archive_path`, the WAL files may have been missed by the WAL scanner program for scanning and creation of MBM files. Use the `scan_interval` parameter in the BART configuration file to initiate force scanning of WAL files in the `archive_path` to ensure MBM files are generated. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about the `scan_interval` parameter. - -See [Running the BART WAL Scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) for information about using the WAL scanner. diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx deleted file mode 100644 index 8198f0f6400..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: "Performing an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_an_incremental_backup.html" ---- - - - -The WAL files produced at the time of the parent backup up to the start of the incremental backup contain information about which blocks were modified during that time interval. That information is consolidated into an MBM file for each WAL file by the WAL scanner. - -The MBM files for the relevant WAL files are read, and the information is used to copy the modified blocks from the database cluster to the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file. When compared to a full backup, the number and sizes of relation files can be significantly less for an incremental backup. - -For comparison, the following is an abbreviated list of the files copied to the archived `base` subdirectory of a full backup for one database: - -```text -[root@localhost 14845]# pwd -/opt/backup/acctg/1476301238969/base/base/14845 -[root@localhost 14845]# ls -112 13182_vm 14740 16467 16615 2608_vm 2655 2699 2995 ... -113 13184 14742 16471 174 2609 2656 2701 2995_vm ... -1247 13186 14745 16473 175 2609_fsm 2657 2702 2996 ... -1247_fsm 13187 14747 16474 2187 2609_vm 2658 2703 2998 ... -1247_vm 13187_fsm 14748 16476 2328 2610 2659 2704 2998_vm ... -1249 13187_vm 14749 16477 2328_fsm 2610_fsm 2660 2753 2999 ... -1249_fsm 13189 14752 16479 2328_vm 2610_vm 2661 2753_fsm 2999_vm ... -1249_vm 13191 14754 16488 2336 2611 2662 2753_vm 3079 ... -1255 13192 14755 16490 2336_vm 2611_vm 2663 2754 3079_fsm ... - . - . - . -13182_fsm 14739 16465 16603 2608_fsm 2654 2696 2893_vm 3501_vm ... -``` - -In contrast, the following is the content of the archived `base` subdirectory of the same database from a subsequent incremental backup: - -```text -[root@localhost 14845]# pwd -/opt/backup/acctg/1476301835391/base/base/14845 -[root@localhost 14845]# ls -1247 1249 1259 16384 17006 2608 2610 2658 2663 2678 ... -1247_fsm 1249_fsm 1259_fsm 16387 17009 2608_fsm 2610_fsm 2659 2673 2679 ... -1247_vm 1249_vm 1259_vm 16389 17011 2608_vm 2610_vm 2662 2674 2703 ... -``` - -The information from the MBM files are consolidated into one file called a *consolidated block map* (CBM) file. During the restore operation for the incremental backup, the CBM file is used to identify the modified blocks to be restored for that backup. In addition, the incremental backup also stores other required subdirectories and files from the database cluster as is done for full backups. - -Before taking an incremental backup, an initial full backup must be taken with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. - -The syntax for taking a full backup is: - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - [ -z ] [ –c ] - [ --backup-name ] - [ --thread-count ] - [ { --with-pg_basebackup | --no-pg_basebackup } ] - [--checksum-algorithm ] -``` - -The syntax for taking an incremental backup is: - -```text -bart BACKUP –s { | all } [ -F p] - [ --parent { | } ] - [ --backup-name ] - [ --thread-count ] - [ --check ] - [--checksum-algorithm ] -``` - -You must specify the following before taking an incremental backup: - -- `-Fp` option for plain text format as incremental backup can only be taken in the plain text format. -- `--check` option to verify if the required MBM files are present in the `archived_wals` directory. The `--parent` option must be specified when the `--check` option is used. - -See [BACKUP](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for more information about using the `BACKUP` subcommand. diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx deleted file mode 100644 index b3dcf583e31..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Restoring an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restoring_an_incremental_backup.html" ---- - - - -Restoring an incremental backup may require additional steps depending upon the host on which the incremental backup is to be restored: - -- [Restoring an Incremental Backup on a BART Host](#restoring-an-incremental-backup-on-a-bart-host) - This section outlines restoring an incremental backup onto the same host where BART has been installed. -- [Restoring an Incremental Backup on a Remote Host](#restoring-an-incremental-backup-on-a-remote-host) - This section outlines restoring an incremental backup onto a remote host where BART has not been installed. - - - -## Restoring an Incremental Backup on a BART Host - -Specify a backup identifier or name, and include the `-i` option when invoking the `RESTORE` subcommand to restore an incremental backup. All `RESTORE` options may be used in the same manner as when restoring a full backup. See [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) command for more details. - -First, all files from the full backup from the beginning of the backup chain are restored. For each incremental backup, the CBM file is used to identify and restore blocks from the incremental backup. If there are new relations or databases identified in the CBM file, then relevant relation files are copied. If consolidated block map information is found indicating the drop of a relation or a database, then the relevant files are removed from the restore directory. Similarly, if there is any indication of a table truncation, then the related files are truncated. - -Also note that you can use the `-w` option of the `RESTORE` subcommand to specify a multiple number of parallel worker processes to stream the modified blocks to the restore host. - -!!! Note - If you set the [BART scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or [backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) with the `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring an incremental backup. - - - -## Restoring an Incremental Backup on a Remote Host - -Ensure the `bart` program is available on the remote host when restoring an incremental backup on a remote host; the invocation of the `RESTORE` subcommand for an incremental backup results in the execution of the `bart` program on the remote host to restore the modified blocks to their proper location. - -To restore an incremental backup onto a remote host where BART has not been installed, perform the following steps: - -**Step 1:** Install `BART` on the remote host to which an incremental backup is to be restored. - -No editing is needed in the `bart.cfg` file installed on the remote host. - -**Step 2:** Determine the Linux operating system user account on the remote host to be used as the remote user. This user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup. The remote user must be the owner of the directory where the incremental backup is to be restored on the remote host. By default, the user account is `enterprisedb` for Advanced Server or `postgres` for PostgreSQL. - -**Step 3:** Ensure a passwordless SSH/SCP connection is established from the BART user on the BART host to the remote user on the remote host. For information about creating a passwordless SSH/SCP connection, see the *EDB Backup and Recovery Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - -When restoring an incremental backup, specify the backup identifier or name of the incremental backup that will be restored. See the [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) documentation for more details. To view an example of restoring an incremental backup, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -!!! Note - If you set the [BART scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or [backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) with the `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring an incremental backup. diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/index.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/index.mdx deleted file mode 100644 index 3e65e3b0056..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/01_block-level_incremental_backup/index.mdx +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Block-Level Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/block-level_incremental_backup.html" ---- - - - -This section describes the basic concepts of a block-level incremental backup (referred to as an incremental backup). An incremental backup is a unique functionality of BART. - -An incremental backup provides a number of advantages when compared to using a full backup: - -- The amount of time required to produce an incremental backup is generally less than a full backup, as modified relation blocks are saved instead of all full relation files of the database cluster. -- An incremental backup uses less disk space than a full backup. - -Generally, all BART features (such as retention policy management) apply to incremental backups and full backups. See [Managing Incremental Backups](../../03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups/#managing_incremental_backups) for more information. - -
- -incremental_backup_limitations_and_requirements concept_overview wal_scanning_preparation_for_an_incremental_backup performing_an_incremental_backup restoring_an_incremental_backup - -
diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/02_creating_a_backup_chain.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/02_creating_a_backup_chain.mdx deleted file mode 100644 index 644040d87f1..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/02_creating_a_backup_chain.mdx +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Creating a Backup Chain" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/creating_a_backup_chain.html" ---- - - - -A *backup chain* is the set of backups consisting of a full backup and all of its successive incremental backups. Tracing back on the parent backups of all incremental backups in the chain eventually leads back to that single, full backup. - -It is possible to have a *multi-forked* backup chain, which is two or more successive lines of incremental backups, all of which begin with the same, full backup. Thus, within the chain there is a backup that serves as the parent of more than one incremental backup. - -Since restoration of an incremental backup is dependent upon first restoring the full backup, then all successive incremental backups up to, and including the incremental backup specified by the `RESTORE` subcommand, it is crucial to note the following: - -- Deletion or corruption of the full backup destroys the entire backup chain. It is not possible to restore any of the incremental backups that were part of that chain. -- Deletion or corruption of an incremental backup within the chain results in the inability to restore any incremental backup that was added to that successive line of backups following the deleted or corrupted backup. The full backup and incremental backups prior to the deleted or corrupted backup can still be restored. - -The actions of retention policy management are applied to the full backup and all of its successive incremental backups within the chain in an identical manner as if they were one backup. Thus, use of retention policy management does not result in the breakup of a backup chain. - -See the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/) for examples of creating a backup chain and restoring an incremental backup. diff --git a/product_docs/docs/bart/2.6.2/bart_user/02_overview/index.mdx b/product_docs/docs/bart/2.6.2/bart_user/02_overview/index.mdx deleted file mode 100644 index 7b5b7e92fb3..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/02_overview/index.mdx +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: "Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview.html" ---- - - - -BART provides a simplified interface for the continuous archiving and point-in-time recovery method provided with Postgres database servers. This consists of the following processes: - -- Capturing a complete image of a database cluster as a full base backup or referred to simply as a *full backup*. -- Capturing a modified image of a database cluster called a *block-level incremental backup* or referred as *incremental backup*, which is similar to a full backup, but contains the modified blocks of the relation files that have been changed since a previous backup. -- Archiving the `Write-Ahead Log segments` (WAL files), which continuously record changes to be made to the database files. -- Performing *Point-In-Time Recovery* (PITR) to a specified transaction ID or timestamp with respect to a timeline using a full backup along with successive, [block-level incremental backups](01_block-level_incremental_backup/#block-level_incremental_backup) that reside in the same backup chain, and the WAL files. - -Detailed information regarding WAL files and point-in-time recovery is documented in the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/continuous-archiving.html). - -The general term *backup* refers to both full backups and incremental backups. - -When taking a full backup of a standby server, BART uses the PostgreSQL `pg_basebackup` utility program. However, it must be noted that for standby servers, you can only take a full backup, but cannot take an incremental or parallel backups. For information about standby servers, see the [PostgreSQL Documentation](https://www.postgresql.org/docs/current/static/high-availability.html). - -BART uses a centralized backup catalog, a single configuration file, and a command line interface controlling the necessary operations to simplify the management process. Reasonable defaults are automatically used for various backup and restore options. BART also performs the necessary recovery file configuration required for point-in-time recovery using its command line interface. - -BART also provides the following features to enhance backup management: - -- Automation of the WAL archiving command configuration. -- Usage of retention policies to evaluate, categorize, and delete obsolete backups. -- Compression of WAL files to conserve disk space. -- Customizable naming of backups to ease their usage. -- Easy access to comprehensive information about each backup. - -The key components of a BART installation are: - -- **BART Host.** The host system on which BART is installed. BART operations are invoked from this host system. The database server backups and archived WAL files are stored on this host as well. -- **BART User Account.** Linux operating system user account you choose to run BART. The BART user account owns the BART backup catalog directory. -- **BART Configuration File.** File in editable text format containing the configuration information that BART uses. -- **BART Backup Catalog.** File system directory structure containing all of the backups for the database servers that BART manages. It is also the default `archive_path` to store archived WAL files. -- **BART Backupinfo File.** File in text format containing information for a BART backup. A `backupinfo` file resides in each backup subdirectory within the BART backup catalog. -- **BART Command Line Utility Program.** Single, executable file named `bart`, which is used to manage all BART operations. -- **BART WAL Scanner Program.** Single, executable file named `bart-scanner`, which is used to scan WAL files to locate and record the modified blocks for incremental backups. - -Other concepts and terms referred to in this document include the following: - -- **Postgres Database Cluster.** Also commonly called the *data directory*, this is the file system directory where all of the data files related to a particular Postgres database server instance are stored. (Each specific running instance is identified by its host and port number when connecting to a database.) The database cluster is identified by the `–D` option when it is created, started, stopped, etc. by the `Postgres initdb` and `pg_ctl` commands. A full backup is a copy of a database cluster. - - The terms database cluster and database server are used somewhat interchangeably throughout this document, though a single database server can run multiple database clusters. - -- **Postgres User Account.** Linux operating system user account that runs the Advanced Server or PostgreSQL database server and owns the database cluster directory. - - - By default, the database user account is `enterprisedb` when Advanced Server is installed to support compatibility with Oracle databases. - - - By default, the database user account is `postgres` when Advanced Server is installed in PostgreSQL compatible mode. For a PostgreSQL database server, the default database user account is also `postgres`. - - The BART configuration parameter `cluster_owner` must be set to the database user account for each database server. - -- **Replication Database User.** For each database server that BART manages, a database superuser must be selected to act as the replication database user. This database user is used to connect to the database server when backups are taken. The database superusers created with an initial Postgres database server installation (`enterprisedb` or `postgres`) may be used for this purpose. The BART configuration parameter `user` must be set to this replication database user for each database server. - -- **Secure Shell (SSH)/Secure Copy (SCP).** Linux utility programs used to log into hosts (SSH) and copy files (SCP) between hosts. A valid user account must be specified that exists on the target host and in fact is the user account under which the SSH or SCP operations occur. - -For information on how all of these components are configured and used with BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -**Supported BART Operations** - -The following tables are not a conclusive list of the scenarios supported by BART, but instead provides an overview of some of the most common scenarios in both `pg_basebackup` (thread count=1) as well as parallel backup mode (thread count greater than 1). - -| | -Fp-xlog-method=fetch | -Fp-xlog-method=stream | -Ft-xlog-method=fetch | -Ft-xlog-method=stream | -| -------------------------------------------- | --------------------- | ---------------------- | --------------------- | ---------------------- | -| `Primary Database Server/Full backup` | Supported | Supported | Supported | Supported | -| `Primary Database Server/Incremental backup` | Supported | Supported | Not Supported | Not Supported | -| `Standby Database Server/Full backup` | Supported | Supported | Supported | Supported | -| `Standby Database Server/Incremental backup` | Not Supported | Not Supported | Not Supported | Not Supported | - -Backup - -| | Wal compression by BART | WAL scanner | -| -------------------------------------------- | ----------------------- | ----------- | -| `Primary Database Server/Full backup` | Supported | N/A | -| `Primary Database Server/Incremental backup` | Not Supported | N/A | -| `Standby Database Server/Full backup` | Supported | N/A | -| `Standby Database Server/Incremental backup` | Not Supported | N/A | - -Wal Archiving - -| | Wal compression = enabled | Wal compression = disabled | -| ------------------ | ------------------------- | -------------------------- | -| `Restore` | Supported | Supported | -| `Parallel restore` | Supported | Supported | - -Restore - -
- -block-level_incremental_backup creating_a_backup_chain - -
diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx deleted file mode 100644 index 06edb0b5afb..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Performing a Restore Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_a_restore_operation.html" ---- - - - -The following steps describe the process of restoring a backup: - -**Step 1:** Use your system-specific command to shut down the database server. - -**Step 2:** Inspect the `pg_wal` subdirectory (inspect the `pg_xlog` subdirectory if you are using server 9.6 version) of the data directory and save any WAL files that have not yet been archived to the `archive_path`. If there are files that have not been archived, save them to a temporary location. - -**Step 3:** If you want to restore to current data directory, it is recommended to make a copy of the current data directory and then delete all files and subdirectories under the data directory if you have enough extra space. If there is not enough space, then make a copy of `pg_wal` directory (or `pg_xlog` if you are using server 9.6 version) until the server is successfully restored. - -If you want to restore to a new, empty directory, create the directory on which you want to restore the backed up database cluster. Ensure the data directory can be written to by the BART user account or by the user account specified by the `remote_host` configuration parameter, or by the `--remote-host` option of the `RESTORE` subcommand (if these are to be used). - -**Step 4:** Perform the same process for tablespaces as described in Step 3. The `tablespace_path` parameter in the BART configuration file must contain the tablespace directory paths to which the tablespace data files are to be restored. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about this parameter. - -**Step 5:** Identify the backup to use for the restore operation and obtain the backup ID or backup name. - -To use the latest backup, omit the `-i` option; the `RESTORE` subcommand uses that backup by default. The backups can be listed with the `SHOW-BACKUPS` subcommand. - -**Step 6:** Run the BART `RESTORE` subcommand. - -- Minimal recovery settings will be saved in the `postgresql.auto.conf` file and archive recovery will proceed only until consistency is reached, with no restoration of files from the archive. See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for detailed information about `Restore` subcommand. - -- If the `-c` option is specified or if the `copy_wals_during_restore` BART configuration parameter is enabled for this database server, then the following actions occur: - - - In addition to restoring the database cluster to the directory specified by the `-p restore_path` option, the archived WAL files of the backup are copied from the BART backup catalog to the subdirectory `restore_path/archived_wals`. - - If recovery settings are saved in the `postgresql.auto.conf` file, the command string set in the `restore_command` parameter retrieves the WAL files from this `archived_wals` subdirectory relative to the `restore_path` parent directory as: `restore_command = cp archived_wals/%f %p` - -You must ensure that valid options are specified when using the `RESTORE` subcommand. BART will not generate an error message if invalid option values or invalid option combinations are provided. BART will accept the invalid options and pass them to the `postgresql.auto.conf` file, which will then be processed by the database server when it is restarted. - -**Step 7:** Copy any saved WAL files from Step 2 to the `restore_path/pg_xlog` subdirectory. - -**Step 8:** Inspect the restored directories and data files of the restored database cluster in directory `restore_path`. - -All files and directories must be owned by the user account that you intend to use to start the database server. Recursively change the user and group ownership of the `restore_path` directory, its files, and its subdirectories if necessary. There must only be directory access privileges for the user account that will start the database server. No other groups or users can have access to the directory. - -**Step 9:** The `postgresql.auto.conf` file should be configured to recover only until the cluster reaches consistency. In either case, the settings may be modified as desired. - -**Step 10:** Disable WAL archiving at this point. The BART `RESTORE` subcommand adds `archive_mode = off` to the end of the `postgresql.conf` file. - -- If you want to restart the database server with WAL archiving enabled, ensure that this additional parameter is deleted. -- The original `archive_mode` parameter still resides in the `postgresql.conf` file in its initial location with its last setting. - -**Step 11:** Start the database server to initiate recovery. After completion, check the database server log file to ensure the recovery was successful. - -If the backup is restored to a different location than where the original database cluster resided, operations dependent upon the database cluster location may fail if supporting service scripts are not updated to reflect the location where the backup has been restored. For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). - -See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the BART `Restore` subcommand. - -An example of a restore operation is documented in the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/). - -!!! Note - If you set the [backup](../03_basic_bart_subcommand_usage/03_backup/#backup) `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring a backup. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx deleted file mode 100644 index 5d85c80281b..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Point-In-Time Recovery Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/point_in_time_recovery_operation.html" ---- - - - -The following steps outline how to perform a point-in-time recovery operation for a database cluster: - -1. Use your system-specific command to shut down the database server. - -2. If you want to: - a. restore the database cluster and tablespace files to new, empty directories, create the new directories with the appropriate directory ownership and permissions. - b. reuse the existing database cluster directories, delete all the files and subdirectories in the existing directories. We strongly recommend that you make a copy of this data before deleting it. Be sure to save any recent WAL files in the `pg_wal` subdirectory ( `pg_xlog` subdirectory if you are using server 9.6 version) that have not been archived to `archive_path`. - -3. Run the BART `SHOW-BACKUPS -s ` subcommand to list the backup IDs and backup names of the backups for the database server. You will need to provide the appropriate backup ID or backup name with the BART `RESTORE` subcommand, unless you intend to restore the latest backup in which case the `-i` option of the `RESTORE` subcommand for specifying the backup ID or backup name may be omitted. - -4. Run the BART `RESTORE` subcommand with the appropriate options. - - - The backup is restored to the directory specified by the `-p restore_path` option. - - - In addition, if the `RESTORE` subcommand `-c` option is specified or if the enabled setting of the `copy_wals_during_restore` BART configuration parameter is applicable to the database server, then the required archived WAL files from the `archive_path` are copied to the `restore_path/archived_wals` subdirectory. - - - Ensure the `restore_path` directory and all subdirectories and files in the `restore_path` are owned by the proper Postgres user account (for example, `enterprisedb` or `postgres`). Also ensure that only the Postgres user account has access permission to the `restore_path` directory. - - Use the `chown` command to make the appropriate adjustments to file permissions; for example, the following command changes the ownership of `restore_path` to `enterprisedb`: - - `chown -R enterprisedb:enterprisedb restore_path` - - The following command restricts access to `restore_path`: - - `chmod 700 restore_path` - -5. Copy any saved WAL files from Step 2 that were not archived to the BART backup catalog to the `restore_path/pg_wal` subdirectory (`pg_xlog` subdirectory if you are using server 9.6 version). - -6. Identify the timeline ID you wish to use to perform the restore operation. - - The available timeline IDs can be identified by the first non-zero digit of the WAL file names reading from left to right. - -7. Verify that the `postgresql.auto.conf` file created in the directory specified with the `RESTORE` subcommand’s `-p ` option was generated with the correct recovery parameter settings. - - If the `RESTORE` subcommand `-c` option is specified or if the enabled setting of the `copy_wals_during_restore` BART configuration parameter is applicable to the database server, then the `restore_command` parameter retrieves the archived WAL files from the `/archived_wals` subdirectory that was created by the `RESTORE` subcommand, otherwise the `restore_command` retrieves the archived WAL files from the BART backup catalog. - -8. The BART `RESTORE` subcommand disables WAL archiving in the restored database cluster. If you want to immediately enable WAL archiving, modify the `postgresql.conf` file by deleting the `archive_mode = off` parameter that BART appends to the end of the file. - -9. Start the database server, which will then perform the point-in-time recovery operation if recovery settings are saved in the `postgresql.auto.conf` file. - -For a detailed description of the `RESTORE` subcommand, see [Basic BART Subcommand Usage](../03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage). An example of a Point-in-Time Recovery operation is documented in the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the `Restore` subcommand. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/index.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/index.mdx deleted file mode 100644 index 4cb9c779397..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/01_bart_management_overview/index.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "BART Management Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/bart_management_overview.html" ---- - - - -After configuring BART, you can begin the backup and recovery management process. The following steps will help you get started: - -1. Run the `CHECK-CONFIG` subcommand without the `-s` option. When the `CHECK-CONFIG` subcommand is used without specifying the `-s` option, it checks the parameters in the global section of the BART configuration file. -2. Run the `INIT` subcommand (if you have not already done so) to finish creation of the BART backup catalog, which results in the complete directory structure to which backups and WAL files are saved. This step must be done before restarting the database servers with enabled WAL archiving, otherwise the copy operation in the `archive_command` parameter of the `postgresql.conf` file or the `postgresql.auto.conf` file fails due to the absence of the target archive directory. When the directory structure is complete, the `archived_wals` subdirectory should exist for each database server. -3. Start the Postgres database servers with archiving enabled. Verify that the WAL files are appearing in the `archive_path`. The archiving frequency is dependent upon other `postgresql.conf` configuration parameters. Check the Postgres database server log files to ensure there are no archiving errors. Archiving should be operational before taking a backup in order to ensure that the WAL files that may be created during the backup process are archived. -4. Start the WAL scanner if you intend to take incremental backups. Since the WAL scanner processes the WAL files copied to the `archive path`, it is advantageous to commence the WAL scanning as soon as the WAL files begin to appear in the `archive_path` in order to keep the scanning in pace with the WAL archiving. -5. Run the BART `CHECK-CONFIG` subcommand for each database server with the `-s` option specifying the server name. This ensures the database server is properly configured for taking backups. -6. Create a full backup for each database server. The full backup establishes the starting point of when point-in-time recovery can begin and also establishes the initial parent backup for any incremental backups to be taken. - -There are now a number of other BART management processes you may perform: - -- Execute the `BACKUP` subcommand to create additional full backups or incremental backups. -- Use the `VERIFY-CHKSUM` subcommand to verify the checksum of the full backups. -- Display database server information with the `SHOW-SERVERS` subcommand. -- Display backup information with the `SHOW-BACKUPS` subcommand. -- Compress the archived WAL files in the `archive_path` by enabling WAL compression in the BART configuration file and then invoking the `MANAGE` subcommand. -- Determine and set the retention policy for backups in the BART configuration file. -- Establish the procedure for using the `MANAGE` subcommand to enforce the retention policy for backups. This may include using `cron` jobs to schedule the `MANAGE` subcommand. - -
- -performing_a_restore_operation point_in_time_recovery_operation - -
diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx deleted file mode 100644 index 7169d6f7bb6..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Overview - Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview_managing_backups_using_a_retention_policy.html" ---- - - - -The BART retention policy results in the categorization of each backup in one of three statuses – *active*, *obsolete*, and *keep*. - -- **Active.** The backup satisfies the retention policy applicable to its server. Such backups would be considered necessary to ensure the recovery safety for the server and thus should be retained. -- **Obsolete.** The backup does not satisfy the retention policy applicable to its server. The backup is no longer considered necessary for the recovery safety of the server and thus can be deleted. -- **Keep.** The backup is to be retained regardless of the retention policy applicable to its server. The backup is considered vital to the recovery safety for the server and thus should not be deleted for an indefinite period of time. - -There are two types of retention policies - redundancy retention policy and recovery window retention policy. - -- **Redundancy Retention Policy** - The [redundancy retention policy](03_setting_the_retention_policy/#redundancy-retention-policy) relies on a specified, maximum number of most recent backups to retain for a given server. When the number of backups exceeds that maximum number, the oldest backups are considered obsolete (except for backups marked as keep). -- **Recovery Window Retention Policy** - The [recovery window retention policy](03_setting_the_retention_policy/#recovery-window-retention-policy) relies on a time frame (the recovery window) for when a backup should be considered active. The boundaries defining the recovery window are the current date/time (the ending boundary of the recovery window) and the date/time going back in the past for a specified length of time (the starting boundary of the recovery window). - - If the date/time the backup was taken is within the recovery window (that is, the backup date/time is on or after the starting date/time of the recovery window), then the backup is considered active, otherwise it is considered obsolete (except for backups marked as keep). - - Thus, for the recovery window retention policy, the recovery window time frame dynamically shifts, so the end of the recovery window is always the current date/time when the `MANAGE` subcommand is run. As you run the `MANAGE` subcommand at future points in time, the starting boundary of the recovery window moves forward in time. At some future point, the date/time of when a backup was taken will be earlier than the starting boundary of the recovery window. This is when an active backup’s status will be considered obsolete. - - You can see the starting boundary of the recovery window at any point in time by running the `SHOW-SERVERS` subcommand. The `RETENTION POLICY` field of the `SHOW-SERVERS` subcommand displays the starting boundary of the recovery window. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx deleted file mode 100644 index 047552d0a9e..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Marking the Backup Status" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/marking_the_backup_status.html" ---- - - - -When a backup is initially created with the `BACKUP` subcommand, it is always recorded with active status. Use the `MANAGE` subcommand to evaluate if the backup status should be changed to obsolete in accordance with the retention policy. You can review the current status of your backups with the `SHOW-BACKUPS` subcommand. - -Active backups are evaluated and also marked (that is, internally recorded by BART) as obsolete only when the `MANAGE` subcommand is invoked either with no options or with only the `-s` option. - -Once a backup has been marked as obsolete, you cannot change it back to active unless you perform the following steps: - -- Use the `MANAGE` subcommand with the `-c` option along with the backup identifier or name with the `-i` option. To keep this particular backup indefinitely, use `-c keep`, otherwise use `-c nokeep`. -- If you use the `-c nokeep` option, the backup status is changed back to active. When the `MANAGE` subcommand is used the next time, the backup is re-evaluated to determine if its status needs to be changed back to obsolete based on the current retention policy in the BART configuration file. - -After setting the `retention_policy` parameter and running the `MANAGE` subcommand if you change the `retention_policy` parameter, the current, marked status of the backups are probably inconsistent with the new `retention_policy` setting. To modify the backup status to be consistent with the new `retention_policy` setting, you need to run the `MANAGE` subcommand with: - -- the `-c nokeep` option to change the obsolete status to active status if there are backups currently marked as obsolete that would no longer be considered obsolete under a new retention policy. You can also specify the `-i all` option to change all backups back to active status, including those currently marked as keep. -- no options or with only the `-s` option to reset the marked status based on the new `retention_policy` setting in the BART configuration file. - -See [MANAGE](../03_basic_bart_subcommand_usage/07_manage/#manage) for usage information for the `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx deleted file mode 100644 index a4396239bfe..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "Setting the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/setting_the_retention_policy.html" ---- - - - -The retention policy is determined by the `retention_policy` parameter in the BART configuration file. It can be applied globally to all servers, but each server can override the global retention policy with its own. For information about creating a global retention policy and an individual database server retention policy, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). - -There are two types of retention policies - redundancy retention policy and the recovery window retention policy as described in the following sections. - - - -## Redundancy Retention Policy - -To use the redundancy retention policy, set `retention_policy = max_number BACKUPS` where `max_number` is a positive integer designating the maximum number of most recent backups. - -**Additional Restrictions:** - -- The keyword `BACKUPS` must always be specified in plural form (for example, `1 BACKUPS`). -- BART will accept a maximum integer value of 2,147,483,647 for `max_number`; however, you should use a realistic, practical value based on your system environment. - -The redundancy retention policy is the default type of retention policy if all keywords `BACKUPS`, `DAYS`, `WEEKS`, and `MONTHS` following the `max_number` integer are omitted as shown by the following example: - -`retention_policy = 3` - -In the following example, the redundancy retention policy setting considers the three most recent backups as the active backups. Any older backups, except those marked as `keep`, are considered obsolete: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -archive_command = 'cp %p %a/%f' -retention_policy = 3 BACKUPS -description = "Accounting" -``` - -The `SHOW-SERVERS` subcommand displays the `3 Backups` redundancy retention policy in the `RETENTION POLICY` field: - -```bash --bash-4.1$ bart SHOW-SERVERS -s acctg -SERVER NAME : acctg -HOST NAME : 127.0.0.1 -USER NAME : enterprisedb -PORT : 5444 -REMOTE HOST : -RETENTION POLICY : 3 Backups -DISK UTILIZATION : 627.04 MB -NUMBER OF ARCHIVES : 25 -ARCHIVE PATH : /opt/backup/acctg/archived_wals -ARCHIVE COMMAND : cp %p /opt/backup/acctg/archived_wals/%f -XLOG METHOD : fetch -WAL COMPRESSION : disabled -TABLESPACE PATH(s) : -DESCRIPTION : "Accounting" -``` - - - -## Recovery Window Retention Policy - -To use the recovery window retention policy, set the `retention_policy` parameter to the desired length of time for the recovery window in one of the following ways: - -- Set to `max_number DAYS` to define the start date/time recovery window boundary as the number of days specified by `max_number` going back in time from the current date/time. -- Set to `max_number WEEKS` to define the start date/time recovery window boundary as the number of weeks specified by `max_number` going back in time from the current date/time. -- Set to `max_number MONTHS` to define the start date/time recovery window boundary as the number of months specified by `max_number` going back in time from the current date/time. - -**Additional Restrictions:** - -- The keywords `DAYS`, `WEEKS`, and `MONTHS` must always be specified in plural form (for example, `1 DAYS`, `1 WEEKS`, or `1 MONTHS`). -- BART will accept a maximum integer value of `2,147,483,647` for `max_number`, however, a realistic, practical value based on your system environment must always be used. - -A backup is considered active if the date/time of the backup is equal to or greater than the start of the recovery window date/time. - -You can view the actual, calculated recovery window by: - -- Invoking the `MANAGE` subcommand in debug mode, along with the `-n` option. -- Using the `SHOW-SERVERS` subcommand. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx deleted file mode 100644 index def779a4026..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: "Managing the Backups Based on the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_the_backups_based_on_the_retention_policy.html" ---- - - - -The [MANAGE](../03_basic_bart_subcommand_usage/07_manage/#manage) subcommand is used to evaluate and categorize backups according to the retention policy set in the BART configuration file. When a backup is first created with the `BACKUP` subcommand, it is `active`. You can use the `MANAGE` subcommand to change the status of an active backup to `obsolete`. Obsolete backups can then be deleted. - -This section covers following aspects of backup management: - -- The rules for [deleting backups](#deletions_permitted_under_retention_policy) depending upon the backup status and the subcommand used. -- The process to retain a backup indefinitely by [marking it as keep](#marking-backups-for-indefinite-keep-status). This section also provides information about resetting backups status (that are marked as `obsolete` and `keep`) back to active status. -- The general process for [evaluating, marking, and then deleting obsolete backups](#evaluating-marking-and-deleting-obsolete-backups). - - - -## Deletions Permitted Under a Retention Policy - -This section describes how and under what conditions backups may be deleted under a retention policy. - -You must use the `MANAGE` subcommand to delete obsolete backups. Use the `DELETE` subcommand only for special administrative purposes. - -The deletion behavior of the `MANAGE` subcommand and the `DELETE` subcommand are based on different aspects of the retention policy. - -- The `MANAGE` subcommand deletion relies solely upon how a backup status is currently marked (that is, internally recorded by BART). The current setting of the `retention_policy` parameter in the BART configuration file is ignored. -- The `DELETE` subcommand relies solely upon the current setting of the `retention_policy` parameter in the BART configuration file. The current active, obsolete, or keep status of a backup is ignored. - -The specific deletion rules for the `MANAGE` and `DELETE` subcommands are as follows: - -- `MANAGE` subcommand: The `MANAGE` subcommand with the `-d` option can only delete backups marked as obsolete. This deletion occurs regardless of the current `retention_policy` setting in the BART configuration file. The deletion of backups relies on the last occasion when the backups have been marked. -- `DELETE` subcommand: - - - Under a redundancy retention policy currently set with the `retention_policy` parameter in the BART configuration file, any backup regardless of its marked status, can be deleted with the `DELETE` subcommand when the backup identifier or name is specified with the `-i` option and if the current total number of backups for the specified database server is greater than the maximum number of redundancy backups currently specified with the `retention_policy` parameter. - - If the total number of backups is less than or equal to the specified, maximum number of redundancy backups, then no additional backups can be deleted using `DELETE` with the `-i backup` option. - - - Under a recovery window retention policy currently set with the `retention_policy` parameter in the BART configuration file, any backup regardless of its marked status, can be deleted with the `DELETE` subcommand when the backup identifier or name is specified with the `-i` option, and if the backup date/time is not within the recovery window currently specified with the `retention_policy` parameter. If the backup date/time is within the recovery window, then it cannot be deleted using `DELETE` with the `-i backup` option. - - - Invoking the `DELETE` subcommand with the `-i all` option results in the deletion of all backups regardless of the retention policy and regardless of whether the status is marked as active, obsolete, or keep. - -The following table summarizes the deletion rules of backups according to their marked status. An entry of `Yes` indicates the backup may be deleted under the specified circumstances. An entry of `No` indicates that the backup may not be deleted. - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OperationRedundancy Retention PolicyRecovery Window Retention Policy
ActiveObsoleteKeepActiveObsoleteKeep
MANAGE –dNoYesNoNoYesNo
DELETE –i *backup* -

Yes

-

(see Note 1)

- 		-

Yes

-

(see Note 1)

- 		-

Yes

-

(see Note 1_)

- 		-

Yes

-

(see Note 2

- 		-

Yes

(see Note 2 - 		-

Yes

(see Note 2) -
DELETE –i allYesYesYesYesYesYes
- - - -!!! Note - Redundancy Retention Policy (Note 1) : Deletion occurs only if the total number of backups for the specified database server is greater than the specified, maximum number of redundancy backups currently set with the `redundancy_policy` parameter in the BART configuration file. - - - -!!! Note - Recovery Window Retention Policy (Note 2): Deletion occurs only if the backup is not within the recovery window currently set with the `redundancy_policy` parameter in the BART configuration file. - - - -## Marking Backups for Indefinite Keep Status - -There may be certain backups that you wish to keep for an indefinite period of time and do not wish to delete based upon the retention policy applied to the database server. Such backups can be marked as `keep` to exclude them from being marked as obsolete. Use the `MANAGE` subcommand with the `-c keep` option to retain such backups indefinitely. - - - -## Evaluating, Marking, and Deleting Obsolete Backups - -When the `MANAGE` subcommand is invoked, BART evaluates active backups: - -- If you include the `-s` option when invoking the `MANAGE` subcommand, BART evaluates backups for the database server. -- If you include the `-s all` option when invoking the `MANAGE` subcommand, BART evaluates backups for all database servers. -- If the `-s` option is omitted, the command evaluates the current number of backups for the database server based on the redundancy retention policy or the current date/time for a recovery window retention policy. - -!!! Note - The status of backups currently marked as `obsolete` or `keep` is not changed. To re-evaluate such backups and then classify them, their status must first be reset to `active` with the `MANAGE -c nokeep` option. See [Marking the Backup Status](02_marking_the_backup_status/#marking_the_backup_status) for more information. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) to review examples of how to evaluate, mark, and delete backups using a redundancy retention policy and recovery window retention policy, as well as examples of `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx deleted file mode 100644 index c69f6b09086..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Managing Incremental Backups" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_incremental_backups.html" ---- - - - -The following section summarizes how retention policy management affects incremental backups. - -- The retention policy rules are applied to full backups. - - A redundancy retention policy uses the number of full backups to determine if a backup is obsolete. Incremental backups are excluded from the comparison count against the `retention_policy` setting for the maximum number of backups. - - A recovery window retention policy uses the backup date/time of any full backups to determine if a backup is obsolete. The backup date/time of any successive incremental backups in the chain are ignored when comparing with the recovery window. -- The retention status of all incremental backups in a chain is set to the same status applied to the full backup of the chain. -- The actions applied by the `MANAGE` and `DELETE` subcommands on a full backup are applied to all incremental backups in the chain in the same manner. -- Thus, a backup chain (that is, the full backup and all its successive incremental backups) are treated by retention policy management as if they are all one, single backup. - - The status setting applied to the full backup is also applied to all incremental backups in its chain. - - If a full backup is marked as obsolete and then deleted according to the retention policy, all incremental backups in the chain are also marked obsolete and then deleted as well. - -The following are some specific points regarding the `MANAGE` and `DELETE` subcommands on incremental backups. - -- `MANAGE` subcommand: - - When the `MANAGE` subcommand is invoked, the status applied to the full backup is also applied to all successive incremental backups in the chain. - - The `MANAGE` subcommand with the `-c { keep | nokeep}` option cannot specify the backup identifier or backup name of an incremental backup with `-i` backup option. The `-i` backup option can only specify the backup identifier or backup name of a full backup. - - You can also use the `-i` all option to take a backup of all backups. When the `MANAGE` subcommand with the `-c { keep | nokeep }` option is applied to a full backup, the same status change is made to all incremental backups in the chain. -- `DELETE` subcommand: - - The `DELETE` subcommand with the `-s server -i` backup option specifies the backup identifier or backup name of an incremental backup in which case that incremental backup along with all its successive incremental backups are deleted, thus shortening that backup chain. - -## Using a Redundancy Retention Policy with Incremental Backups - -When a [redundancy retention policy](03_setting_the_retention_policy/#redundancy-retention-policy) is used and the `MANAGE` subcommand is invoked, the status of the oldest `active` full backup is changed to `obsolete` if the number of full backups exceeds the maximum number specified by the `retention_policy` parameter in the BART configuration file. - -!!! Note - When a full backup is changed from `active` to `obsolete`, all successive incremental backups in the chain of the full backup are also changed from `active` to `obsolete`. - -When determining the number of backups that exceeds the number specified by the `retention_policy` parameter, only full backups are counted for the comparison. Incremental backups are not included in the count for the comparison against the `retention_policy` parameter setting. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a redundancy retention policy is in effect. - -## Using a Recovery Window Retention Policy with Incremental Backups - -If the `MANAGE` command is invoked when BART is configured to use a [recovery window retention policy](03_setting_the_retention_policy/#recovery-window-retention-policy), the status of `active` full backups are changed to `obsolete` if the date/time of the full backup is outside of the recovery window. - -!!! Note - If a full backup is changed from `active` to `obsolete`, all successive incremental backups in the chain of the full backup are also changed from `active` to `obsolete`. - -The status of an incremental backup is changed to `obsolete` regardless of whether or not the date/time of when the incremental backup was taken still lies within the recovery window. - -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a recovery window retention policy is in effect. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx deleted file mode 100644 index aff92bbd6a5..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_backups_using_a_retention_policy.html" ---- - - - -Over the course of time when using BART, the number of backups can grow significantly. This ultimately leads to a large consumption of disk space unless an administrator periodically performs the process of deleting the oldest backups that are no longer needed. This process of determining when a backup is old enough to be deleted and then actually deleting such backups can be done and automated with the following basic steps: - -1. Determine and set a retention policy in the BART configuration file. A *retention policy* is a rule that determines when a backup is considered obsolete. The retention policy can be applied globally to all servers, but each server can override the global retention policy with its own. - -2. Use the `MANAGE` subcommand to categorize and manage backups according to the retention policy. - -3. Create a cron job to periodically run the `MANAGE` subcommand to evaluate the backups and then list and/or delete the obsolete backups. - - Retention policy management applies differently to incremental backups than to full backups. See [Managing Incremental Backups](05_managing_incremental_backups/#managing_incremental_backups) for information about how retention policy management is applied to each backup type. - - The following sections describe how retention policy management generally applies to backups, and its specific usage and effect on full backups. - -
- -overview_managing_backups_using_a_retention_policy marking_the_backup_status setting_the_retention_policy managing_the_backups_based_on_the_retention_policy managing_incremental_backups - -
diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx deleted file mode 100644 index f12dd038edd..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/check_config.html" ---- - - - -The `CHECK-CONFIG` subcommand checks the parameter settings in the BART configuration file as well as the database server configuration for which the `-s` option is specified. - -**Syntax:** - -`bart CHECK-CONFIG [ –s server_name ]` - -The following table describes the option. - -| Options | Description | -| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s ` or `--server ` | `server_name` is the name of the database server to be checked for proper configuration. If the option is omitted, the settings of the global section of the BART configuration file are checked. | - -- When the `-s` option is omitted, the global section \[BART] parameters including `bart_host`, `backup_path`, and `pg_basebackup_path` are checked. -- When the `-s` option is specified, the server section parameters are checked. In addition, certain database server `postgresql.conf` parameters are also checked, which include the following: - - The `cluster_owner` parameter must be set to the user account owning the database cluster directory. - - A passwordless SSH/SCP connection must be set between the BART user and the user account specified by the `cluster_owner` parameter. - - A database superuser must be specified by the BART `user` parameter. - - The `pg_hba.conf` file must contain a replication entry for the database superuser specified by the BART `user` parameter. - - The `archive_mode` parameter in the `postgresql.conf` file must be enabled. - - The `archive_command` parameter in the `postgresql.auto.conf` or the `postgresql.conf` file must be set. - - The `allow_incremental_backups` parameter in the BART configuration file must be enabled for database servers for which incremental backups are to be taken. - - Archiving of WAL files to the `archive_path` must be in process. - - The WAL scanner program must be running. - -The `CHECK-CONFIG` subcommand displays an error message if the required configuration is not properly set. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx deleted file mode 100644 index d8cdeed8126..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/init.html" ---- - - - -The `INIT` subcommand is used to create the BART backup catalog directory, rebuild the BART `backupinfo` file, and set the `archive_command` in the PostgreSQL server based on the `archive_command` setting in the `bart.cfg` file. - -!!! Note - If the `archive_mode` configuration parameter is set to `off`, then the `-o` option must be used to set the Postgres `archive_command` using the BART `archive_command` parameter in the BART configuration file even if the `archive_command` is not currently set in `postgresql.conf` nor in `postgresql.auto.conf` file. - -**Syntax:** - -```text -bart INIT [ –s { | all } ] [ -o ] - [ -r [ -i { | | all } ] ] - [--no-configure] -``` - -All subcommand options are generally specified in lowercase. The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`

`--server { \| all }` | `server_name` is the name of the database server to which the `INIT` actions are to be applied. If `all` is specified or if the option is omitted, the actions are applied to all servers. | -| `-o`

`--override` | Overrides the existing, active Postgres `archive_command` configuration parameter setting in the `postgresql.conf` file or the `postgresql.auto.conf` file using the BART `archive_command` parameter in the BART configuration file. The `INIT` generated archive command string is written to the `postgresql.auto.conf` file. | -| `-r`

`--rebuild` | Rebuilds the backupinfo file (a text file named `backupinfo`) located in each backup subdirectory. This option is only intended for recovering from a situation where the backupinfo file has become corrupt.
If the backup was initially created with a user-defined backup name, and then the `INIT -r` option is invoked to rebuild that `backupinfo` file, the user-defined backup name is no longer available. Thus, future references to the backup must use the backup identifier. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is an integer, backup identifier and `` is the user-defined alphanumeric name for the backup. If `all` is specified or if the option is omitted, the backupinfo files of all backups for the database servers specified by the `-s` option are recreated. The `-i` option can only be used with the `-r` option. | -| `--no-configure` | Prevents the `archive_command` from being set in the PostgreSQL server. | - -**Archive Command Setting** - -After the `archive_command` is set, you need to either restart the PostgreSQL server or reload the configuration file in the PostgreSQL server based on the following conditions. - -- If the `archive_mode` is set to `off` and `archive_command` is not set in the PostgreSQL server, the `archive_command` is set based on the `archive_command` setting in the `bart.cfg` and also sets the `archive_mode` to `on`. In this case, you need to restart the PostgreSQL server using `pg_ctl restart` -- If the `archive_mode` is set to `on` and `archive_command` is not set in the PostgreSQL server, the `archive_command` is set based on the `archive_command` setting in the `bart.cfg`. In this case, you need to reload the configuration in the PostgreSQL server using `pg_reload_conf()` or `pg_ctl reload`. -- If the `archive_mode` is set to `off` and `archive_command` is already set in the PostgreSQL server, the `archive_mode` is set to on. In this case, you need to restart the PostgreSQL server using `pg_ctl restart` -- If the `archive_mode` is set to `on` and `archive_command` is already set in the PostgreSQL server, then the `archive_command` is not set unless `-o` option is specified. diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx deleted file mode 100644 index 0189291fe44..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/backup.html" ---- - - - -The `BACKUP` subcommand is used to create a full backup or an incremental backup. - -**Syntax for full backup:** - -```text -bart BACKUP –s { | all } [ -F { p | t } ] - [ -z ] [ –c ] - [ --backup-name ] - [ --thread-count ] - [ { --with-pg_basebackup | --no-pg_basebackup } ] -``` - -!!! Note - While taking a backup, if a file (for example, database server log file) exceeding 1 GB size is stored in the `$PGDATA` directory, the backup will fail. To avoid such backup failure, you need to store large files (exceeding 1 GB) outside the `$PGDATA` directory. - -**Syntax for incremental Backup:** - -```text -bart BACKUP –s { | all } [ -F p] - [ --parent { | } ] - [ --backup-name ] - [ --thread-count ] - [ --check ] - [--checksum-algorithm ] -``` - -!!! Note - To take an [incremental backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup), you must take a full backup first followed by incremental backup. - -**Please Note:** - -- While a `BACKUP` subcommand is in progress, no other subcommands must be invoked. Any subcommands invoked while a backup is in progress will skip and ignore the backups. - -- For full backup, the target default format is a tar file, whereas for incremental backup, only plain format must be specified. - -- The backup is saved in the `//` directory, where `` is the value assigned to the `` parameter in the BART configuration file, `` is the lowercase name of the database server as listed in the configuration file, and `` is a backup identifier assigned by BART to the particular backup. - -- MD5 checksums of the full backup and any user-defined tablespaces are saved as well for tar backups. - -- Before performing the backup, BART checks to ensure if there is enough disk space to completely store the backup in the BART backup catalog. - -- In the `postgresql.conf` file, ensure the `wal_keep_segments` configuration parameter is set to a sufficiently large value. A low setting of the `wal_keep_segments` configuration parameter may result in the deletion of some WAL files before the BART `BACKUP` subcommand saves them to the `archive_path`. For information about the `wal_keep_segments` parameter, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/runtime-config-replication.html). - -- In the BART configuration file, setting `xlog_method=stream` will instruct the server to stream the transaction log in parallel with creation of the backup for a specific database server; otherwise the transaction log files are collected upon completion of the backup. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details about database server setting. - - !!! Note - If the transaction log streaming method is used, the `-Fp` option for a plain text backup format must be specified with the `BACKUP` subcommand. - -- When you use BART to take a backup of PostgreSQL server, multiple backups can be taken simultaneously and if a backup is interrupted, the backup mode is terminated automatically without the need to run `pg_stop_backup()` command manually to terminate the backup. - -**Options** - -Along with the `BACKUP` subcommand, specify the following option: - -| Options | Description | -| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { server_name \| all }`
`--server { server_name \| all }` | `server_name` is the database server name to be backed up as specified in the BART configuration file. If `all` is specified, all servers are backed up. This option is mandatory.
If `all` is specified, and a connection to a database server listed in the BART configuration file cannot be opened, the backup for that database server is skipped, but the backup operation continues for the other database servers. | - -Specify the following options as required. If you do not specify any of the following options, the backup is created using default settings. - -| Options | Description | -| -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-F { p \| t }`
`--format { p \| t }` | Specify this option to provide the backup file format. Use `p` for plain text or `t` for tar. If the option is omitted, the default is tar format.
For taking incremental backups, the option `-Fp` must be specified. | -| `-z`
`--gzip` | This is applicable only for full backup. Specify this option to use gzip compression on the tar file output using the default compression level. This option is applicable only for the tar format. | -| `-c `
`--compress-level ` | This is applicable only for full backup. Specify this option to use the gzip compression level on the tar file output. `compression_level` is a digit from 1 through 9, with 9 being the best compression. This option is applicable only for the tar format. | -| `--parent { backup_id \| backup_name }` | Specify this option to take an incremental backup. `` is the backup identifier of a parent backup. `` is the user-defined alphanumeric name of a parent backup.
The parent is a backup taken prior to the incremental backup. The parent backup can be either a full backup or an incremental backup.
The option `–Fp` must be specified since an incremental backup can only be taken in plain text format.
An incremental backup cannot be taken on a standby database server. See [Block-Level Incremental Backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup) for additional information on incremental backups. | -| `--backup-name ` | Specify this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
The backup name may include the following variables to be substituted by the timestamp values when the backup is taken: 1) `%year` – 4-digit year, 2) `%month` – 2-digit month, 3) `%day` – 2-digit day, 4) `%hour` 2-digit hour, 5) `%minute` – 2-digit minute, and 6) `%second` – 2-digit second.
To include the percent sign (`%`) as a character in the backup name, specify `%%` in the alphanumeric string.
If the backup name contains space characters (i.e. more than one word) or when referenced with the option `-i` by other subcommands (such as `restore`), enclose the string in single quotes or double quotes. See [backup name examples](#backup_name_examples).
If the `--backup-name` option is not specified, and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to use the number of worker threads to run in parallel to copy blocks for a backup.
If the option `--thread-count` is omitted, then the `thread_count` parameter in the BART configuration file applicable to this database server is used.
If the option `--thread-count` is not enabled for this database server, then the `thread_count` setting in the global section of the BART configuration file is used.
If the option `--thread-count` is not set in the global section as well, the default number of threads is 1.
If parallel backup is run with N number of worker threads, then it will initiate N+ 1 concurrent connections with the server.
Thread count will not be effective if backup is taken on a standby server.
For more information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/) | -| `--with-pg_basebackup` | This is applicable only for full backup. Specify this option to use `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the option `--with-pg_basebackup` is specified with the `BACKUP` subcommand. | -| `--no-pg_basebackup` | This is applicable only for full backup. Specify this option if you do not want `pg_basebackup` to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the option `--no-pg_basebackup` is specified with the `BACKUP` subcommand. | -| `--check` | This is applicable only for incremental backup. Specify this option to verify if the required MBM files are present in the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file before taking an incremental backup. The option `--parent` must be specified when the option `--check` is used. An actual incremental backup is not taken when the option `--check` is specified. | -| `--checksum-algorithm` | While taking a backup, you can specify one of the following values with the `--checksum-algorithm` option:
`--checksum-algorithm=MD5` (default) to generate MD5 checksum files.
`--checksum-algorithm=SHA256` to generate SHA256 checksum files.
`--checksum-algorithm=NONE` to skip generating checksum files. | - - - -**Backup Name Examples** - -The following examples demonstrate using the `--backup-name` clause: - -```text -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year -MONTH = %month DAY = %day" -./bart backup -s ppas12 -Ft --backup-name "YEAR = %year -MONTH = %month DAY = %day %%" -./bart show-backups -s ppas12 -i "test backup" -``` - -**Error messages** - -The following table lists the error messages that may be encountered when using the `BACKUP` subcommand: - -| error message | Cause | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `edb@localhost bin]$ ./bart backup -s mktg -Ft`

`WARNING: xlog_method is empty, defaulting to global policy`

`ERROR: backup failed for server 'mktg'`

`free disk space is not enough to backup the server 'mktg'`

`space available 13.35 GB, approximately required 14.65 GB` | Insufficient free disk space. | -| `ERROR: backup failed for server 'mktg'`

`command failed with exit code 1`

`pg_basebackup: could not get transaction log end position from server: ERROR: requested WAL segment 00000001000000D50000006B has already been removed` | The wal_keep_segments configuration parameter is not set to a sufficiently large value in the postgresql.conf file. | -| `ERROR: backup failed for server 'mktg'`

`connection to the server failed: could not connect to server: Connection refused`

`Is the server running on host "172.16.114.132" and accepting`

`TCP/IP connections on port 5444?` | A connection to a database server listed in the BART configuration file fails. As a result the backup for that database server is skipped, but the backup operation continues for other database servers | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx deleted file mode 100644 index 778efd3d4d6..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_servers.html" ---- - - - -The `SHOW-SERVERS` subcommand displays the information for the managed database servers listed in the BART configuration file. - -**Syntax:** - -`bart SHOW-SERVERS [ –s { | all } ]` - -The following table describes the command options. - -| Options | Description | -| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server whose BART configuration information is to be displayed. If `all` is specified or if the option is omitted, information for all database servers is displayed. | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx deleted file mode 100644 index d006df69db1..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_backups.html" ---- - -The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. - -**Syntax:** - -```text -bart SHOW-BACKUPS [ –s { | all } ] - [ -i { | | all } ] - [ -t ] -``` - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`
`--server { \| all }` | `` is the name of the database server whose backup information is to be displayed.
If `all` is specified or if the option is omitted, the backup information for all database servers is displayed with the exception as described by the following note:
If `SHOW-BACKUPS` is invoked while the BART `BACKUP` subcommand is in progress, backups affected by the backup process are shown in progress status in the displayed backup information. | -| `-i { \| \| all }`
`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified or if the option is omitted, all backup information for the relevant database server is displayed. | -| `-t`
`--toggle` | Displays more backup information in a list format. If the option is omitted, the default is a tabular format. | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx deleted file mode 100644 index 4ec79d52d62..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/verify_chksum.html" ---- - - - -The `VERIFY-CHKSUM` subcommand verifies the MD5 checksums of the full backups and any user-defined tablespaces for the specified database server or for all database servers. The checksum is verified by comparing the current checksum of the backup against the checksum when the backup was taken. - -!!! Note - The `VERIFY-CHKSUM` subcommand is only used for tar format backups. It is not applicable to plain format backups. - -**Syntax:** - -```text -bart VERIFY-CHKSUM - [ -s { | all } ] - [ -i { | | all } ] -``` - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s { \| all }`

`--server { \| all }` | `` is the name of the database server whose tar backup checksums are to be verified. If `all` is specified or if the `-s` option is omitted, the checksums are verified for all database servers. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is the backup identifier of a tar format full backup whose checksum is to be verified along with any user-defined tablespaces.
`` is the user-defined alphanumeric name for the full backup.
If `all` is specified or if the `-i` option is omitted, the checksums of all tar backups for the relevant database server are verified. | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx deleted file mode 100644 index 52a74badaa7..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/manage.html" ---- - - - -The `MANAGE` subcommand can be invoked to: - -- Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file (See [Managing Backups Using a Retention Policy](../02_managing_backups_using_a_retention_policy/#managing_backups_using_a_retention_policy) for information about retention policy management). - -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file (See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting this parameter). - - **Syntax:** - - ```text - bart MANAGE [ –s { | all} ] - [ -l ] [ -d ] - [ -c { keep | nokeep } - -i { | | all } ] - [ -n ] - ``` - -The following summarizes the actions performed when the `MANAGE` subcommand is invoked: - -- When the `MANAGE` subcommand is invoked with no options or with only the `-s ` or `-s all` option, the following actions are performed: - - For the server specified by the `-s` option, or for all servers (if `-s all` is specified or the `-s` option is omitted), active backups are marked as `obsolete` in accordance with the retention policy. - - All backups that were marked `obsolete` or `keep` prior to invoking the `MANAGE` subcommand remain marked with the same prior status. - - If WAL compression is enabled for the database server, then any uncompressed, archived WAL files in the BART backup catalog of the database server are compressed with gzip. -- When the `MANAGE` subcommand is invoked with any other option besides the `-s` option, the following actions are performed: - - For the server specified by the `-s` option, or for all servers, the action performed is determined by the other specified options (that is, `-l` to list obsolete backups, `-d` to delete obsolete backups, `-c` to keep or to return backups to `active` status, or `-n` to perform a dry run of any action). - - No marking of `active` backups to `obsolete` status is performed regardless of the retention policy. - - All backups that were marked `obsolete` or `keep` prior to invoking the `MANAGE` subcommand remain marked with the same prior status unless the `-c` option (without the `-n` option) is specified to change the backup status of the particular backup or all backups referenced with the `-i` option. - - No compression is applied to any uncompressed, archived WAL file in the BART backup catalog regardless of whether or not WAL compression is enabled. - -The following are additional considerations when using WAL compression: - -- Compression of archived WAL files is not permitted for database servers on which incremental backups are to be taken. -- The gzip compression program must be installed on the BART host and be accessible in the `PATH` of the BART user account. -- When the `RESTORE` subcommand is invoked, if the `-c` option is specified or if the `copy_wals_during_restore` BART configuration parameter is enabled for the database server, then the following actions occur: - - - If compressed, archived WAL files are stored in the BART backup catalog and the location to which the WAL files are to be restored is on a remote host relative to the BART host: - - - the archived WAL files are transmitted across the network to the remote host in compressed format only if the gzip compression program is accessible in the `PATH` of the remote user account that is used to log into the remote host when performing the `RESTORE` operation. - - This remote user is specified with either the `remote_host` parameter in the BART configuration file or the `RESTORE -r` option (see [RESTORE](08_restore/#restore)). - - Transmission of compressed WAL files results in less network traffic. After the compressed WAL files are transmitted across the network, the `RESTORE` subcommand uncompresses the files for the point-in-time recovery operation. - - If the gzip program is not accessible on the remote host in the manner described in the previous bullet point, then the compressed, archived WAL files are first uncompressed while on the BART host, then transmitted across the network to the remote host in uncompressed format. -- When the `RESTORE` subcommand is invoked without the `-c` option and the `copy_wals_during_restore` BART configuration parameter is disabled for the database server, then any compressed, archived WAL files needed for the `RESTORE` operation are uncompressed in the BART backup catalog. The uncompressed WAL files can then be saved to the remote host by the `restore_command` in the `postgresql.auto.conf` file when the database server archive recovery begins. - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `s { \| all }`
`--server { \| all }` | `` is the name of the database server to which the actions are to be applied. If `all` is specified or if the `-s` option is omitted, the actions are applied to all database servers. | -| `-l`
`--list-obsolete` | Lists the backups marked as obsolete. | -| `-d`
`--delete-obsolete` | Delete the backups marked as `obsolete`. This action physically deletes the backup along with its archived WAL files and any MBM files for incremental backups. | -| `-c { keep \| nokeep }`

`--change-status { keep \| nokeep }` | Specify `keep` to change the status of a backup to `keep` to retain it indefinitely.
Specify `nokeep` to change the status of any backup back to active status. The backup can then be re-evaluated and possibly be marked to `obsolete` according to the retention policy by subsequent usage of the `MANAGE` subcommand.
The `–i` option must be included when using the `-c` option. | -| `-i { \| \| all }`

`--backupid { \| \| all }` | `` is a backup identifier and `` is the user-defined alphanumeric name for the backup.
If `all` is specified, then actions are applied to all backups.
The `–c` option must be included when using the `-i` option. | -| `-n`
`--dry-run` | Performs the test run and displays the results prior to actually implementing the actions as if the operation was performed, however, no changes are actually made.
If `-n` is specified with the `-d` option, it displays which backups would be deleted, but does not actually delete the backups.
If `-n` is specified with the `-c` option, it displays the keep or nokeep action, but does not actually change the backup from its current status.
If `-n` is specified alone with no other options, or with only the `-s` option, it displays which active backups would be marked as obsolete, but does not actually change the backup status. In addition, no compression is performed on uncompressed, archived WAL files even if WAL compression is enabled for the database server. | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx deleted file mode 100644 index a7fc6fc64ab..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restore.html" ---- - - - -The `RESTORE` subcommand restores a backup and its archived WAL files for the designated database server to the specified directory location. If the appropriate `RESTORE` options are specified, all recovery settings will be saved in the `postgresql.auto.conf` file. - -**Syntax:** - -```text -bart RESTORE –s -p - [ –i { | } ] - [ -r ] - [ -w ] - [ -t ] - [ { -x | -g } ] - [ -c ] - [ --disable-checksum ] -``` - -For information about using a continuous archive backup for recovery, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/13/static/continuous-archiving.html). This reference material provides detailed information about the underlying point-in-time recovery process and the meaning and usage of the restore options that are generated into the `postgresql.auto.conf` file by BART. - -**Please note**: - -- For special requirements when restoring an incremental backup to a remote database server, see [Restoring an Incremental Backup on a Remote Host](../../02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup/#restoring_an_incremental_backup_on_a_remote_host). -- Check to ensure that the host where the backup is to be restored contains enough disk space for the backup and its archived WAL files. The `RESTORE` subcommand may result in an error while copying files if there is not enough disk space available. -- See [Performing a Restore Operation](../01_bart_management_overview/01_performing_a_restore_operation/#performing_a_restore_operation) to view steps on how to perform a restore operation and see [Point-In-Time Recovery Operation](../01_bart_management_overview/02_point_in_time_recovery_operation/#point_in_time_recovery_operation) to view steps on how to perform a point-in-time recovery operation. -- If the backup is restored to a different database cluster directory than where the original database cluster resided, certain operations dependent upon the database cluster location may fail. This happens if their supporting service scripts are not updated to reflect the new directory location of restored backup. For information about the usage and modification of service scripts, see the *EDB Advanced Server Installation Guide* available at the [EDB website](/epas/latest/). - -The following table describes the command options: - -| Options | Description | -| ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `
`--server ` | `` is the name of the database server to be restored. | -| `-p `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | -| `-i { \| }`

`--backupid { \| }` | `` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the default is to use the latest backup. | -| `-r or --remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored and `` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `` parameter for this database server is not set in the BART configuration file.
If the BART user account is not the same as the operating system account owning the `` directory given with the `-p` option, use the `` BART configuration parameter or the `RESTORE` subcommand `-r` option to specify the `` directory owner even when restoring to a directory on the same host as the BART host.
See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `` parameter. | -| `-w `
`--workers ` | `` is the specification of the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location.
For example, if 4 worker processes are specified, 4 receiver processes on the restore host and 4 streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process. When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. If the `-w` option is omitted, the default is `1` \| worker process. | -| `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | -| `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. Include either the `-x ` or the `--target-xid ` option if point-in-time recovery is desired. | -| `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. Include either the `--target-timestamp ` or the `-g ` option if point-in-time recovery is desired. | -| `-c`
`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
If recovery settings are saved in the `postgresql.auto.conf` file for point-in-time recovery, the `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, the `restore_command` in the `postgresql.auto.conf` file is generated by default to retrieve the archived WAL files directly from the BART backup catalog. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `copy_wals_during_restore` parameter. | -| `--disable-checksum` | While restoring a backup, specify this option to skip verifying the MD5 or SHA256 checksum files.
If you set the `--checksum-algorithm=NONE` option with the [BART scanner](../04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or while taking a [backup](03_backup/#backup), you must specify the `--disable checksum` option while restoring an incremental backup. | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx deleted file mode 100644 index 7f9836ad724..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/delete.html" ---- - - - -The `DELETE` subcommand removes the subdirectory and data files from the BART backup catalog for the specified backups along with its archived WAL files. - -**Syntax:** - -```text -bart DELETE –s - -i { all | - [']{ | },... }['] - } - [ -n ] -``` - -!!! Note - While invoking the `DELETE` subcommand, you must specify a specific database server. - -For database servers under a retention policy, there are conditions where certain backups may not be deleted. See [Deletions Permitted Under a Retention Policy](../02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy/#deletions_permitted_under_retention_policy) for information about permitted backup deletions. - -The following table describes the command options: - -| Options | Description | -| -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-s `

`--server ` | `` is the name of the database server whose backups are to be deleted. | -| `-i { all \| [']{ \| },... }['] }`

`--backupid { all \| [']{ \| },... }['] }` | `` is the backup identifier of the backup to be deleted and `` is the user-defined alphanumeric name for the backup.
Multiple backup identifiers and backup names may be specified in a comma-separated list. The list must be enclosed within single quotes if there is any white space appearing before or after each comma.
If `all` is specified, all of the backups and their archived WAL files for the specified database server are deleted. | -| `-n`
`--dry-run` | Displays the results as if the deletions were done, however, no physical removal of the files are actually performed. In other words, a test run is performed so that you can see the potential results prior to actually initiating the action.
After the deletion, the BART backup catalog for the database server no longer contains the corresponding directory for the deleted backup ID. The `archived_wals` subdirectory no longer contains the WAL files of the backup. | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx deleted file mode 100644 index e7d51affa18..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Basic BART Subcommand Usage" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/basic_bart_subcommand_usage.html" ---- - - - -This section briefly describes the BART subcommands and options. You can invoke the `bart` program (located in the `/bin` directory) with the desired options and subcommands to manage your BART installation. - -To view examples of BART subcommands, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -**Syntax for invoking BART**: - - `bart [ general_option ]... [ subcommand ] [subcommand_option ]...` - -- When invoking a subcommand, the subcommand name is not case-sensitive (that is, the subcommand can be specified in uppercase, lowercase, or mixed case). -- Each subcommand has a number of its own applicable options that are specified following the subcommand. All options are available in both single-character and multi-character forms. -- Keywords are case-sensitive; options are generally specified in lowercase unless specified otherwise in this section. -- When invoking BART, the current user must be the BART user account (operating system user account used to run the BART command line program). For example, enterprisedb or postgres can be selected as the BART user account when the managed database servers are Advanced Server or PostgreSQL respectively. -- The chosen operating system user account must own the BART backup catalog directory, be able to run the `bart` program and the `bart scanner` program, and have a passwordless SSH/SCP connection established between database servers managed by BART. - -You can specify one or more of the following general options: - -| Options | Description | -| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on BART usage. All subcommands support a help option (`-h`, `--help`). If the help option is specified, information is displayed regarding that particular subcommand. The subcommand, itself, is not executed. | -| `-v` `--version` | Displays the BART version information. | -| `-d` `--debug` | Displays debugging output while executing BART subcommands. | -| `-c ` `--config-path ` | Specifies `config_file_path` as the full directory path to a BART configuration file. Use this option if you do not want to use the default BART configuration file `/etc/bart.cfg`. | - -**Troubleshooting: Setting Path Environment Variable** - -If execution of BART subcommands fails with the following error message, then you need to set the `LD_LIBRARY_PATH` to include the `libpq` library directory: - - `./bart: symbol lookup error: ./bart: undefined symbol: PQping` - -**Workaround:** Set the `LD_LIBRARY_PATH` environment variable for the BART user account to include the directory containing the `libpq` library. This directory is `POSTGRES_INSTALL_HOME/lib`. - -It is suggested that the `PATH` and the `LD_LIBRARY_PATH` environment variable settings be placed in the BART user account’s profile. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details. - -In the following sections, the `help` option is omitted from the syntax diagrams for the purpose of providing readability for the subcommand options. - -
- -check_config init backup show_servers show_backups verify_chksum manage restore delete - -
diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx deleted file mode 100644 index f4a4a6e5cbd..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/running_the_bart_wal_scanner.html" ---- - - - -Use the BART WAL scanner to invoke the `bart-scanner` program located in the `BART_HOME/bin` directory. When invoking the WAL scanner, the current user must be the BART user account. - -**Syntax:** - -```text -bart-scanner - [ -d ] - [ -c ] - { –h | - -v | - --daemon | - -p | - | - RELOAD | - STOP - --checksum-algorithm } -``` - -!!! Note - For clarity, the syntax diagram shows only the single-character option form (for example, `-d`), but the multi-character option form (for example, `--debug`) is supported as well. - -The WAL scanner processes each WAL file to find and record modified blocks in a corresponding modified block map (MBM) file. The default approach is that the WAL scanner gets notified whenever a new WAL file is added to the `archived_wals` directory specified in the `archive_path` parameter of the configuration file. It then scans the WAL file and produces the MBM file. - -The default approach does not work in some cases; for example when the WAL files are shipped to the `archive_path` using the Network File System (NFS) and also in case of some specific platforms. This results in the WAL files being copied to the `archived_wals` directory, but the WAL scanner does not scan them (as WAL scanner is not aware of WAL file) and produce the MBM files. This results in the failure of an incremental backup. This can be avoided by using the timer-based WAL scanning approach, which is done by using the `scan_interval` parameter in the BART configuration file. The value for `scan_interval` is the number of seconds after which the WAL scanner will initiate force scanning of the new WAL files. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about `scan_interval` parameter. - -!!! Note - After upgrading to BART 2.6, users who have set this parameter to a non-default value may see increased CPU consumption on the part of bart-scanner. If this is an issue, consider increasing the configured value of scan_interval parameter, or removing the setting if it is not required. - -When the `bart-scanner` program is invoked, it forks a separate process for each database server enabled with the `allow_incremental_backups` parameter. - -The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option. Use the `--daemon` option to run the WAL scanner process in the background so that all output messages can be viewed in the BART log file. If the `--daemon` option is omitted, the WAL scanner process runs in the foreground and all output messages can be viewed from the terminal running the program as well as in the BART log file. - -See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for additional information about WAL scanning, `allow_incremental_backups`, and `logfile` parameters. - -!!! Note - The BART user account’s `LD_LIBRARY_PATH` environment variable may need to be set to include the directory containing the `libpq` library if invocation of the WAL scanner program fails. See [Basic BART Subcommand Usage](03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage) for information about setting the `LD_LIBRARY_PATH` environment variable. - -The following table describes the scanner options: - -| Options | Description | -| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `-h` `--help` | Displays general syntax and information on WAL scanner usage. | -| `-v` `--version` | Displays the WAL scanner version information. | -| `-d` `--debug` | Displays debugging output while executing the WAL scanner with any of its options. | -| `-c ` `--config-path ` | Use this option to specify the `config_file_path` of a BART configuration file if you do not want to use the default BART configuration file path `BART_HOME/etc/bart.cfg`. | -| `--daemon` | Runs the WAL scanner as a background process. | -| `-p ` `--print ` | Use this option to specify the full directory path to an MBM file whose content is to be printed. The directory specified in the `archive_path` parameter in the `bart.cfg` file contains the MBM files. | -| `` | Specify the full directory path to a WAL file to be scanned. The directory specified in the `archive_path` parameter in the `bart.cfg` file contains the WAL files. Use this option if a WAL file in the archive path is missing its MBM file. This option is to be used for assisting the EnterpriseDB support team for debugging problems that may have been encountered. | -| `RELOAD` | Reloads the BART configuration file. The keyword `RELOAD` is not case-sensitive. The `RELOAD` option is useful if you make changes to the configuration file after the WAL scanner has been started. It will reload the configuration file and adjust the WAL scanners accordingly. For example, if a server section allowing incremental backups is removed from the BART configuration file, then the process attached to that server will stop. Similarly, if a server allowing incremental backups is added, a new WAL scanner process will be launched to scan the WAL files of that server. | -| `STOP` | Stops the WAL scanner. The keyword `STOP` is not case-sensitive. | -| `--checksum-algorithm` | While invoking the WAL scanner, you can specify one of the following values with the `--checksum-algorithm` option: `--checksum-algorithm=MD5` (default) to generate MD5 checksum files. `--checksum-algorithm=SHA256` to generate SHA256 checksum files. `--checksum-algorithm=NONE` to skip generating checksum files. | diff --git a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/index.mdx b/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/index.mdx deleted file mode 100644 index a076b82b5e9..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/03_using_bart/index.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: "Using BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_bart.html" ---- - - - -After installing and configuring the BART host and the database servers, you can start using BART. - -This section describes how to perform backup and recovery management operations using BART. Review the sections that follow before proceeding with any BART operation. - -
- -bart_management_overview managing_backups_using_a_retention_policy basic_bart_subcommand_usage running_the_bart_wal_scanner - -
diff --git a/product_docs/docs/bart/2.6.2/bart_user/04_using_tablespaces.mdx b/product_docs/docs/bart/2.6.2/bart_user/04_using_tablespaces.mdx deleted file mode 100644 index 94d5450778a..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/04_using_tablespaces.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Using Tablespaces" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_tablespaces.html" ---- - - - -If the database cluster contains user-defined tablespaces (that is, tablespaces created with the `CREATE TABLESPACE` command): - -- You can take full backups with the `BACKUP` subcommand in either tar (`-Ft`) or plain text (`-Fp`) backup file format. -- You must take incremental backups in the plain text (`-Fp`) backup file format. -- You can take full backups using the transaction log streaming method (xlog_method = stream in the BART configuration file) `--with-pg_basebackup` and the `BACKUP` subcommand in either tar (`-Ft`) or plain text (`-Fp`) backup file format. - -!!! Note - If the particular database cluster you plan to back up contains tablespaces created by the `CREATE TABLESPACE` command, then you must set the `tablespace_path` parameter in the BART configuration file before you perform a BART `RESTORE` operation. - -The `tablespace_path` parameter specifies the directory paths to which you want the tablespaces to be restored. It takes the following format: - - `OID_1=tablespace_path_1;OID_2=tablespace_path_2 ...` - -Where `OID_1`, `OID_2`, … are the Object Identifiers of the tablespaces. You can find the OIDs of the tablespaces and their corresponding soft links to the directories by listing the contents of the `POSTGRES_INSTALL_HOME/data/pg_tblspc` subdirectory as shown in the following example: - -```text -[root@localhost pg_tblspc ]# pwd -/opt/PostgresPlus/9.6AS/data/pg_tblspc -[root@localhost pg_tblspc]# ls -l -total 0 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Aug 22 16:38 16644 -> /mnt/tablespace_1 -lrwxrwxrwx 1 enterprisedb enterprisedb 17 Aug 22 16:38 16645 -> /mnt/tablespace_2 -``` - -The OIDs are `16644` and `16645` to directories `/mnt/tablespace_1` and `/mnt/tablespace_2`, respectively. - -If you later wish to restore the tablespaces to the same locations as indicated in the preceding example, the BART configuration file must contain the following entry: - -```text -[ACCTG] -host = 127.0.0.1 -port = 5444 -user = enterprisedb -cluster_owner = enterprisedb -tablespace_path = 16644=/mnt/tablespace_1;16645=/mnt/tablespace_2 -description = "Accounting" -``` - -If you later wish to restore the tablespaces to different locations, specify the new directory locations in the `tablespace_path` parameter. - -In either case, the directories specified in the `tablespace_path` parameter must exist and be empty at the time you perform the `BART RESTORE` operation. - -If the database server is running on a remote host (in other words you are also using the `remote_host` configuration parameter or will specify the `--remote-host` option with the `RESTORE` subcommand), the specified tablespace directories must exist on the specified remote host. - -To view example of backing up and restoring a database cluster on a remote host containing tablespaces, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). - -The directories must be owned by the user account with which you intend to start the database server (typically the Postgres user account) with no access by other users or groups as is required for the directory path to which the main full backup is to be restored. - -To view a sample BART managed backup and recovery system consisting of both local and remote database servers, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.6.2/bart_user/images/EDB_logo.png b/product_docs/docs/bart/2.6.2/bart_user/images/EDB_logo.png deleted file mode 100644 index f4a93cf57f5..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/images/EDB_logo.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:07423b012a855204780fe5a2a5a1e33607304a5c3020ae4acbf3d575691dedd6 -size 12136 diff --git a/product_docs/docs/bart/2.6.2/bart_user/images/copy_1.png b/product_docs/docs/bart/2.6.2/bart_user/images/copy_1.png deleted file mode 100644 index e08d97827fb..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/images/copy_1.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:c2b13e1623222f77bce5a2d1be4027a9032c878b05bed7ba1a0873be45257d8c -size 10470 diff --git a/product_docs/docs/bart/2.6.2/bart_user/images/edb.png b/product_docs/docs/bart/2.6.2/bart_user/images/edb.png deleted file mode 100644 index 3e8d3c76655..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/images/edb.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:df8233799fa8616e3762286196fbaf567f3ef45830c65bfcb42214e86a5d69fc -size 12049 diff --git a/product_docs/docs/bart/2.6.2/bart_user/images/edb_logo.svg b/product_docs/docs/bart/2.6.2/bart_user/images/edb_logo.svg deleted file mode 100644 index f24d1dfefee..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/images/edb_logo.svg +++ /dev/null @@ -1,19 +0,0 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file diff --git a/product_docs/docs/bart/2.6.2/bart_user/index.mdx b/product_docs/docs/bart/2.6.2/bart_user/index.mdx deleted file mode 100644 index 50504d9e3db..00000000000 --- a/product_docs/docs/bart/2.6.2/bart_user/index.mdx +++ /dev/null @@ -1,17 +0,0 @@ ---- -navTitle: Backup and Recovery Guide -title: "EDB Postgres Backup and Recovery User Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/index.html" ---- - -
- -introduction overview using_bart using_tablespaces conclusion - -
diff --git a/product_docs/docs/bart/2.6.2/index.mdx b/product_docs/docs/bart/2.6.2/index.mdx deleted file mode 100644 index 8993f4a09fd..00000000000 --- a/product_docs/docs/bart/2.6.2/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Backup and Recovery Tool -directoryDefaults: - description: "EDB Backup and Recovery Tool Version 2.6.1 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." -navigation: - - "#Getting Started" - - bart_inst - - bart_qs_7 - - bart_qs_8 - - "#Guides" - - bart_user - - bart_ref -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-backup-and-recovery-tool/2.6.1" ---- diff --git a/product_docs/docs/bart/2.6/bart_inst/02_installing_bart.mdx b/product_docs/docs/bart/2.6/bart_inst/02_installing_bart.mdx index 710e39d9228..f98fbd30f52 100644 --- a/product_docs/docs/bart/2.6/bart_inst/02_installing_bart.mdx +++ b/product_docs/docs/bart/2.6/bart_inst/02_installing_bart.mdx @@ -1,9 +1,5 @@ --- title: 'Installing BART' - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/installing_bart.html" --- This section will walk you through performing a fresh installation of BART on a host. Installation instructions are organized into the following platform/installer specific sections: @@ -110,7 +106,7 @@ The following section demonstrates installing BART on a CentOS host using an RPM The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). + - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). Upon successful installation, BART is installed in the `BART_HOME` directory: @@ -231,7 +227,7 @@ The following section demonstrates installing BART on a RHEL host using an RPM p The `bart --version` command should return the current BART version. If the `bart --version` command returns an error stating the PATH is not available after switching from the root user to another BART user account, adjust the setting of the `PATH` environment variable to include the directory location of the BART `bin` subdirectory in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - The BART user account on the BART host. See [Configuring BART](03_configuring_bart/#path) for details. - - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). + - The remote user account on the remote host to which incremental backups are to be restored. For details, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). Upon successful installation, BART is installed in the `BART_HOME` directory: diff --git a/product_docs/docs/bart/2.6/bart_inst/03_configuring_bart.mdx b/product_docs/docs/bart/2.6/bart_inst/03_configuring_bart.mdx index 29ca4a2c1a8..6cc270a0ad4 100644 --- a/product_docs/docs/bart/2.6/bart_inst/03_configuring_bart.mdx +++ b/product_docs/docs/bart/2.6/bart_inst/03_configuring_bart.mdx @@ -1,9 +1,5 @@ --- title: "Configuring BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/configuring_bart.html" --- @@ -124,11 +120,11 @@ The following table describes the `[BART]` host parameters. | `[BART}` | Mandatory | Identifies the global section of the configuration file. It must be named BART. | | `bart_host` | Mandatory | Specify the bart user name and the IP address of the bart host on which the BART utility resides. You must specify it in the form of <bart_user>@<bart_host_address>. | | `backup_path` | Mandatory | Specify the path to the file system parent directory where all BART backups are stored. | -| `pg_basebackup_path` | Mandatory | Specify the path to the `pg_basebackup` program that you installed on the BART host. For information about `pg_basebackup` version-specific restrictions, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). | +| `pg_basebackup_path` | Mandatory | Specify the path to the `pg_basebackup` program that you installed on the BART host. For information about `pg_basebackup` version-specific restrictions, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | | `wal_compression` | Optional | Set this parameter to `enabled` to compress the archived WAL files in gzip format in the BART backup catalog when the `MANAGE` subcommand is invoked. By default it is set to `disabled`. The gzip compression program must be in the BART user account’s `PATH` and the WAL compression setting must not be enabled for those database servers where you need to take incremental backups. | | `copy_wals_during_restore` | Optional | Set this parameter to `enabled` to copy the archived WAL files from the BART backup catalog to the `restore_path/archived_wals` directory prior to the database server archive recovery. Enabling this option helps you save time during the restore operation. Set this parameter to `disabled` (default) to retrieve the archived WAL files directly from the BART backup catalog during the database server archive recovery. During the restore operation, recovery settings will be saved in the `postgresql.auto.conf` file. The `restore_command` in the `postgresql.auto.conf` file will be determined by the value specified in the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked with the `-c` option, the archived WAL files are copied from the BART backup catalog to the `restore_path/archived_wals` directory, thus overriding any setting of the `copy_wals_during_restore` parameter. If the `RESTORE` subcommand is invoked without the `-c` option, the value specified by the `copy_wals_during_restore` parameter is used. | | `xlog_method` | Optional | Specify how the transaction log is collected during the execution of `pg_basebackup` through the `BACKUP` subcommand. Set `xlog_method` to `fetch` (default) to collect the transaction log files after the backup is completed. Set to `stream` to stream the transaction log in parallel with the full backup creation. | -| `retention_policy` | Optional | Set this parameter to determine when an active backup should be marked as `obsolete` when the `MANAGE` subcommand is used. You can specify the retention policy either in terms of number of backups or duration (days, weeks, or months). ` BACKUPS` (default), ` DAYS`, ` WEEKS`, or ` MONTHS` where `` is a positive integer. For information about managing backups using a retention policy, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). | +| `retention_policy` | Optional | Set this parameter to determine when an active backup should be marked as `obsolete` when the `MANAGE` subcommand is used. You can specify the retention policy either in terms of number of backups or duration (days, weeks, or months). ` BACKUPS` (default), ` DAYS`, ` WEEKS`, or ` MONTHS` where `` is a positive integer. For information about managing backups using a retention policy, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | | `logfile` | Optional | Use this parameter to specify the path to the BART log file. The default log file location is `/tmp/bart.log`. The log file will be created the first time you invoke the `bart` command line program using the sample configuration file value. To change the default setting, you must delete the `bart.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a log file. | | `scanner_logfile` | Optional | Use this parameter to specify the path to the XLOG/WAL scanner log file. The default location is `/tmp/bart_scanner.log`. The scanner log file will be created the first time you invoke the `bart_scanner` program using the sample configuration file value. To change the default setting, you must delete the `bart_scanner.log` file from the `/tmp` directory and create a new log file in another directory so that a new log file will be created and owned by the new BART user account. If no path to a log file is specified, BART does not create a WAL scanner log file. | | `` | Optional | Specify the socket directory path where all BART sockets will be stored. The default directory is `/tmp`. While specifying the `bart_socket_directory` path, you must ensure that the directory exists and the BART user has the required access permissions to the directory. | @@ -199,7 +195,7 @@ For BART usage, there are two scenarios that require a passwordless SSH/SCP conn - The public key file name should be appended to the `~/.ssh/authorized_keys` file on the database server host. The `authorized_keys` file is in the home directory of the user account that owns the directory where the database backup is to be restored. - If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. -See the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/2.6/bart_ref/) to view examples of creating a passwordless connection. +See the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/) to view examples of creating a passwordless connection. **Enabling Public Key Authentication** @@ -362,7 +358,7 @@ The following table describes the database server parameters. | `` | Mandatory | Specify the Linux operating system user account that owns the database cluster. This is typically `enterprisedb` for Advanced Server database clusters installed in the Oracle compatible mode, or `postgres` for Advanced Server database clusters installed in the PostgreSQL compatible mode and PostgreSQL database clusters. | | `` | Optional | Specify the IP address of the remote server to which a backup is to be restored. Specify this parameter in the form of `@`. `` is the user account on the target database server host that accepts a passwordless SSH/SCP login connection and owns the directory where the backup is to be restored. `` is the IP address of the remote host. For restoring a backup to a remote host or for restoring any backup where `` and the BART user account are not the same users, either this parameter must be set or it may be specified with the `-r` option with the BART `RESTORE` subcommand. | | `` | Optional | Specify path to which tablespaces are to be restored in the format `OID = `; If the backup is to be restored to a remote host specified by the `` parameter, then the tablespace paths must exist on the remote host. | -| `allow_incremental_backups` | Optional | Set this parameter to `enabled` to enable use of the WAL scanner and permit taking incremental backups when the `BACKUP` subcommand is invoked with the `--parent` option. Set it to `disabled` (default) to disallow incremental backups and thus permit only full backups. For information about using the `BACKUP` subcommand and running the WAL scanner, please see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). | +| `allow_incremental_backups` | Optional | Set this parameter to `enabled` to enable use of the WAL scanner and permit taking incremental backups when the `BACKUP` subcommand is invoked with the `--parent` option. Set it to `disabled` (default) to disallow incremental backups and thus permit only full backups. For information about using the `BACKUP` subcommand and running the WAL scanner, please see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). | | `Description` | Optional | Specify the description that will be used to identify the database server. | For information regarding the following parameters, see [configuring the BART host](#configuring-the-bart-host). @@ -501,7 +497,7 @@ To enable WAL archiving: - In the `postgresql.conf` file, set the `wal_level` to `replica` or higher, `archive_mode` to `on`, and `max_wal_senders` to a value high enough to leave at least one session available for the backup. If the `xlog_method=stream` parameter setting is to be used by this database server as determined in the BART configuration file, the `max_wal_senders` setting must account for an additional session for the transaction log streaming (that is, the setting must be a minimum of `2`). See [Configuring the BART host](#configuring-the-bart-host) for information on the `xlog_method` parameter. -- Configure the Postgres `archive_command` parameter automatically with the `INIT` subcommand and restart the database server when you are ready to initiate WAL archiving. The `INIT` subcommand invokes the Postgres `ALTER SYSTEM` command to set the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME data directory`. For additional information about the `INIT` subcommand, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +- Configure the Postgres `archive_command` parameter automatically with the `INIT` subcommand and restart the database server when you are ready to initiate WAL archiving. The `INIT` subcommand invokes the Postgres `ALTER SYSTEM` command to set the Postgres `archive_command` configuration parameter in the `postgresql.auto.conf` file located in the managed database server’s `POSTGRES_INSTALL_HOME data directory`. For additional information about the `INIT` subcommand, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The archive command string that the `INIT` subcommand generates into the `postgresql.auto.conf` file is determined by the parameter setting of the BART `archive_command` parameter in the server section of the BART configuration file. If the BART `archive_command` parameter is not set in the server section for a given database server, the command string that is configured uses the following default format: @@ -640,4 +636,4 @@ The `CHECK-CONFIG` subcommand confirms the following: - Archiving of WAL files to the `archive_path` is in process. - The WAL scanner program is running. -After configuring the BART host and the database server(s), you can start using BART. For information about using BART, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +After configuring the BART host and the database server(s), you can start using BART. For information about using BART, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). diff --git a/product_docs/docs/bart/2.6/bart_inst/04_upgrading_bart.mdx b/product_docs/docs/bart/2.6/bart_inst/04_upgrading_bart.mdx index 7bd85d1d19c..a526f95dc3f 100644 --- a/product_docs/docs/bart/2.6/bart_inst/04_upgrading_bart.mdx +++ b/product_docs/docs/bart/2.6/bart_inst/04_upgrading_bart.mdx @@ -1,9 +1,5 @@ --- title: "Upgrading BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/upgrading_bart.html" --- @@ -61,12 +57,12 @@ bart-scanner STOP **Step 3:** Repeat the process described in this section to upgrade to the latest BART version on each remote hosts where an incremental backup will be restored. -For additional information about restoration of incremental backups on remote hosts, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +For additional information about restoration of incremental backups on remote hosts, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). **Step 4:** If the `bart --version` command returns an error stating the `PATH` is not available after switching from `root` user to another BART user account, adjust the setting of the `PATH` environment variable to include the location of the BART x.y.z (x denotes the major version of BART, and y and z denotes the minor version) executable (the `bin` subdirectory) in the `~/.bashrc` or `~/.bash_profile` files of the following user accounts: - The BART user account on the BART host. -- The remote user account on the remote host to which incremental backups are to be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +- The remote user account on the remote host to which incremental backups are to be restored. For details, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The `PATH` setting should be the same as set for BART x.y.z since all versions use `/usr/edb/bart/bin`. diff --git a/product_docs/docs/bart/2.6/bart_inst/05_uninstalling_bart.mdx b/product_docs/docs/bart/2.6/bart_inst/05_uninstalling_bart.mdx index 78cb55f2aa3..2d1177e3bd4 100644 --- a/product_docs/docs/bart/2.6/bart_inst/05_uninstalling_bart.mdx +++ b/product_docs/docs/bart/2.6/bart_inst/05_uninstalling_bart.mdx @@ -1,9 +1,5 @@ --- title: "Uninstalling BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/uninstalling_bart.html" --- @@ -31,7 +27,7 @@ Uninstalling BART does not delete the backup files and archived WAL files that r - `rm –rf /opt/backup` - BART `DELETE` subcommand -For information about the BART `DELETE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). +For information about the BART `DELETE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). ## Uninstalling BART on an SLES 12 Host diff --git a/product_docs/docs/bart/2.6/bart_inst/index.mdx b/product_docs/docs/bart/2.6/bart_inst/index.mdx index 3f2963a4f4d..6595b356078 100644 --- a/product_docs/docs/bart/2.6/bart_inst/index.mdx +++ b/product_docs/docs/bart/2.6/bart_inst/index.mdx @@ -1,14 +1,6 @@ --- navTitle: Installation Guide title: "EDB Postgres Backup and Recovery Installation Guide" -legacyRedirects: - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/requirements_overview.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/installation-getting-started/installation-upgrade-guide/2.6.1/index.html" --- This guide provides information about how to install and configure the EDB Backup and Recovery Tool (BART) 2.6. @@ -22,7 +14,7 @@ This guide provides information about how to install and configure the EDB Backu - To view a complete list of supported platforms, visit the [EDB website.](https://www.enterprisedb.com/services-support/edb-supported-products-and-platforms) !!! Note - BART 2.6 does not support CentOS/RHEL/OEL 6.x platforms. It is strongly recommended that EDB products running on these platforms be migrated to a supported platform. + BART 2.6 is no longer supported on CentOS/RHEL/OEL 6.x platforms. It is strongly recommended that EDB products running on these platforms be migrated to a supported platform. - BART supports the following database versions: diff --git a/product_docs/docs/bart/2.6/bart_qs_7/index.mdx b/product_docs/docs/bart/2.6/bart_qs_7/index.mdx index 9f98f080e56..45d6840101e 100644 --- a/product_docs/docs/bart/2.6/bart_qs_7/index.mdx +++ b/product_docs/docs/bart/2.6/bart_qs_7/index.mdx @@ -1,15 +1,10 @@ --- title: "Quick Start Guide for RHEL/CentOS 7" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-7/2.6.1/index.html" --- This tutorial demonstrates using `yum` to [install](#installing) and [configure](../bart_qs_8/#configuring) Backup and Recovery Tool (BART) 2.6 on a CentOS 7 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures, and has administrative privileges on the host. -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/2.6/bart_inst/). +For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). - BART is tested with the following database versions: @@ -113,7 +108,7 @@ Before configuring BART, establish the BART user account (the operating system u cp bart.cfg.sample bart.cfg ``` -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/2.6/bart_inst/). +3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. @@ -188,7 +183,7 @@ The following table describes only mandatory parameters: bart CHECK-CONFIG [ -s ] ``` - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide*, available at the [EDB website](/bart/2.6/bart_user/). + BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide*, available at the [EDB website](/bart/latest/bart_user/). @@ -254,7 +249,7 @@ The following example enables SSH/SCP access on a CentOS 7.x host; similar (plat If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/2.6/bart_ref/). +An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. diff --git a/product_docs/docs/bart/2.6/bart_qs_8/index.mdx b/product_docs/docs/bart/2.6/bart_qs_8/index.mdx index 42bfc8daf38..f064612cc51 100644 --- a/product_docs/docs/bart/2.6/bart_qs_8/index.mdx +++ b/product_docs/docs/bart/2.6/bart_qs_8/index.mdx @@ -1,15 +1,10 @@ --- title: "Quick Start Guide for RHEL/CentOS 8" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/quick-start/quick-start-guide-for-rhelcentos-8/2.6.1/index.html" --- This tutorial demonstrates using the `dnf` command to install and configure the EDB Backup and Recovery Tool (BART) 2.6 on a CentOS 8 host with minimal configuration settings.  The tutorial assumes that the user has some knowledge of installation and system administration procedures and has administrative privileges on the host. -For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/). +For detailed information about BART installation and configuration, see the *BART Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). - BART is tested with the following database versions: @@ -109,7 +104,7 @@ Before configuring BART, establish the BART user account (the operating system u cp bart.cfg.sample bart.cfg ``` -3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/2.6/bart_inst/). +3. Open the BART configuration file (`bart.cfg`) using an editor of your choice and scroll through the BART configuration file to edit the file as required; sample settings are included for your reference. You must add the mandatory parameters to the `[BART]` and `[ServerName]` sections. Default values may be used for optional parameters. For detailed information about parameter settings, see the *BART Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). Parameters set in the `[BART]` section are applicable to all BART managed database servers, while parameters set in the `[ServerName]` section are applicable only to the specific server; `[ServerName]` settings override `[BART]` section settings. @@ -184,7 +179,7 @@ The following table describes only mandatory parameters: bart CHECK-CONFIG [ -s ] ``` - BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide* available at the [EDB website](/bart/2.6/bart_user/). + BART is now configured successfully. For detailed information about using BART, see the *EDB Backup and Recovery Tool User Guide* available at the [EDB website](/bart/latest/bart_user/). @@ -250,7 +245,7 @@ The following example enables SSH/SCP access on a CentOS 7.x host; similar (plat If backups are to be taken from a given database server host, but restored to a different database server host, the passwordless SSH/SCP connections must be configured from the BART host to the database server host from which the backup is to be taken as well as from the BART host to the database server host to which the backup is to be restored. -An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/2.6/bart_ref/). +An example of how to create a passwordless connection is documented in the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/). Even when the Advanced Server database is on the same host as BART, and the Advanced Server database cluster owner is also the BART user account, a passwordless SSH/SCP connection must be established from the same user account to itself. diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/01_backup.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/01_backup.mdx index bbebab0060e..a630d1bacd0 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/01_backup.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/01_backup.mdx @@ -1,9 +1,5 @@ --- title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/backup.html" --- Use the `BACKUP` subcommand to create a full or incremental backup. @@ -36,7 +32,7 @@ bart BACKUP –s [-Fp] [ { --checksum-algorithm } ] ``` -Before performing an incremental backup, you must take a full backup. For more details about incremental backup, refer to *Block-Level Incremental Backup* in the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). +Before performing an incremental backup, you must take a full backup. For more details about incremental backup, refer to *Block-Level Incremental Backup* in the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). The following table describes the `BACKUP` options: @@ -46,8 +42,8 @@ The following table describes the `BACKUP` options: | `-F { p \| t }`
`--format { p \| t }` | Use this option to specify the backup file format.
Specify `p` option to take backup in plain text format and specify `t` option to take backup in tar format. If the `p` or `t` option is omitted, the default is tar format.
Use `p` option with the `BACKUP` subcommand when streaming is used as a backup method.
An incremental backup can only be taken in plain text format (`p`). | | `-z`
`(--gzip)` | This option is applicable only for full backup and `tar` format. Use this option to enable gzip compression of tar files using the default compression level (typically 6). | | `-c `
`--compress-level ` | This is applicable only for full backup and tar format. Use this option to specify the gzip compression level on the tar file output. `` is a digit from 1 through 9, with 9 being the best compression. | -| `--backup-name ` | Use this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
For detailed information about this parameter, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/).
If the option `--backup-name` is not specified and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to specify the number of worker threads to run in parallel to copy blocks for a backup.
For detailed information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/). | +| `--backup-name ` | Use this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
For detailed information about this parameter, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/).
If the option `--backup-name` is not specified and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | +| `--thread-count ` | Use this option to specify the number of worker threads to run in parallel to copy blocks for a backup.
For detailed information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | | `--with-pg_basebackup` | This is applicable only for full backup. Use this option to specify the use of `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the `--with-pg_basebackup` option is specified with the `BACKUP` subcommand. | | `--no-pg_basebackup` | This is applicable only for full backup. Use this option to specify that `pg_basebackup` is not to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the `--no-pg_basebackup` option is specified with the `BACKUP` subcommand. | | `--parent { \| }` | Use this option to take an incremental backup. The parent backup is a backup taken prior to the incremental backup; it can be either a full backup or an incremental backup. `` is the backup identifier of a parent backup and `` is the user-defined alphanumeric name of a parent backup. | diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/02_check_config.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/02_check_config.mdx index 69c51d5249e..0798998d12f 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/02_check_config.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/02_check_config.mdx @@ -1,9 +1,5 @@ --- title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/check_config.html" --- The `CHECK-CONFIG` subcommand checks the global parameter settings as well as the database server configuration in the BART configuration file. diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/03_delete.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/03_delete.mdx index f440e10a66b..155b9d77baa 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/03_delete.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/03_delete.mdx @@ -1,9 +1,5 @@ --- title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/delete.html" --- The `DELETE` subcommand removes the subdirectory and data files from the BART backup catalog for the specified backups along with archived WAL files. @@ -18,7 +14,7 @@ bart DELETE –s Note that when invoking the `DELETE` subcommand, you must specify a database server. -For database servers under a retention policy, there are conditions where certain backups may not be deleted. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +For database servers under a retention policy, there are conditions where certain backups may not be deleted. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The following table describes the `DELETE` options: diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/04_init.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/04_init.mdx index 9f8b020ac03..7070316c8e8 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/04_init.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/04_init.mdx @@ -1,9 +1,5 @@ --- title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/init.html" --- diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/05_manage.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/05_manage.mdx index 79716d976ee..cdf94ffdf3d 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/05_manage.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/05_manage.mdx @@ -1,9 +1,5 @@ --- title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/manage.html" --- The `MANAGE` subcommand can be invoked to: @@ -21,7 +17,7 @@ bart MANAGE [ –s { | all} ] [ -n ] ``` -To view detailed information about the `MANAGE` subcommand and retention policy management, see *the EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). For information about setting the `wal_compression` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/). +To view detailed information about the `MANAGE` subcommand and retention policy management, see *the EDB Backup and Recovery User Guide*. For information about setting the `wal_compression` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide*. These guides are available at the [EDB website](/bart/latest/bart_user/). The following table describes the `MANAGE` options: diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/06_restore.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/06_restore.mdx index 57f969b5b72..16fdc1702eb 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/06_restore.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/06_restore.mdx @@ -1,9 +1,5 @@ --- title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/restore.html" --- The `RESTORE` subcommand restores a backup and its archived WAL files for the designated database server to the specified directory location. @@ -21,11 +17,11 @@ bart RESTORE –s -p [ --disable-checksum ] ``` -To view detailed information about the `RESTORE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). +To view detailed information about the `RESTORE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). If the backup is restored to a different database cluster directory than where the original database cluster resided, then some operations dependent upon the database cluster location may fail. This happens if the supporting service scripts are not updated to reflect the new directory location of restored backup. -For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide. +For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). The following table describes the `RESTORE` options: @@ -34,12 +30,12 @@ The following table describes the `RESTORE` options: | `-s `
`--server ` | `` is the name of the database server to be restored. | | `-p --restore-path `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | | `-i { \| }`

`--backupid { \| }` | `backup_id` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the latest backup is restored by default. | -| `-r `

`--remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored.
`` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `remote_host` parameter for this database server is not set in the BART configuration file.
For information about the `remote_host` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/). | +| `-r `

`--remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored.
`` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `remote_host` parameter for this database server is not set in the BART configuration file.
For information about the `remote_host` parameter, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). | | `-w `
`--workers ` | `` is the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location. If the `-w` option is omitted, the default is `1` worker process.
For example, if four worker processes are specified, four receiver processes on the restore host and four streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process.
When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. | | `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | | `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. | | `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. | -| `-c`

`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
The `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, then the `restore_command` in the `postgresql.conf` retrieves the archived WAL files directly from the BART backup catalog.
For information about the `copy_wals_during_restore` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/). | +| `-c`

`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
The `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, then the `restore_command` in the `postgresql.conf` retrieves the archived WAL files directly from the BART backup catalog.
For information about the `copy_wals_during_restore` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). | | `--disable-checksum` | While restoring a backup, specify this option to skip verifying the MD5 or SHA256 checksum files.
If you set the `--checksum-algorithm=NONE` option with the BART scanner or while taking a backup, you also need to specify the `--disable checksum` option while restoring an incremental backup. | **Examples** diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx index 8ada69b5622..6c994055f14 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/07_show_servers.mdx @@ -1,9 +1,5 @@ --- title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_servers.html" --- The `SHOW-SERVERS` subcommand displays information for the managed database servers listed in the BART configuration file. diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx index 03b7727add3..760bfc211b0 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/08_show_backups.mdx @@ -1,9 +1,5 @@ --- title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/show_backups.html" --- The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx index 973ae05dc7d..914c05321c2 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/09_verify_chksum.mdx @@ -1,9 +1,5 @@ --- title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/verify_chksum.html" --- The `VERIFY-CHKSUM` subcommand verifies the MD5 checksums of the full backups and any user-defined tablespaces for the specified database server or for all database servers. The checksum is verified by comparing the current checksum of the backup against the checksum when the backup was taken. diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx index 816b1ba397d..f3d95557cd5 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/10_running_the_bart_wal_scanner.mdx @@ -1,14 +1,10 @@ --- title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/running_the_bart_wal_scanner.html" --- The BART WAL scanner is used to process each WAL file to find and record modified blocks in a corresponding MBM file. As a BART account user, use the BART WAL scanner to invoke the `bart-scanner` program located in the `/bin` directory. -For detailed information about the WAL scanner and its usage, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +For detailed information about the WAL scanner and its usage, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). **Syntax:** diff --git a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/index.mdx b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/index.mdx index 20c71192ef2..37e753f9f6b 100644 --- a/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/index.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/01_bart_subcommands_examples/index.mdx @@ -1,9 +1,5 @@ --- title: "BART Subcommand Syntax and Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/bart_subcommands_examples.html" --- diff --git a/product_docs/docs/bart/2.6/bart_ref/02_additional_examples.mdx b/product_docs/docs/bart/2.6/bart_ref/02_additional_examples.mdx index 48fac9053fa..69259bd837f 100644 --- a/product_docs/docs/bart/2.6/bart_ref/02_additional_examples.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/02_additional_examples.mdx @@ -1,9 +1,5 @@ --- title: "Additional Examples" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/additional_examples.html" --- @@ -17,7 +13,7 @@ This section lists examples of the following BART operations. ## Restoring a Database Cluster with Tablespaces -The following code sample illustrates taking a backup and restoring a database cluster on a remote host containing tablespaces. For detailed information regarding using tablespaces, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +The following code sample illustrates taking a backup and restoring a database cluster on a remote host containing tablespaces. For detailed information regarding using tablespaces, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). On an Advanced Server database running on a remote host, the following tablespaces are created for use by two tables: @@ -264,7 +260,7 @@ tblspc_2 | enterprisedb | /opt/restore_tblspc_2 ## Restoring an Incremental Backup -Restoring an incremental backup may require additional setup steps depending upon the host on which the incremental backup is to be restored. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +Restoring an incremental backup may require additional setup steps depending upon the host on which the incremental backup is to be restored. For more information, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). This section provides an example of creating backup chains and then restoring an incremental backup. @@ -453,7 +449,7 @@ Restoring incremental backup `incr_1-b` as shown by the preceding example result ## Managing Backups -This section illustrates evaluating, marking, and deleting backups using the `MANAGE` subcommand using a redundancy retention policy and a recovery window retention policy. For detailed information about the `MANAGE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). +This section illustrates evaluating, marking, and deleting backups using the `MANAGE` subcommand using a redundancy retention policy and a recovery window retention policy. For detailed information about the `MANAGE` subcommand, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). @@ -1065,7 +1061,7 @@ dev 1428502171990 2015-04-08 10:09:34 EDT 5.65 MB 80.00 MB ## Managing Incremental Backups -This section illustrates evaluating, marking, and deleting incremental backups using the `MANAGE` and `DELETE` subcommands utilizing redundancy retention policy and recovery window retention policy. For detailed information about the `MANAGE` and `DELETE` subcommands, as well as the redundancy retention and recovery window retention policy, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). +This section illustrates evaluating, marking, and deleting incremental backups using the `MANAGE` and `DELETE` subcommands utilizing redundancy retention policy and recovery window retention policy. For detailed information about the `MANAGE` and `DELETE` subcommands, as well as the redundancy retention and recovery window retention policy, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/latest/bart_user/). - [Using a Redundancy Retention Policy](#redundancy_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 3 backup redundancy retention policy is in effect. - [Using a Recovery Window Retention Policy](#recovery_window_retention_policy) provides an example of using the `MANAGE` and `DELETE` subcommands when a 1-day recovery window retention policy is in effect. diff --git a/product_docs/docs/bart/2.6/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx b/product_docs/docs/bart/2.6/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx index f8034584c1d..cfc972aea30 100644 --- a/product_docs/docs/bart/2.6/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/03_sample_bart_system_with_local_and_remote_database_servers.mdx @@ -1,16 +1,12 @@ --- title: "Sample BART System with Local and Remote Database Servers" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/sample_bart_system_with_local_and_remote_database_servers.html" --- This section describes a sample BART managed backup and recovery system consisting of both local and remote database servers. The complete steps to configure and operate the system are provided. -For detailed information about configuring a BART system, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/). For detailed information about the operational procedures and BART subcommands, see the *EDB Backup and Recovery User Guide* available at the [EDB website](/bart/2.6/bart_user/). +For detailed information about configuring a BART system, see the *EDB Backup and Recovery Installation and Upgrade Guide*. For detailed information about the operational procedures and BART subcommands, see the *EDB Backup and Recovery User Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). The environment for this sample system is as follows: @@ -848,7 +844,7 @@ drwx------ 2 enterprisedb enterprisedb 4096 Apr 23 15:36 backup Use the BART `INIT` subcommand to complete the directory structure and set the Postgres `archive_command` configuration parameter. -Before invoking any BART subcommands, set up a profile under the BART user account’s home directory to set the `LD_LIBRARY_PATH` and `PATH` environment variables. For more information regarding setting this variable, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/). +Before invoking any BART subcommands, set up a profile under the BART user account’s home directory to set the `LD_LIBRARY_PATH` and `PATH` environment variables. For more information regarding setting this variable, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). The `-o` option is specified with the `INIT` subcommand to force the setting of the Postgres `archive_command` configuration parameter when `archive_mode` is `off` or if the Postgres `archive_command` parameter is already set and needs to be overridden. diff --git a/product_docs/docs/bart/2.6/bart_ref/index.mdx b/product_docs/docs/bart/2.6/bart_ref/index.mdx index 1af3ceb2813..2441db56549 100644 --- a/product_docs/docs/bart/2.6/bart_ref/index.mdx +++ b/product_docs/docs/bart/2.6/bart_ref/index.mdx @@ -1,12 +1,6 @@ --- navTitle: Reference Guide title: "EDB Postgres Backup and Recovery Reference Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/reference/reference-guide/2.6.1/index.html" --- This guide acts as a quick reference for BART subcommands and provides comprehensive examples of the following BART operations: @@ -18,7 +12,7 @@ This guide acts as a quick reference for BART subcommands and provides comprehen - Evaluating, marking, and deleting backups and incremental backups - Configuring and operating local and remote database servers -For detailed information about BART subcommands and operations, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/2.6/bart_user/). +For detailed information about BART subcommands and operations, see the EDB Backup and Recovery User Guide available at the [EDB website](/bart/latest/bart_user/). The document is organized as follows: diff --git a/product_docs/docs/bart/2.6/bart_user/01_introduction.mdx b/product_docs/docs/bart/2.6/bart_user/01_introduction.mdx index c87bc7e24e0..323bcea1cc8 100644 --- a/product_docs/docs/bart/2.6/bart_user/01_introduction.mdx +++ b/product_docs/docs/bart/2.6/bart_user/01_introduction.mdx @@ -1,9 +1,5 @@ --- title: "Introduction" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" --- The EDB Backup and Recovery Tool (BART) is an administrative utility that provides simplified backup and recovery management for multiple local or remote EDB Advanced Server and PostgreSQL database servers. @@ -26,7 +22,7 @@ This guide provides the following information about using BART: - [backup and recovery management process](03_using_bart/#using_bart). - [using tablespaces](04_using_tablespaces/#using_tablespaces). -For information about installing BART, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/). To view examples of BART operations and subcommand usage, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/). +For information about installing BART, see the *EDB Backup and Recovery Installation and Upgrade Guide*; for examples of BART operations and subcommand usage, see the *EDB Backup and Recovery Reference Guide*. These guides are available at the [EDB website](/bart/latest/bart_inst/). @@ -50,6 +46,6 @@ BART takes full backups using the `pg_basebackup` utility program under the foll - The number of thread count in effect is 1, and the `with-pg_basebackup` option is not specified with the `BACKUP` subcommand. - Database servers can only be backed up using `pg_basebackup` utility program of the same or later version than the database server version. -In the global section of the BART configuration file, the `pg_basebackup_path` parameter specifies the complete directory path to the `pg_basebackup` program. For information about the `pg_basebackup_path` parameter and the `thread_count`, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/). +In the global section of the BART configuration file, the `pg_basebackup_path` parameter specifies the complete directory path to the `pg_basebackup` program. For information about the `pg_basebackup_path` parameter and the `thread_count`, see the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/). For information about `pg_basebackup`, see the [PostgreSQL Core Documentation](https://postgresql.org/docs/current/static/app-pgbasebackup.html). diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx index d0293b345ad..f3ad3324894 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/01_incremental_backup_limitations_and_requirements.mdx @@ -1,9 +1,5 @@ --- title: "Incremental Backup Limitations and Requirements" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/incremental_backup_limitations_and_requirements.html" --- @@ -37,6 +33,6 @@ You must meet the following requirements before implementing incremental backup: - The incremental backup must be on the same timeline as the parent backup. The timeline changes after each recovery operation so an incremental backup cannot use a parent backup from an earlier timeline. -For information about configuring these requirements, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/). +For information about configuring these requirements, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). The following section provides an overview of the basic incremental backup concepts. diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx index a771eb3b4a3..e9ae357184a 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/02_concept_overview.mdx @@ -1,9 +1,5 @@ --- title: "Concept Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/concept_overview.html" --- @@ -14,7 +10,7 @@ Using incremental backups involves the following sequence of steps: The default `archive_path` is the BART backup catalog (`//archived_wals`). Using the `` parameter in the server section of the BART configuration file, you can specify the location where WAL files will be archived. - For more information about the `archive_path` parameter and configuring BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/). + For more information about the `archive_path` parameter and configuring BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). 2. Take an initial full backup with the `BACKUP` subcommand. This full backup establishes the parent of the first incremental backup. @@ -26,7 +22,7 @@ Using incremental backups involves the following sequence of steps: 5. The incremental backup process identifies which WAL files may contain changes from when the parent backup was taken to the starting point of the incremental backup. The corresponding MBM files are used to locate and copy the modified blocks to the incremental backup directory along with other database cluster directories and files. Instead of backing up all, full relation files, only the modified blocks are copied and saved. In addition, the relevant MBM files are condensed into one consolidated block map (CBM) file that is stored with the incremental backup. - Multiple block copier threads can be used to copy the modified blocks to the incremental backup directory. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for information about setting the `thread_count` parameter in the BART configuration file. See [Backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for information about using the `--thread-count` option with the `BACKUP` subcommand. + Multiple block copier threads can be used to copy the modified blocks to the incremental backup directory. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting the `thread_count` parameter in the BART configuration file. See [Backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) for information about using the `--thread-count` option with the `BACKUP` subcommand. 6. Invoke the restore process for an incremental backup using the `RESTORE` subcommand in the same manner as restoring a full backup. The `-i` option specifies the backup identifier or name of the incremental backup to restore. The restore process begins by going back through the chain of past, parent incremental backups until the initial full backup starting the chain is identified. This full backup provides the initial set of directories and files to be restored to the location specified with the `-p` option. Each subsequent incremental backup in the chain is then restored. Restoration of an incremental backup uses its CBM file to restore the modified blocks from the incremental backup. diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx index 9fb0f929e0f..f08fa950527 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/03_wal_scanning_preparation_for_an_incremental_backup.mdx @@ -1,9 +1,5 @@ --- title: "WAL Scanning – Preparation for an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/wal_scanning_preparation_for_an_incremental_backup.html" --- @@ -49,6 +45,6 @@ MBM files have the suffix, `.mbm`. In preparation for any incremental backup, the WAL files should be scanned as soon as they are copied to the `archive_path`. Thus, the WAL scanner should be running as soon as the WAL files from the database cluster are archived to the `archive_path`. If the `archive_path` contains WAL files that have not yet been scanned, starting the WAL scanner begins scanning these files. If WAL file fails to be scanned (resulting in a missing MBM file), you can use the WAL scanner to specify an individual WAL file. -Under certain conditions such as when the Network File System (NFS) is used to copy WAL files to the `archive_path`, the WAL files may have been missed by the WAL scanner program for scanning and creation of MBM files. Use the `scan_interval` parameter in the BART configuration file to initiate force scanning of WAL files in the `archive_path` to ensure MBM files are generated. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for more information about the `scan_interval` parameter. +Under certain conditions such as when the Network File System (NFS) is used to copy WAL files to the `archive_path`, the WAL files may have been missed by the WAL scanner program for scanning and creation of MBM files. Use the `scan_interval` parameter in the BART configuration file to initiate force scanning of WAL files in the `archive_path` to ensure MBM files are generated. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about the `scan_interval` parameter. See [Running the BART WAL Scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) for information about using the WAL scanner. diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx index 8198f0f6400..2b4e5e028cf 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/04_performing_an_incremental_backup.mdx @@ -1,9 +1,5 @@ --- title: "Performing an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_an_incremental_backup.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx index edd998ec999..986f4059ee3 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup.mdx @@ -1,9 +1,5 @@ --- title: "Restoring an Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restoring_an_incremental_backup.html" --- @@ -40,9 +36,9 @@ No editing is needed in the `bart.cfg` file installed on the remote host. **Step 2:** Determine the Linux operating system user account on the remote host to be used as the remote user. This user is specified by the `remote_host` parameter in the BART configuration file or by the `-r` option when using the `RESTORE` subcommand to restore the incremental backup. The remote user must be the owner of the directory where the incremental backup is to be restored on the remote host. By default, the user account is `enterprisedb` for Advanced Server or `postgres` for PostgreSQL. -**Step 3:** Ensure a passwordless SSH/SCP connection is established from the BART user on the BART host to the remote user on the remote host. For information about creating a passwordless SSH/SCP connection, see the *EDB Backup and Recovery Installation and Upgrade Guide*, available at the [EDB website](/bart/2.6/bart_inst/). +**Step 3:** Ensure a passwordless SSH/SCP connection is established from the BART user on the BART host to the remote user on the remote host. For information about creating a passwordless SSH/SCP connection, see the *EDB Backup and Recovery Installation and Upgrade Guide*, available at the [EDB website](/bart/latest/bart_inst/). -When restoring an incremental backup, specify the backup identifier or name of the incremental backup that will be restored. See the [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) documentation for more details. To view an example of restoring an incremental backup, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/). +When restoring an incremental backup, specify the backup identifier or name of the incremental backup that will be restored. See the [RESTORE](../../03_using_bart/03_basic_bart_subcommand_usage/08_restore/#restore) documentation for more details. To view an example of restoring an incremental backup, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). !!! Note If you set the [BART scanner](../../03_using_bart/04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or [backup](../../03_using_bart/03_basic_bart_subcommand_usage/03_backup/#backup) with the `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring an incremental backup. diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/index.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/index.mdx index 3e65e3b0056..9efd8b6c43f 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/index.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/01_block-level_incremental_backup/index.mdx @@ -1,9 +1,5 @@ --- title: "Block-Level Incremental Backup" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/block-level_incremental_backup.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/02_creating_a_backup_chain.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/02_creating_a_backup_chain.mdx index 5e2f2f94b3f..83421416e0c 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/02_creating_a_backup_chain.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/02_creating_a_backup_chain.mdx @@ -1,9 +1,5 @@ --- title: "Creating a Backup Chain" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/creating_a_backup_chain.html" --- @@ -19,4 +15,4 @@ Since restoration of an incremental backup is dependent upon first restoring the The actions of retention policy management are applied to the full backup and all of its successive incremental backups within the chain in an identical manner as if they were one backup. Thus, use of retention policy management does not result in the breakup of a backup chain. -See the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/2.6/bart_ref/) for examples of creating a backup chain and restoring an incremental backup. +See the *EDB Backup and Recovery Reference Guide*, available at the [EDB website](/bart/latest/bart_ref/) for examples of creating a backup chain and restoring an incremental backup. diff --git a/product_docs/docs/bart/2.6/bart_user/02_overview/index.mdx b/product_docs/docs/bart/2.6/bart_user/02_overview/index.mdx index ae510d0dac2..404599fde3c 100644 --- a/product_docs/docs/bart/2.6/bart_user/02_overview/index.mdx +++ b/product_docs/docs/bart/2.6/bart_user/02_overview/index.mdx @@ -1,9 +1,5 @@ --- title: "Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview.html" --- @@ -59,7 +55,7 @@ Other concepts and terms referred to in this document include the following: - **Secure Shell (SSH)/Secure Copy (SCP).** Linux utility programs used to log into hosts (SSH) and copy files (SCP) between hosts. A valid user account must be specified that exists on the target host and in fact is the user account under which the SSH or SCP operations occur. -For information on how all of these components are configured and used with BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/). +For information on how all of these components are configured and used with BART, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). **Supported BART Operations** diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx index 6197df8941b..ec671385681 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/01_performing_a_restore_operation.mdx @@ -1,9 +1,5 @@ --- title: "Performing a Restore Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/performing_a_restore_operation.html" --- @@ -18,7 +14,7 @@ The following steps describe the process of restoring a backup: If you want to restore to a new, empty directory, create the directory on which you want to restore the backed up database cluster. Ensure the data directory can be written to by the BART user account or by the user account specified by the `remote_host` configuration parameter, or by the `--remote-host` option of the `RESTORE` subcommand (if these are to be used). -**Step 4:** Perform the same process for tablespaces as described in Step 3. The `tablespace_path` parameter in the BART configuration file must contain the tablespace directory paths to which the tablespace data files are to be restored. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for more information about this parameter. +**Step 4:** Perform the same process for tablespaces as described in Step 3. The `tablespace_path` parameter in the BART configuration file must contain the tablespace directory paths to which the tablespace data files are to be restored. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about this parameter. **Step 5:** Identify the backup to use for the restore operation and obtain the backup ID or backup name. @@ -50,11 +46,11 @@ All files and directories must be owned by the user account that you intend to u **Step 11:** Start the database server to initiate recovery. After completion, check the database server log file to ensure the recovery was successful. -If the backup is restored to a different location than where the original database cluster resided, operations dependent upon the database cluster location may fail if supporting service scripts are not updated to reflect the location where the backup has been restored. For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide. +If the backup is restored to a different location than where the original database cluster resided, operations dependent upon the database cluster location may fail if supporting service scripts are not updated to reflect the location where the backup has been restored. For information about the use and modification of service scripts, see the EDB Advanced Server Installation Guide available at the [EDB website](/epas/latest/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the BART `Restore` subcommand. -An example of a restore operation is documented in the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/2.6/bart_ref/). +An example of a restore operation is documented in the EDB Backup and Recovery Reference Guide available at the [EDB website](/bart/latest/bart_ref/). !!! Note If you set the [backup](../03_basic_bart_subcommand_usage/03_backup/#backup) `--checksum-algorithm=NONE` option, then you must specify the `--disable checksum` option while restoring a backup. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx index 09a45311364..c0fa179edf4 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/02_point_in_time_recovery_operation.mdx @@ -1,9 +1,5 @@ --- title: "Point-In-Time Recovery Operation" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/point_in_time_recovery_operation.html" --- @@ -48,4 +44,4 @@ The following steps outline how to perform a point-in-time recovery operation fo 9. Start the database server, which will then perform the point-in-time recovery operation if recovery settings are saved in the `postgresql.auto.conf` file. -For a detailed description of the `RESTORE` subcommand, see [Basic BART Subcommand Usage](../03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage). An example of a Point-in-Time Recovery operation is documented in the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the `Restore` subcommand. +For a detailed description of the `RESTORE` subcommand, see [Basic BART Subcommand Usage](../03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage). An example of a Point-in-Time Recovery operation is documented in the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). See [Restore](../03_basic_bart_subcommand_usage/08_restore/#restore) for more information about using the `Restore` subcommand. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/index.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/index.mdx index 4cb9c779397..caddcc9f4c3 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/index.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/01_bart_management_overview/index.mdx @@ -1,9 +1,5 @@ --- title: "BART Management Overview" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/bart_management_overview.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx index 7169d6f7bb6..7c793f38b85 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/01_overview_managing_backups_using_a_retention_policy.mdx @@ -1,9 +1,5 @@ --- title: "Overview - Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/overview_managing_backups_using_a_retention_policy.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx index 047552d0a9e..d924099540d 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/02_marking_the_backup_status.mdx @@ -1,9 +1,5 @@ --- title: "Marking the Backup Status" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/marking_the_backup_status.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx index d4fd91675c9..75b1de29b23 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/03_setting_the_retention_policy.mdx @@ -1,14 +1,10 @@ --- title: "Setting the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/setting_the_retention_policy.html" --- -The retention policy is determined by the `retention_policy` parameter in the BART configuration file. It can be applied globally to all servers, but each server can override the global retention policy with its own. For information about creating a global retention policy and an individual database server retention policy, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/). +The retention policy is determined by the `retention_policy` parameter in the BART configuration file. It can be applied globally to all servers, but each server can override the global retention policy with its own. For information about creating a global retention policy and an individual database server retention policy, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/). There are two types of retention policies - redundancy retention policy and the recovery window retention policy as described in the following sections. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx index f0750c1565e..5b9f0f62772 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/04_managing_the_backups_based_on_the_retention_policy.mdx @@ -1,9 +1,5 @@ --- title: "Managing the Backups Based on the Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_the_backups_based_on_the_retention_policy.html" --- @@ -144,4 +140,4 @@ When the `MANAGE` subcommand is invoked, BART evaluates active backups: !!! Note The status of backups currently marked as `obsolete` or `keep` is not changed. To re-evaluate such backups and then classify them, their status must first be reset to `active` with the `MANAGE -c nokeep` option. See [Marking the Backup Status](02_marking_the_backup_status/#marking_the_backup_status) for more information. -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/) to review examples of how to evaluate, mark, and delete backups using a redundancy retention policy and recovery window retention policy, as well as examples of `MANAGE` subcommand. +See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) to review examples of how to evaluate, mark, and delete backups using a redundancy retention policy and recovery window retention policy, as well as examples of `MANAGE` subcommand. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx index 3cf29e34f3a..2200a012265 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/05_managing_incremental_backups.mdx @@ -1,9 +1,5 @@ --- title: "Managing Incremental Backups" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_incremental_backups.html" --- @@ -37,7 +33,7 @@ When a [redundancy retention policy](03_setting_the_retention_policy/#redundancy When determining the number of backups that exceeds the number specified by the `retention_policy` parameter, only full backups are counted for the comparison. Incremental backups are not included in the count for the comparison against the `retention_policy` parameter setting. -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a redundancy retention policy is in effect. +See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a redundancy retention policy is in effect. ## Using a Recovery Window Retention Policy with Incremental Backups @@ -48,4 +44,4 @@ If the `MANAGE` command is invoked when BART is configured to use a [recovery wi The status of an incremental backup is changed to `obsolete` regardless of whether or not the date/time of when the incremental backup was taken still lies within the recovery window. -See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a recovery window retention policy is in effect. +See the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/) for examples demonstrating use of the `MANAGE` and `DELETE` subcommands when a recovery window retention policy is in effect. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx index aff92bbd6a5..9f458b830ca 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/02_managing_backups_using_a_retention_policy/index.mdx @@ -1,9 +1,5 @@ --- title: "Managing Backups Using a Retention Policy" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/managing_backups_using_a_retention_policy.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx index f12dd038edd..2e639b45760 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/01_check_config.mdx @@ -1,9 +1,5 @@ --- title: "CHECK-CONFIG" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/check_config.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx index d8cdeed8126..7f9922f17f0 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/02_init.mdx @@ -1,9 +1,5 @@ --- title: "INIT" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/init.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx index fb59ed1f30e..5e599b62946 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/03_backup.mdx @@ -1,9 +1,5 @@ --- title: "BACKUP" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/backup.html" --- @@ -51,7 +47,7 @@ bart BACKUP –s { | all } [ -F p] - In the `postgresql.conf` file, ensure the `wal_keep_segments` configuration parameter is set to a sufficiently large value. A low setting of the `wal_keep_segments` configuration parameter may result in the deletion of some WAL files before the BART `BACKUP` subcommand saves them to the `archive_path`. For information about the `wal_keep_segments` parameter, see the [PostgreSQL Core Documentation](https://www.postgresql.org/docs/current/static/runtime-config-replication.html). -- In the BART configuration file, setting `xlog_method=stream` will instruct the server to stream the transaction log in parallel with creation of the backup for a specific database server; otherwise the transaction log files are collected upon completion of the backup. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for details about database server setting. +- In the BART configuration file, setting `xlog_method=stream` will instruct the server to stream the transaction log in parallel with creation of the backup for a specific database server; otherwise the transaction log files are collected upon completion of the backup. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details about database server setting. !!! Note If the transaction log streaming method is used, the `-Fp` option for a plain text backup format must be specified with the `BACKUP` subcommand. @@ -75,7 +71,7 @@ Specify the following options as required. If you do not specify any of the foll | `-c `
`--compress-level ` | This is applicable only for full backup. Specify this option to use the gzip compression level on the tar file output. `compression_level` is a digit from 1 through 9, with 9 being the best compression. This option is applicable only for the tar format. | | `--parent { backup_id \| backup_name }` | Specify this option to take an incremental backup. `` is the backup identifier of a parent backup. `` is the user-defined alphanumeric name of a parent backup.
The parent is a backup taken prior to the incremental backup. The parent backup can be either a full backup or an incremental backup.
The option `–Fp` must be specified since an incremental backup can only be taken in plain text format.
An incremental backup cannot be taken on a standby database server. See [Block-Level Incremental Backup](../../02_overview/01_block-level_incremental_backup/#block-level_incremental_backup) for additional information on incremental backups. | | `--backup-name ` | Specify this option to assign a user-defined, alphanumeric friendly name to the backup. The maximum permitted length of backup name is 49 characters.
The backup name may include the following variables to be substituted by the timestamp values when the backup is taken: 1) `%year` – 4-digit year, 2) `%month` – 2-digit month, 3) `%day` – 2-digit day, 4) `%hour` 2-digit hour, 5) `%minute` – 2-digit minute, and 6) `%second` – 2-digit second.
To include the percent sign (`%`) as a character in the backup name, specify `%%` in the alphanumeric string.
If the backup name contains space characters (i.e. more than one word) or when referenced with the option `-i` by other subcommands (such as `restore`), enclose the string in single quotes or double quotes. See [backup name examples](#backup_name_examples).
If the `--backup-name` option is not specified, and the `backup_name` parameter is not set for this database server in the BART configuration file, then the backup can only be referenced in other BART subcommands by the BART assigned backup identifier. | -| `--thread-count ` | Use this option to use the number of worker threads to run in parallel to copy blocks for a backup.
If the option `--thread-count` is omitted, then the `thread_count` parameter in the BART configuration file applicable to this database server is used.
If the option `--thread-count` is not enabled for this database server, then the `thread_count` setting in the global section of the BART configuration file is used.
If the option `--thread-count` is not set in the global section as well, the default number of threads is 1.
If parallel backup is run with N number of worker threads, then it will initiate N+ 1 concurrent connections with the server.
Thread count will not be effective if backup is taken on a standby server.
For more information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/2.6/bart_inst/) | +| `--thread-count ` | Use this option to use the number of worker threads to run in parallel to copy blocks for a backup.
If the option `--thread-count` is omitted, then the `thread_count` parameter in the BART configuration file applicable to this database server is used.
If the option `--thread-count` is not enabled for this database server, then the `thread_count` setting in the global section of the BART configuration file is used.
If the option `--thread-count` is not set in the global section as well, the default number of threads is 1.
If parallel backup is run with N number of worker threads, then it will initiate N+ 1 concurrent connections with the server.
Thread count will not be effective if backup is taken on a standby server.
For more information about the `--thread-count` parameter, see the EDB Backup and Recovery Installation and Upgrade Guide available at the [EDB website](/bart/latest/bart_inst/) | | `--with-pg_basebackup` | This is applicable only for full backup. Specify this option to use `pg_basebackup` to take a full backup. The number of thread counts in effect is ignored as given by the `thread_count` parameter in the BART configuration file.
When taking a full backup, if the thread count in effect is greater than `1`, then the `pg_basebackup` utility is not used to take the full backup (parallel worker threads are used) unless the option `--with-pg_basebackup` is specified with the `BACKUP` subcommand. | | `--no-pg_basebackup` | This is applicable only for full backup. Specify this option if you do not want `pg_basebackup` to be used to take a full backup.
When taking a full backup, if the thread count in effect is only `1`, then the `pg_basebackup` utility is used to take the full backup unless the option `--no-pg_basebackup` is specified with the `BACKUP` subcommand. | | `--check` | This is applicable only for incremental backup. Specify this option to verify if the required MBM files are present in the `archived_wals` directory as specified in the `archive_path` parameter in the `bart.cfg` file before taking an incremental backup. The option `--parent` must be specified when the option `--check` is used. An actual incremental backup is not taken when the option `--check` is specified. | diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx index 778efd3d4d6..670ff5ab28a 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/04_show_servers.mdx @@ -1,9 +1,5 @@ --- title: "SHOW-SERVERS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_servers.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx index d006df69db1..9134ea94dbf 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/05_show_backups.mdx @@ -1,9 +1,5 @@ --- title: "SHOW-BACKUPS" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/show_backups.html" --- The `SHOW-BACKUPS` subcommand displays the backup information for the managed database servers. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx index 4ec79d52d62..fa3f5729b0c 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/06_verify_chksum.mdx @@ -1,9 +1,5 @@ --- title: "VERIFY-CHKSUM" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/verify_chksum.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx index 856566907f7..01f49008853 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/07_manage.mdx @@ -1,9 +1,5 @@ --- title: "MANAGE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/manage.html" --- @@ -12,7 +8,7 @@ The `MANAGE` subcommand can be invoked to: - Evaluate backups, mark their status, and delete obsolete backups based on the `retention_policy` parameter in the BART configuration file (See [Managing Backups Using a Retention Policy](../02_managing_backups_using_a_retention_policy/#managing_backups_using_a_retention_policy) for information about retention policy management). -- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file (See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for information about setting this parameter). +- Compress the archived WAL files based on the `wal_compression` parameter in the BART configuration file (See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about setting this parameter). **Syntax:** diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx index 969d5aa0aa7..89251a329cd 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/08_restore.mdx @@ -1,9 +1,5 @@ --- title: "RESTORE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/restore.html" --- @@ -30,7 +26,7 @@ For information about using a continuous archive backup for recovery, see the [P - For special requirements when restoring an incremental backup to a remote database server, see [Restoring an Incremental Backup on a Remote Host](../../02_overview/01_block-level_incremental_backup/05_restoring_an_incremental_backup/#restoring_an_incremental_backup_on_a_remote_host). - Check to ensure that the host where the backup is to be restored contains enough disk space for the backup and its archived WAL files. The `RESTORE` subcommand may result in an error while copying files if there is not enough disk space available. - See [Performing a Restore Operation](../01_bart_management_overview/01_performing_a_restore_operation/#performing_a_restore_operation) to view steps on how to perform a restore operation and see [Point-In-Time Recovery Operation](../01_bart_management_overview/02_point_in_time_recovery_operation/#point_in_time_recovery_operation) to view steps on how to perform a point-in-time recovery operation. -- If the backup is restored to a different database cluster directory than where the original database cluster resided, certain operations dependent upon the database cluster location may fail. This happens if their supporting service scripts are not updated to reflect the new directory location of restored backup. For information about the usage and modification of service scripts, see the *EDB Advanced Server Installation Guide*. +- If the backup is restored to a different database cluster directory than where the original database cluster resided, certain operations dependent upon the database cluster location may fail. This happens if their supporting service scripts are not updated to reflect the new directory location of restored backup. For information about the usage and modification of service scripts, see the *EDB Advanced Server Installation Guide* available at the [EDB website](/epas/latest/). The following table describes the command options: @@ -39,10 +35,10 @@ The following table describes the command options: | `-s `
`--server ` | `` is the name of the database server to be restored. | | `-p `
`--restore-path ` | `` is the directory path where the backup of the database server is to be restored. The directory must be empty and have the proper ownership and privileges assigned to it. | | `-i { \| }`

`--backupid { \| }` | `` is the backup identifier of the backup to be used for the restoration and `` is the user-defined alphanumeric name for the backup.
If the option is omitted, the default is to use the latest backup. | -| `-r or --remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored and `` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `` parameter for this database server is not set in the BART configuration file.
If the BART user account is not the same as the operating system account owning the `` directory given with the `-p` option, use the `` BART configuration parameter or the `RESTORE` subcommand `-r` option to specify the `` directory owner even when restoring to a directory on the same host as the BART host.
See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for information about the `` parameter. | +| `-r or --remote-host ` | `` is the user account on the remote database server host that accepts a passwordless SSH/SCP login connection and is the owner of the directory where the backup is to be restored and `` is the IP address of the remote host to which the backup is to be restored. This option must be specified if the `` parameter for this database server is not set in the BART configuration file.
If the BART user account is not the same as the operating system account owning the `` directory given with the `-p` option, use the `` BART configuration parameter or the `RESTORE` subcommand `-r` option to specify the `` directory owner even when restoring to a directory on the same host as the BART host.
See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `` parameter. | | `-w `
`--workers ` | `` is the specification of the number of worker processes to run in parallel to stream the modified blocks of an incremental backup to the restore location.
For example, if 4 worker processes are specified, 4 receiver processes on the restore host and 4 streamer processes on the BART host are used. The output of each streamer process is connected to the input of a receiver process. When the receiver gets to the point where it needs a modified block file, it obtains those modified blocks from its input. With this method, the modified block files are never written to the restore host disk. If the `-w` option is omitted, the default is `1` \| worker process. | | `-t `
`--target-tli ` | `` is the integer identifier of the timeline to be used for replaying the archived WAL files for point-in-time recovery. | | `-x `
`--target-xid ` | `` is the integer identifier of the transaction ID that determines the transaction up to and including, which point-in-time recovery encompasses. Include either the `-x ` or the `--target-xid ` option if point-in-time recovery is desired. | | `-g `

`--target-timestamp ` | `` is the timestamp that determines the point in time up to and including, which point-in-time recovery encompasses. Include either the `--target-timestamp ` or the `-g ` option if point-in-time recovery is desired. | -| `-c`
`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
If recovery settings are saved in the `postgresql.auto.conf` file for point-in-time recovery, the `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, the `restore_command` in the `postgresql.auto.conf` file is generated by default to retrieve the archived WAL files directly from the BART backup catalog. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for information about the `copy_wals_during_restore` parameter. | +| `-c`
`--copy-wals` | Specify this option to copy archived WAL files from the BART backup catalog to `/archived_wals` directory.
If recovery settings are saved in the `postgresql.auto.conf` file for point-in-time recovery, the `restore_command` retrieves the WAL files from `/archived_wals` for the database server archive recovery.
If the `-c` option is omitted and the `copy_wals_during_restore` parameter in the BART configuration file is not enabled in a manner applicable to this database server, the `restore_command` in the `postgresql.auto.conf` file is generated by default to retrieve the archived WAL files directly from the BART backup catalog. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for information about the `copy_wals_during_restore` parameter. | | `--disable-checksum` | While restoring a backup, specify this option to skip verifying the MD5 or SHA256 checksum files.
If you set the `--checksum-algorithm=NONE` option with the [BART scanner](../04_running_the_bart_wal_scanner/#running_the_bart_wal_scanner) or while taking a [backup](03_backup/#backup), you must specify the `--disable checksum` option while restoring an incremental backup. | diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx index 7f9836ad724..af4544164b0 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/09_delete.mdx @@ -1,9 +1,5 @@ --- title: "DELETE" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/delete.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx index b4dd726573b..81edc811403 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/03_basic_bart_subcommand_usage/index.mdx @@ -1,16 +1,12 @@ --- title: "Basic BART Subcommand Usage" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/basic_bart_subcommand_usage.html" --- This section briefly describes the BART subcommands and options. You can invoke the `bart` program (located in the `/bin` directory) with the desired options and subcommands to manage your BART installation. -To view examples of BART subcommands, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/). +To view examples of BART subcommands, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). **Syntax for invoking BART**: @@ -39,7 +35,7 @@ If execution of BART subcommands fails with the following error message, then yo **Workaround:** Set the `LD_LIBRARY_PATH` environment variable for the BART user account to include the directory containing the `libpq` library. This directory is `POSTGRES_INSTALL_HOME/lib`. -It is suggested that the `PATH` and the `LD_LIBRARY_PATH` environment variable settings be placed in the BART user account’s profile. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for details. +It is suggested that the `PATH` and the `LD_LIBRARY_PATH` environment variable settings be placed in the BART user account’s profile. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for details. In the following sections, the `help` option is omitted from the syntax diagrams for the purpose of providing readability for the subcommand options. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx index 02984b649de..03b492f30ff 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/04_running_the_bart_wal_scanner.mdx @@ -1,9 +1,5 @@ --- title: "Running the BART WAL Scanner" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/running_the_bart_wal_scanner.html" --- @@ -31,7 +27,7 @@ bart-scanner The WAL scanner processes each WAL file to find and record modified blocks in a corresponding modified block map (MBM) file. The default approach is that the WAL scanner gets notified whenever a new WAL file is added to the `archived_wals` directory specified in the `archive_path` parameter of the configuration file. It then scans the WAL file and produces the MBM file. -The default approach does not work in some cases; for example when the WAL files are shipped to the `archive_path` using the Network File System (NFS) and also in case of some specific platforms. This results in the WAL files being copied to the `archived_wals` directory, but the WAL scanner does not scan them (as WAL scanner is not aware of WAL file) and produce the MBM files. This results in the failure of an incremental backup. This can be avoided by using the timer-based WAL scanning approach, which is done by using the `scan_interval` parameter in the BART configuration file. The value for `scan_interval` is the number of seconds after which the WAL scanner will initiate force scanning of the new WAL files. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for more information about `scan_interval` parameter. +The default approach does not work in some cases; for example when the WAL files are shipped to the `archive_path` using the Network File System (NFS) and also in case of some specific platforms. This results in the WAL files being copied to the `archived_wals` directory, but the WAL scanner does not scan them (as WAL scanner is not aware of WAL file) and produce the MBM files. This results in the failure of an incremental backup. This can be avoided by using the timer-based WAL scanning approach, which is done by using the `scan_interval` parameter in the BART configuration file. The value for `scan_interval` is the number of seconds after which the WAL scanner will initiate force scanning of the new WAL files. See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for more information about `scan_interval` parameter. !!! Note After upgrading to BART 2.6, users who have set this parameter to a non-default value may see increased CPU consumption on the part of bart-scanner. If this is an issue, consider increasing the configured value of scan_interval parameter, or removing the setting if it is not required. @@ -40,7 +36,7 @@ When the `bart-scanner` program is invoked, it forks a separate process for each The WAL scanner processes can run in either the foreground or background depending upon usage of the `--daemon` option. Use the `--daemon` option to run the WAL scanner process in the background so that all output messages can be viewed in the BART log file. If the `--daemon` option is omitted, the WAL scanner process runs in the foreground and all output messages can be viewed from the terminal running the program as well as in the BART log file. -See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/2.6/bart_inst/) for additional information about WAL scanning, `allow_incremental_backups`, and `logfile` parameters. +See the *EDB Backup and Recovery Installation and Upgrade Guide* available at the [EDB website](/bart/latest/bart_inst/) for additional information about WAL scanning, `allow_incremental_backups`, and `logfile` parameters. !!! Note The BART user account’s `LD_LIBRARY_PATH` environment variable may need to be set to include the directory containing the `libpq` library if invocation of the WAL scanner program fails. See [Basic BART Subcommand Usage](03_basic_bart_subcommand_usage/#basic_bart_subcommand_usage) for information about setting the `LD_LIBRARY_PATH` environment variable. diff --git a/product_docs/docs/bart/2.6/bart_user/03_using_bart/index.mdx b/product_docs/docs/bart/2.6/bart_user/03_using_bart/index.mdx index a076b82b5e9..7d04fe83491 100644 --- a/product_docs/docs/bart/2.6/bart_user/03_using_bart/index.mdx +++ b/product_docs/docs/bart/2.6/bart_user/03_using_bart/index.mdx @@ -1,9 +1,5 @@ --- title: "Using BART" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_bart.html" --- diff --git a/product_docs/docs/bart/2.6/bart_user/04_using_tablespaces.mdx b/product_docs/docs/bart/2.6/bart_user/04_using_tablespaces.mdx index 6683466db04..158364f92a1 100644 --- a/product_docs/docs/bart/2.6/bart_user/04_using_tablespaces.mdx +++ b/product_docs/docs/bart/2.6/bart_user/04_using_tablespaces.mdx @@ -1,9 +1,5 @@ --- title: "Using Tablespaces" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/using_tablespaces.html" --- @@ -52,8 +48,8 @@ In either case, the directories specified in the `tablespace_path` parameter mus If the database server is running on a remote host (in other words you are also using the `remote_host` configuration parameter or will specify the `--remote-host` option with the `RESTORE` subcommand), the specified tablespace directories must exist on the specified remote host. -To view examples of backing up and restoring a database cluster on a remote host containing tablespaces, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/). +To view example of backing up and restoring a database cluster on a remote host containing tablespaces, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). The directories must be owned by the user account with which you intend to start the database server (typically the Postgres user account) with no access by other users or groups as is required for the directory path to which the main full backup is to be restored. -To view a sample BART managed backup and recovery system consisting of both local and remote database servers, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/2.6/bart_ref/). +To view a sample BART managed backup and recovery system consisting of both local and remote database servers, see the *EDB Backup and Recovery Reference Guide* available at the [EDB website](/bart/latest/bart_ref/). diff --git a/product_docs/docs/bart/2.6/bart_user/index.mdx b/product_docs/docs/bart/2.6/bart_user/index.mdx index 50504d9e3db..87565cb4ab0 100644 --- a/product_docs/docs/bart/2.6/bart_user/index.mdx +++ b/product_docs/docs/bart/2.6/bart_user/index.mdx @@ -1,13 +1,6 @@ --- navTitle: Backup and Recovery Guide title: "EDB Postgres Backup and Recovery User Guide" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/genindex.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/introduction.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/conclusion.html" - - "/edb-docs/d/edb-backup-and-recovery-tool/user-guides/backup-recovery-guide/2.6.1/index.html" ---
diff --git a/product_docs/docs/bart/2.6/index.mdx b/product_docs/docs/bart/2.6/index.mdx index 245dc0e42ef..bf93da4c2a8 100644 --- a/product_docs/docs/bart/2.6/index.mdx +++ b/product_docs/docs/bart/2.6/index.mdx @@ -1,7 +1,7 @@ --- title: Backup and Recovery Tool directoryDefaults: -description: "EDB Backup and Recovery Tool Version 2.6 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." + description: "EDB Backup and Recovery Tool Version 2.6.1 Documentation and release notes. A tool to manage and configure PostgreSQL backups and disaster recovery." navigation: - "#Getting Started" - bart_inst @@ -10,4 +10,4 @@ navigation: - "#Guides" - bart_user - bart_ref ---- \ No newline at end of file +--- diff --git a/product_docs/docs/efm/3.6/index.mdx b/product_docs/docs/efm/3.6/index.mdx deleted file mode 100644 index da27fd43bb5..00000000000 --- a/product_docs/docs/efm/3.6/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "EDB Postgres Failover Manager" -productStub: true -directoryDefaults: - description: "EDB Postgres Failover Manager Version 3.6 Documentation and release notes. PostgreSQL replication and failover manager for achieving high availability." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-postgres-failover-manager/3.6" ---- - - diff --git a/product_docs/docs/efm/4.2/efm_user/04_configuring_efm/01_cluster_properties/index.mdx b/product_docs/docs/efm/4.2/efm_user/04_configuring_efm/01_cluster_properties/index.mdx index 5907124322c..0a8abffaba2 100644 --- a/product_docs/docs/efm/4.2/efm_user/04_configuring_efm/01_cluster_properties/index.mdx +++ b/product_docs/docs/efm/4.2/efm_user/04_configuring_efm/01_cluster_properties/index.mdx @@ -794,6 +794,12 @@ The database parameter `synchronous_standby_names` on the primary node specifies reconfigure.num.sync=false ``` +!!! Note + + If you are using the `reconfigure.num.sync` property, ensure that the `wal_sender_timeout` in the primary database is set to at least ten seconds less than the `efm.node.timeout` value. + + + Use the `reconfigure.num.sync.max` property to specify the maximum number to which num-sync can be raised when a standby is added to the cluster. @@ -830,6 +836,11 @@ Set the `reconfigure.sync.primary` property to `true` to take the primary databa reconfigure.sync.primary=false ``` +!!! Note + + If you are using the `reconfigure.sync.primary` property, ensure that the `wal_sender_timeout` in the primary database is set to at least ten seconds less than the `efm.node.timeout` value. + + Use the `minimum.standbys` property to specify the minimum number of standby nodes that will be retained on a cluster; if the standby count drops to the specified minimum, a replica node will not be promoted in the event of a failure of the primary node. diff --git a/product_docs/docs/epas/12/language_pack/01_supported_database_server_versions.mdx b/product_docs/docs/epas/12/language_pack/01_supported_database_server_versions.mdx index 2621a7454e5..9e2df4d290a 100644 --- a/product_docs/docs/epas/12/language_pack/01_supported_database_server_versions.mdx +++ b/product_docs/docs/epas/12/language_pack/01_supported_database_server_versions.mdx @@ -1,11 +1,5 @@ --- title: "Supported Database Server Versions" -legacyRedirects: - - "/edb-docs/d/postgresql/user-guides/language-pack-guide/13.0/supported_database_server_versions.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-advanced-server/user-guides/language-pack-guide/13/supported_database_server_versions.html" --- @@ -21,4 +15,4 @@ Language Pack installers are version and platform specific. Select the Language | Windows (64-bit) | PostgreSQL `9.6`,`10`,`11`,`12` | 1.0 | Perl `5.26`, Python `3.7`, Tcl `8.8` | | Windows (64-bit) | EDB Postgres Advanced Server `9.6`,`10`,`11`,`12` | 1.0 | Perl `5.26`, Python `3.7`, Tcl `8.6` | -For detailed information, please see the EDB Postgres Advanced Server Installation Guide for Linux, available at the [EDB website](/epas/latest/). +For detailed information, please see the EDB Postgres Advanced Server Installation Guide for Linux, available at the [EDB website](/epas/12/). diff --git a/product_docs/docs/epas/12/language_pack/02_installing_language_pack.mdx b/product_docs/docs/epas/12/language_pack/02_installing_language_pack.mdx index cdceb2f03f1..b6f911fa6cc 100644 --- a/product_docs/docs/epas/12/language_pack/02_installing_language_pack.mdx +++ b/product_docs/docs/epas/12/language_pack/02_installing_language_pack.mdx @@ -1,11 +1,5 @@ --- title: "Installing and Configuring Language Pack" -legacyRedirects: - - "/edb-docs/d/postgresql/user-guides/language-pack-guide/13.0/installing_language_pack.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-advanced-server/user-guides/language-pack-guide/13/installing_language_pack.html" --- diff --git a/product_docs/docs/epas/12/language_pack/03_using_the_procedural_languages.mdx b/product_docs/docs/epas/12/language_pack/03_using_the_procedural_languages.mdx index 5f62f3ff6dc..0e9399a4249 100644 --- a/product_docs/docs/epas/12/language_pack/03_using_the_procedural_languages.mdx +++ b/product_docs/docs/epas/12/language_pack/03_using_the_procedural_languages.mdx @@ -1,16 +1,10 @@ --- title: "Using the Procedural Languages" -legacyRedirects: - - "/edb-docs/d/postgresql/user-guides/language-pack-guide/13.0/using_the_procedural_languages.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-advanced-server/user-guides/language-pack-guide/13/using_the_procedural_languages.html" --- -The Postgres procedural languages (PL/Perl, PL/Python, and PL/Java) are installed by the Language Pack installer. You can also use an RPM package to add procedural language functionality to your EDB Postgres Advanced Server installation. For more information about using an RPM package, please see the EDB Postgres Advanced Server Installation Guide, available at the [EDB website](/epas/latest/). +The Postgres procedural languages (PL/Perl, PL/Python, and PL/Java) are installed by the Language Pack installer. You can also use an RPM package to add procedural language functionality to your EDB Postgres Advanced Server installation. For more information about using an RPM package, please see the EDB Postgres Advanced Server Installation Guide, available at the [EDB website](/epas/12/). ## PL/Perl diff --git a/product_docs/docs/epas/12/language_pack/04_uninstalling_language_pack.mdx b/product_docs/docs/epas/12/language_pack/04_uninstalling_language_pack.mdx index 4e371d60ff8..c51775b8303 100644 --- a/product_docs/docs/epas/12/language_pack/04_uninstalling_language_pack.mdx +++ b/product_docs/docs/epas/12/language_pack/04_uninstalling_language_pack.mdx @@ -1,11 +1,5 @@ --- title: "Uninstalling Language Pack" -legacyRedirects: - - "/edb-docs/d/postgresql/user-guides/language-pack-guide/13.0/uninstalling_language_pack.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-advanced-server/user-guides/language-pack-guide/13/uninstalling_language_pack.html" --- The following section outlines the process of uninstalling Language Pack. diff --git a/product_docs/docs/epas/12/language_pack/index.mdx b/product_docs/docs/epas/12/language_pack/index.mdx index b677b383147..c874866a1d9 100644 --- a/product_docs/docs/epas/12/language_pack/index.mdx +++ b/product_docs/docs/epas/12/language_pack/index.mdx @@ -1,15 +1,6 @@ --- navTitle: Language Pack title: "EDB Postgres Language Pack Guide" -legacyRedirects: - - "/edb-docs/d/postgresql/user-guides/language-pack-guide/13.0/index.html" - - "/edb-docs/d/postgresql/user-guides/language-pack-guide/13.0/conclusion.html" - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-advanced-server/user-guides/language-pack-guide/13/index.html" - - "/edb-docs/d/edb-postgres-advanced-server/user-guides/language-pack-guide/13/conclusion.html" - - "/edb-docs/d/edb-postgres-advanced-server/user-guides/language-pack-guide/13/genindex.html" --- This guide provides information about how to install and configure Language Pack, as well as how to use the procedural languages (PL/Perl, PL/Python, and PL/TCL). diff --git a/product_docs/docs/epas/9.5/index.mdx b/product_docs/docs/epas/9.5/index.mdx deleted file mode 100644 index 2d9bebbebc1..00000000000 --- a/product_docs/docs/epas/9.5/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: EDB Postgres Advanced Server -productStub: true -directoryDefaults: - description: "EDB Postgres Advanced Server Version 9.5 Documentation and release notes. Oracle database compatibility with higher security and data redaction for Enterprises." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-postgres-advanced-server/9.5" ---- - - diff --git a/product_docs/docs/eprs/6.2/05_smr_operation/08_optimizing_performance/01_optimizing_snapshot_replication.mdx b/product_docs/docs/eprs/6.2/05_smr_operation/08_optimizing_performance/01_optimizing_snapshot_replication.mdx index da75d2221e9..9dda1806946 100644 --- a/product_docs/docs/eprs/6.2/05_smr_operation/08_optimizing_performance/01_optimizing_snapshot_replication.mdx +++ b/product_docs/docs/eprs/6.2/05_smr_operation/08_optimizing_performance/01_optimizing_snapshot_replication.mdx @@ -33,7 +33,7 @@ The `archive_mode` configuration parameter in the `postgresql.conf` file of the `useFastCopy={true | false}` -The default value is true. +The default value is false. `cpBatchSize` @@ -49,11 +49,11 @@ The default value for `n` is `8`. `batchSize` -The `batchSize` option controls the number of INSERT statements in a JDBC batch. +The `batchSize` option controls the number of `INSERT` statements in a JDBC batch. This option is particularly significant when Oracle or SQL Server is the subscription database since tables of these database types are loaded using JDBC batches of INSERT statements. -For a Postgres subscription database, tables are loaded using JDBC COPY, however, if the COPY operation fails for some reason, then table loading is retried using JDBC batches of INSERT statements as in the case of Oracle and SQL Server. +For a Postgres subscription database, tables are loaded using `JDBC COPY`, however, if the COPY operation fails for some reason, then table loading is retried using JDBC batches of INSERT statements as in the case of Oracle and SQL Server. `batchSize=n` diff --git a/product_docs/docs/hadoop_data_adapter/2.0.5/index.mdx b/product_docs/docs/hadoop_data_adapter/2.0.5/index.mdx deleted file mode 100644 index f754df8894e..00000000000 --- a/product_docs/docs/hadoop_data_adapter/2.0.5/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "EDB Postgres Hadoop Foreign Data Wrapper" -productStub: true -directoryDefaults: - description: "EDB Postgres Hadoop Foreign Data Wrapper Version 2.0.5 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-hadoop-data-adapter/user-guides/user-guide/2.0.5/index.html" - - "/edb-docs/d/edb-postgres-hadoop-data-adapter/user-guides/user-guide/2.0.5/conclusion.html" - - "/edb-docs/d/edb-postgres-hadoop-data-adapter/user-guides/user-guide/2.0.5/whats_new.html" - - "/edb-docs/d/edb-postgres-hadoop-data-adapter/user-guides/user-guide/2.0.5/genindex.html" - - "/edb-docs/p/edb-postgres-hadoop-data-adapter/2.0.5" ---- - - diff --git a/product_docs/docs/hadoop_data_adapter/2.0/index.mdx b/product_docs/docs/hadoop_data_adapter/2.0/index.mdx deleted file mode 100644 index d1f7ec9ec2f..00000000000 --- a/product_docs/docs/hadoop_data_adapter/2.0/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "EDB Postgres Hadoop Foreign Data Wrapper" -productStub: true -directoryDefaults: - description: "EDB Postgres Hadoop Foreign Data Wrapper Version 2.0 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-postgres-hadoop-data-adapter/2.0" ---- - - diff --git a/product_docs/docs/jdbc_connector/42.2.12.1/index.mdx b/product_docs/docs/jdbc_connector/42.2.12.1/index.mdx deleted file mode 100644 index b11c93d72c7..00000000000 --- a/product_docs/docs/jdbc_connector/42.2.12.1/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: EDB JDBC Connector -productStub: true -directoryDefaults: - description: "EDB JDBC Connector Version 42.2.12.1 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/jdbc-connector/user-guides/jdbc-guide/42.2.12.1/genindex.html" - - "/edb-docs/p/jdbc-connector/42.2.12.1" - - "/edb-docs/d/jdbc-connector/user-guides/jdbc-guide/42.2.12.1/whats_new.html" - - "/edb-docs/d/jdbc-connector/user-guides/jdbc-guide/42.2.12.1/conclusion.html" - - "/edb-docs/d/jdbc-connector/user-guides/jdbc-guide/42.2.12.1/index.html" ---- - - diff --git a/product_docs/docs/migration_toolkit/53.0.1/index.mdx b/product_docs/docs/migration_toolkit/53.0.1/index.mdx deleted file mode 100644 index d400fbe1f5f..00000000000 --- a/product_docs/docs/migration_toolkit/53.0.1/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Migration Toolkit" -productStub: true -directoryDefaults: - description: "EDB Postgres Migration Toolkit Version 53.0.1 Documentation and release notes. EDB postgres Migration ToolKit helps migrate data from oracle or any other database to PostgreSQL or EDB Postgres Advanced server." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-migration-toolkit/user-guides/user-guide/53.0.1/conclusion.html" - - "/edb-docs/d/edb-postgres-migration-toolkit/user-guides/user-guide/53.0.1/whats_new.html" - - "/edb-docs/p/edb-postgres-migration-toolkit/53.0.1" - - "/edb-docs/d/edb-postgres-migration-toolkit/user-guides/user-guide/53.0.1/genindex.html" - - "/edb-docs/d/edb-postgres-migration-toolkit/user-guides/user-guide/53.0.1/index.html" ---- - - diff --git a/product_docs/docs/mongo_data_adapter/5.2.8/02_requirements_overview.mdx b/product_docs/docs/mongo_data_adapter/5.2.8/02_requirements_overview.mdx index 51d43460f8d..1e51d9278d1 100644 --- a/product_docs/docs/mongo_data_adapter/5.2.8/02_requirements_overview.mdx +++ b/product_docs/docs/mongo_data_adapter/5.2.8/02_requirements_overview.mdx @@ -25,3 +25,7 @@ The MongoDB Foreign Data Wrapper is supported on the following platforms: **Linux on IBM Power8/9 (LE)** - RHEL 7.x + +## Supported MongoDB C Driver + +The MongoDB Foreign Data Wrapper supports MongoDB C Driver version 1.17.x that is compatible with MongoDB 3.0 and above. However, the MongoDB Foreign Data Wrapper has been tested with the latest version of MongoDB i.e. 4.4. \ No newline at end of file diff --git a/product_docs/docs/ocl_connector/12.1.2.1/01_whats_new.mdx b/product_docs/docs/ocl_connector/12.1.2.1/01_whats_new.mdx new file mode 100644 index 00000000000..ced49ab6680 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/01_whats_new.mdx @@ -0,0 +1,11 @@ +--- +title: "What’s New" +--- + + + +The following features are added to create the EDB OCL Connector 12.1.2.1: + +- EDB OCL Connector now provides multithreading support. +- EDB OCL Connector now supports EDB Postgres Advanced Server 12. +- EDB OCL Connector is now also supported on Windows Server 2019 platform. \ No newline at end of file diff --git a/product_docs/docs/ocl_connector/12.1.2.1/02_supported_platforms.mdx b/product_docs/docs/ocl_connector/12.1.2.1/02_supported_platforms.mdx new file mode 100644 index 00000000000..2d4566da088 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/02_supported_platforms.mdx @@ -0,0 +1,28 @@ +--- +title: "Supported Platforms" +--- + + + +The EDB OCL Connector is certified with Advanced Server version 9.5 and above. The EDB OCL Connector native packages are supported on the following 64-bit platforms: + +- Red Hat Enterprise Linux (x86_64) 7.x and 8.x +- CentOS (x86_64) 7.x and 8.x +- OEL Linux 7.x and 8.x +- PPC-LE 8 running RHEL or CentOS 7.x +- SLES 12.x +- Debian 9.x and 10.x +- Ubuntu 18.04 LTS + +The EDB OCL Connector graphical installers are supported on the following 64-bit Windows platforms: + +- Windows Server 2019 +- Windows Server 2016 +- Windows Server 2012 R2 +- Windows 10 +- Windows 8.1 + +The EDB OCL Connector graphical installers are supported on the following 32-bit Windows platforms: + +- Windows 10 +- Windows 8.1 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/01_installing_and_configuring_the_ocl_connector.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/01_installing_and_configuring_the_ocl_connector.mdx new file mode 100644 index 00000000000..c49c9e4eee0 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/01_installing_and_configuring_the_ocl_connector.mdx @@ -0,0 +1,438 @@ +--- +title: "Installing and Configuring the OCL Connector" +--- + + + +You can use an RPM package, a native package, or a graphical installer to install or update the EDB OCL Connector. + +## Installing the Connector with an RPM Package + +You can install the OCL Connector using an RPM package on the following platforms: + +- [RHEL 7](#rhel7) +- [RHEL 8](#rhel8) +- [CentOS 7](#centos7) +- [CentOS 8](#centos8) + + + +### On RHEL 7 + +Before installing the OCL Connector, you must install the following prerequisite packages, and request credentials from EDB: + +Install the `epel-release` package: + +```text +yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm +``` + +Enable the optional, extras, and HA repositories: + +```text +subscription-manager repos --enable "rhel-*-optional-rpms" --enable "rhel-*-extras-rpms" --enable "rhel-ha-for-rhel-*-server-rpms" +``` + +You must also have credentials that allow access to the EDB repository. For information about requesting credentials, visit: + + + +After receiving your repository credentials you can: + +1. Create the repository configuration file. +2. Modify the file, providing your user name and password. +3. Install `edb-oci`. + +**Creating a Repository Configuration File** + +To create the repository configuration file, assume superuser privileges, and invoke the following command: + +```text +yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm +``` + +The repository configuration file is named `edb.repo`. The file resides in `/etc/yum.repos.d`. + +**Modifying the file, providing your user name and password** + +After creating the `edb.repo` file, use your choice of editor to ensure that the value of the `enabled` parameter is `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the name and password of a registered EDB user. + +```text +[edb] +name=EnterpriseDB RPMs $releasever - $basearch +baseurl=https://:@yum.enterprisedb.com/edb/redhat/rhel-$releasever-$basearch +enabled=1 +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/ENTERPRISEDB-GPG-KEY +``` + +**Installing OCL Connector** + +After saving your changes to the configuration file, use the following commands to install the OCL Connector: + +``` +yum install edb-oci + +yum install edb-oci-devel +``` + +When you install an RPM package that is signed by a source that is not recognized by your system, yum may ask for your permission to import the key to your local server. If prompted, and you are satisfied that the packages come from a trustworthy source, enter `y`, and press `Return` to continue. + +During the installation, yum may encounter a dependency that it cannot resolve. If it does, it will provide a list of the required dependencies that you must manually resolve. + + + +### On RHEL 8 + +Before installing the OCL Connector, you must install the following prerequisite packages, and request credentials from EDB: + +Install the `epel-release` package: + +```text +dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm +``` + +Enable the `codeready-builder-for-rhel-8-\*-rpms` repository: + +```text +ARCH=$( /bin/arch ) +subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms" +``` + +You must also have credentials that allow access to the EDB repository. For information about requesting credentials, visit: + + + +After receiving your repository credentials you can: + +1. Create the repository configuration file. +2. Modify the file, providing your user name and password. +3. Install `edb-oci`. + +**Creating a Repository Configuration File** + +To create the repository configuration file, assume superuser privileges, and invoke the following command: + +```text +dnf -y https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm +``` + +The repository configuration file is named `edb.repo`. The file resides in `/etc/yum.repos.d`. + +**Modifying the file, providing your user name and password** + +After creating the `edb.repo` file, use your choice of editor to ensure that the value of the `enabled` parameter is `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the name and password of a registered EDB user. + +```text +[edb] +name=EnterpriseDB RPMs $releasever - $basearch +baseurl=https://:@yum.enterprisedb.com/edb/redhat/rhel-$releasever-$basearch +enabled=1 +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/ENTERPRISEDB-GPG-KEY +``` + +**Installing OCL Connector** + +After saving your changes to the configuration file, use the below command to install the OCL Connector: + +```text +dnf install edb-oci + +dnf install edb-oci-devel +``` + +When you install an RPM package that is signed by a source that is not recognized by your system, yum may ask for your permission to import the key to your local server. If prompted, and you are satisfied that the packages come from a trustworthy source, enter `y`, and press `Return` to continue. + +During the installation, yum may encounter a dependency that it cannot resolve. If it does, it will provide a list of the required dependencies that you must manually resolve. + + + +### On CentOS 7 + +Before installing the OCL Connector, you must install the following prerequisite packages, and request credentials from EDB: + +Install the `epel-release` package: + +```text +yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm +``` + +!!! Note + You may need to enable the `[extras]` repository definition in the `CentOS-Base.repo` file (located in `/etc/yum.repos.d`). + +You must also have credentials that allow access to the EDB repository. For information about requesting credentials, visit: + + + +After receiving your repository credentials you can: + +1. Create the repository configuration file. +2. Modify the file, providing your user name and password. +3. Install `edb-oci`. + +**Creating a Repository Configuration File** + +To create the repository configuration file, assume superuser privileges, and invoke the following command: + +```text +yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm +``` + +The repository configuration file is named `edb.repo`. The file resides in `/etc/yum.repos.d`. + +**Modifying the file, providing your user name and password** + +After creating the `edb.repo` file, use your choice of editor to ensure that the value of the `enabled` parameter is `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the name and password of a registered EDB user. + +```text +[edb] +name=EnterpriseDB RPMs $releasever - $basearch +baseurl=https://:@yum.enterprisedb.com/edb/redhat/rhel-$releasever-$basearch +enabled=1 +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/ENTERPRISEDB-GPG-KEY +``` + +**Installing OCL Connector** + +After saving your changes to the configuration file, use the following command to install the OCL Connector: + +```text +yum install edb-oci + +yum install edb-oci-devel +``` + +When you install an RPM package that is signed by a source that is not recognized by your system, yum may ask for your permission to import the key to your local server. If prompted, and you are satisfied that the packages come from a trustworthy source, enter `y`, and press `Return` to continue. + +During the installation, yum may encounter a dependency that it cannot resolve. If it does, it will provide a list of the required dependencies that you must manually resolve. + + + +### On CentOS 8 + +Before installing the OCL Connector, you must install the following prerequisite packages, and request credentials from EDB: + +Install the `epel-release` package: + +```text +dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm +``` + +Enable the `PowerTools` repository: + +```text +dnf config-manager --set-enabled PowerTools +``` + +You must also have credentials that allow access to the EDB repository. For information about requesting credentials, visit: + + + +After receiving your repository credentials you can: + +1. Create the repository configuration file. +2. Modify the file, providing your user name and password. +3. Install `edb-oci`. + +**Creating a Repository Configuration File** + +To create the repository configuration file, assume superuser privileges, and invoke the following command: + +```text +dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm +``` + +The repository configuration file is named `edb.repo`. The file resides in `/etc/yum.repos.d`. + +**Modifying the file, providing your user name and password** + +After creating the `edb.repo` file, use your choice of editor to ensure that the value of the `enabled` parameter is `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the name and password of a registered EDB user. + +```text +[edb] +name=EnterpriseDB RPMs $releasever - $basearch +baseurl=https://:@yum.enterprisedb.com/edb/redhat/rhel-$releasever-$basearch +enabled=1 +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/ENTERPRISEDB-GPG-KEY +``` + +**Installing OCL Connector** + +After saving your changes to the configuration file, use the following command to install the OCL Connector: + +```text +dnf install edb-oci + +dnf install edb-oci-devel +``` + +When you install an RPM package that is signed by a source that is not recognized by your system, yum may ask for your permission to import the key to your local server. If prompted, and you are satisfied that the packages come from a trustworthy source, enter `y`, and press `Return` to continue. + +During the installation, yum may encounter a dependency that it cannot resolve. If it does, it will provide a list of the required dependencies that you must manually resolve. + +### Updating an RPM Installation + +If you have an existing `OCL Connector` RPM installation, you can use yum or dnf to upgrade your repository configuration file and update to a more recent product version. To update the `edb.repo` file, assume superuser privileges and enter: + +- On RHEL or CentOS 7: + + `yum upgrade edb-repo` + +- On RHEL or CentOS 8: + + `dnf upgrade edb-repo` + +yum or dnf will update the `edb.repo` file to enable access to the current EDB repository, configured to connect with the credentials specified in your `edb.repo` file. Then, you can use yum to upgrade any installed packages: + +- On RHEL or CentOS 7: + + `yum upgrade edb-oci` + + `yum upgrade edb-oci-devel` + +- On RHEL or CentOS 8: + + `dnf upgrade edb-oci` + + `dnf upgrade edb-oci-devel` + +## Installing the Connector on a SLES 12 Host + +You can use the zypper package manager to install the connector on a SLES 12 host. zypper will attempt to satisfy package dependencies as it installs a package, but requires access to specific repositories that are not hosted at EDB. Before installing the connector, use the following commands to add EDB repository configuration files to your SLES host: + + `zypper addrepo https://zypp.enterprisedb.com/suse/epas12-sles.repo` + `zypper addrepo https://zypp.enterprisedb.com/suse/epas-sles-tools.repo` + `zypper addrepo https://zypp.enterprisedb.com/suse/epas-sles-dependencies.repo` + +Each command creates a repository configuration file in the /etc/zypp/repos.d directory. + +The files are named: + +- `edbas12suse.repo` +- `edbasdependencies.repo` +- `edbastools.repo` + +After creating the repository configuration files, use the `zypper refresh` command to refresh the metadata on your SLES host to include the EDB repositories. + +When prompted for a `User Name` and `Password`, provide your connection credentials for the EDB repository. To request credentials for the repository, visit [the EDB website](https://www.enterprisedb.com/repository-access-request). + +Before installing EDB Postgres Advanced Server or supporting components, you must also add SUSEConnect and the SUSE Package Hub extension to the SLES host, and register the host with SUSE, allowing access to SUSE repositories. Use the commands: + + `zypper install SUSEConnect` + `SUSEConnect -p PackageHub/12/x86_64` + `SUSEConnect -p sle-sdk/12/x86_64` + +For detailed information about registering a SUSE host, visit the [SUSE website](https://www.suse.com/support/kb/doc/?id=7016626). + +Then, you can use the zypper utility to install the connector: + + `zypper install edb-oci` + `zypper install edb-oci-devel` + +## Installing the Connector on a Debian or Ubuntu Host + +To install a DEB package on a Debian or Ubuntu host, you must have credentials that allow access to the EDB repository. To request credentials for the repository, visit [the EDB website](https://www.enterprisedb.com/repository-access-request). + +The following steps will walk you through on using the EDB apt repository to install a DEB package. When using the commands, replace the `username` and `password` with the credentials provided by EDB. + +1. Assume superuser privileges: + + ```text + sudo su – + ``` + +2. Configure the EDB repository: + + On Debian 9: + + ```text + sh -c 'echo "deb https://username:password@apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' + ``` + + On Debian 10: + + a. Set up the EDB repository: + + ```text + sh -c 'echo "deb [arch=amd64] https://apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' + ``` + + b. Substitute your EDB credentials for the `username` and `password` in the following command: + + ```text + sh -c 'echo "machine apt.enterprisedb.com login password " > /etc/apt/auth.conf.d/edb.conf' + ``` + +3. Add support to your system for secure APT repositories: + + ```text + apt-get install apt-transport-https + ``` + +4. Add the EDB signing key: + + ```text + wget -q -O - https://:@apt.enterprisedb.com/edb-deb.gpg.key | apt-key add - + ``` + +5. Update the repository metadata: + + ```text + apt-get update + ``` + +6. Install DEB package: + + ```text + apt-get install edb-oci + apt-get install edb-oci-dev + ``` + +## Using the Graphical Installer to Install the Connector + +You can use the EDB Connectors Installation wizard to add the EDB OCL connector to your system; the wizard is available at the [EDB website](https://www.enterprisedb.com/software-downloads-postgres/). + +This section demonstrates using the Installation Wizard to install the Connectors on a Windows system. (Download the installer, and then, right-click on the installer icon, and select `Run As Administrator` from the context menu.) + +When the `Language Selection` popup opens, select an installation language and click `OK` to continue to the `Setup` window. + +![The OCL Connector Installation wizard](../images/ocl_installation_wizard.png) + +The OCL Connector Installation wizard + +Click `Next` to continue. + +![The Installation dialog](../images/ocl_installation_dialog.png) + +The Installation dialog + +Use the `Installation Directory` dialog to specify the directory in which the connector will be installed, and click `Next` to continue. + +![The Ready to Install dialog](../images/ready_to_install.png) + +The Ready to Install dialog + +Click `Next` on the `Ready to Install` dialog to start the installation; popup dialogs confirm the progress of the installation wizard. + +![The installation is complete](../images/ocl_installation_complete.png) + +The installation is complete + +When the wizard informs you that it has completed the setup, click the `Finish` button to exit the dialog. + +You can also use StackBuilder Plus to add or update the connector on an existing Advanced Server installation; to open StackBuilder Plus, select StackBuilder Plus from the Windows `Apps` menu. + +![Starting StackBuilder Plus](../images/starting_stackbuilder_plus.png) + +Starting StackBuilder Plus + +When StackBuilder Plus opens, follow the onscreen instructions. Select the `EnterpriseDB OCI Connector` option from the `Database Drivers` node of the tree control. + +![Selecting the Connectors installer](../images/selecting_the_connectors_installer.png) + +Selecting the Connectors installer + +Follow the directions of the onscreen wizard to add or update an installation of the EDB Connectors. diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/02_forming_a_connection_string.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/02_forming_a_connection_string.mdx new file mode 100644 index 00000000000..9153bd6c9cf --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/02_forming_a_connection_string.mdx @@ -0,0 +1,47 @@ +--- +title: "Forming a Connection String" +--- + + + +The EDB OCL connector accepts both Oracle-style and Postgres-style connection URI's. A connection string may take the following Oracle-style form: + + `[//][host][:port][/dbname]` + +or the following Postgres-style forms: + +```text +postgres://[user[:password]@][host][:port][/dbname] +[?param1=value1&...] +``` + +```text +postgresql://[user[:password]@][host][:port][/dbname] +[?param1=value1&...] +``` + +You can also use a Postgres-style URI to specify multiple host components (each with an optional port component) in a single URI. A multi-host connection string takes the form: + + `postgresql://host1:port1,host2:port2,host3:port3/` + +Where: + + `user` is the name of the connecting user. + + `password` is the password associated with the connecting user. + + `host` is the host name or IP address to which you are connecting; to specify an IPV6 address, enclose the address in square brackets. + + `port` is the port number to which you are connecting. + + `dbname` is the name of the database with which you are connecting. + + `paramx=valuex` pairs specify extra (application-specific) connection properties. + +For example, each of the following connection strings establish a connection to the `edb` database on port `5444` of a system with an IP address of `10.0.0.4`: + + `//10.0.0.4:5444/edb` + `postgres://10.0.0.4:5444/edb` + `postgresql://10.0.0.4:5444/edb` + +For more information about using Postgres-style connection strings, please see the PostgreSQL core documentation, available at the [EDB website](https://www.postgresql.org/docs/). diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/03_compiling_and_linking_a_program.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/03_compiling_and_linking_a_program.mdx new file mode 100644 index 00000000000..ab85a307437 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/03_compiling_and_linking_a_program.mdx @@ -0,0 +1,49 @@ +--- +title: "Compiling and Linking a Program" +--- + + + +The EDB Open Client Library allows applications written using the Oracle Call Interface API to connect to and access an EDB database with minimal changes to the C source code. The EDB Open Client Library files are named: + + On Linux: + + `libedboci.so` + + On Windows: + + `edboci.dll` + +The files are installed in the `oci/lib` subdirectory. + +**Compiling and Linking a Sample Program** + +The following example compiles and links the sample program `edb_demo.c` in a Linux environment. The `edb_demo.c` is located in the `oci/samples` subdirectory. + +1. Set the `ORACLE_HOME` and `EDB_HOME` environment variables. + +2. Set `ORACLE_HOME` to the complete pathname of the Oracle home directory. + +For example: + +`export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server` + +3. Set `EDB_HOME` to the complete pathname of the home directory. + +For example: + +`export EDB_HOME=/usr/edb` + +4. Set `LD_LIBRARY_PATH` to the complete path of `libpthread.so`. By default, `libpthread.so` is located in `/lib64`. + +`export LD_LIBRARY_PATH=/lib64/lib:$LD_LIBRARY_PATH` + +5. Set `LD_LIBRARY_PATH` to include the Advanced Server Open Client library. By default, `libiconv.so.2` is located in `$EDB_HOME/oci/lib`. + +`export LD_LIBRARY_PATH=$EDB_HOME/oci:$EDB_HOME/oci/lib:$LD_LIBRARY_PATH` + +6. Then, compile and link the OCL API program. + +`cd $EDB_HOME/oci/samples` + +`make` diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/04_ref_cursor_support.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/04_ref_cursor_support.mdx new file mode 100644 index 00000000000..b2b5e5758b6 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/04_ref_cursor_support.mdx @@ -0,0 +1,120 @@ +--- +title: "Ref Cursor Support" +--- + + + +The Advanced Server Open Client Library supports the use of `REF CURSOR` as `OUT` parameters in PL/SQL procedures that are compatible with Oracle. Support is provided through the following APIs: + +- `OCIBindByName` +- `OCIBindByPos` +- `OCIBindDynamic` +- `OCIStmtPrepare` +- `OCIStmtExecute` +- `OCIStmtFetch` +- `OCIAttrGet` + +The EDB OCL connector also supports the `SQLT_RSET` data type. + +The following example demonstrates how to invoke a stored procedure that opens a cursor and returns a `REF CURSOR` as an output parameter. The code sample assumes that a PL/SQL procedure named `openCursor` (with an `OUT` parameter of type `REF CURSOR`) has been created on the database server, and that the required handles have been allocated: + +```text +char * openCursor = + "begin \ + openCursor(:cmdRefCursor); \ + end;"; +OCIStmt *stmtOpenRefCursor; +OCIStmt *stmtUseRefCursor; +``` + +Allocate handles for executing a stored procedure to open and use the `REF CURSOR`: + +```text +/* Handle for the stored procedure to open the ref cursor */ +OCIHandleAlloc((dvoid *) envhp, + (dvoid **) &stmtOpenRefCursor, + OCI_HTYPE_STMT, + 0, + (dvoid **) NULL)); +``` + +```text +/* Handle for using the Ref Cursor */ +OCIHandleAlloc((dvoid *) envhp, + (dvoid **) &stmtUseRefCursor, + OCI_HTYPE_STMT, + 0, + (dvoid **) NULL)); +``` + +Then, prepare the PL/SQL block that is used to open the `REF CURSOR`: + +```text +OCIStmtPrepare(stmtOpenRefCursor, + errhp, + (text *) openCursor, + (ub4) strlen(openCursor), + OCI_NTV_SYNTAX, + OCI_DEFAULT)); +``` + +Bind the PL/SQL `openCursor OUT` parameter: + +```text +OCIBindByPos(stmtOpenRefCursor, + &bndplrc1, + errhp, + 1, + (dvoid*) &stmtUseRefCursor, + /* the returned ref cursor */ + 0, + SQLT_RSET, + /* SQLT_RSET type representing cursor */ + (dvoid *) 0, + (ub2 *) 0, + (ub2) 0, + (ub4) 0, + (ub4 *) 0, + OCI_DEFAULT)); +``` + +Use the `stmtOpenRefCursor` statement handle to call the `openCursor` procedure: + +```text +OCIStmtExecute(svchp, + stmtOpenRefCursor, + errhp, + 1, + 0, + 0, + 0, + OCI_DEFAULT); +``` + +At this point, the `stmtUseRefCursor` statement handle contains the reference to the cursor. To obtain the information, define output variables for the ref cursor: + +```text +/* Define the output variables for the ref cursor */ + OCIDefineByPos(stmtUseRefCursor, + &defnEmpNo, + errhp, + (ub4) 1, + (dvoid *) &empNo, + (sb4) sizeof(empNo), + SQLT_INT, + (dvoid *) 0, + (ub2 *)0, + (ub2 *)0, + (ub4) OCI_DEFAULT)); +``` + +Then, fetch the first row of the result set into the target variables: + +```text +/* Fetch the cursor data */ + OCIStmtFetch(stmtUseRefCursor, + errhp, + (ub4) 1, + (ub4) OCI_FETCH_NEXT, + (ub4) OCI_DEFAULT)) +``` diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/05_ocl_function_reference.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/05_ocl_function_reference.mdx new file mode 100644 index 00000000000..dd981fa522e --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/05_ocl_function_reference.mdx @@ -0,0 +1,417 @@ +--- +title: "OCL Function Reference" +--- + + + +The following tables list the functions supported by the EDB OCL connector. Note that any and all header files must be supplied by the user. Advanced Server does not supply any such files. + +## Connect, Authorize and Initialize Functions + +| Function | Description | +| ----------------- | -------------------------------------------- | +| OCIBreak | Aborts the specified OCL function. | +| OCIEnvCreate | Creates an OCL environment. | +| OCIEnvInit | Initializes an OCL environment handle. | +| OCIInitialize | Initializes the OCL environment. | +| OCILogoff | Releases a session. | +| OCILogon | Creates a logon connection. | +| OCILogon2 | Creates a logon session in various modes. | +| OCIReset | Resets the current operation/protocol. | +| OCIServerAttach | Establishes an access path to a data source. | +| OCIServerDetach | Removes access to a data source. | +| OCISessionBegin | Creates a user session. | +| OCISessionEnd | Ends a user session. | +| OCISessionGet | Gets session from session pool. | +| OCISessionRelease | Releases a session. | +| OCITerminate | Detaches from shared memory subsystem. | + +### Using the tnsnames.ora File + +The `OCIServerAttach` and `OCILogon` method uses `NET_SERVICE_NAME` as connection descriptor specified in the `dblink` parameter of the `tnsnames.ora` file. Use the `tnsnames.ora` file (compatible with Oracle databases), to specify database connection details. OCL searches the user's home directory for a file named `.tnsnames.ora`; if OCL doesn't find the `.tnsnames.ora` file in the user's home directory, it searches the `tnsnames.ora` on path specified in `TNS_ADMIN` environment variable. + +Multiple descriptors `(NET_SERVICE_NAME)` can be specified in `tnsnames.ora` file. + +The sample `tnsnames.ora` file contains: + +```text +EDBX = +(DESCRIPTION = + (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 5444)) + (CONNECT_DATA = (SERVER = DEDICATED)(SID = edb)) +) +``` + +Any parameters not included in the files are ignored by the Open Client Library. In the example, `SID` refers to the database named `edb`, in the cluster running on the `localhost` on port `5444`. + +A C program call to `OCIServerAttach` that uses the `tnsnames.ora` file will look like: + +```text +static text *username = (text *) "enterprisedb"; +static text *password = (text *) "edb"; +static text *attach_str = "EDBX"; +OCIServerAttach(srvhp, errhp, attach_str, strlen(attach_str), 0); +``` + +If you don't have a `tnsnames.ora` file, supply the connection string in the form `//localhost:5444/edbx`. + +!!! Note + Multiple Descriptors are also supported in `tnsnames.ora`. + +## Handle and Descriptor Functions + +| Function | Description | +| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| OCIAttrGet | Get handle attributes. Advanced server supports the following handle attributes: OCI_ATTR_USERNAME, OCI_ATTR_PASSWORD, OCI_ATTR_SERVER, OCI_ATTR_ENV, OCI_ATTR_SESSION, OCI_ATTR_ROW_COUNT, OCI_ATTR_CHARSET_FORM, OCI_ATTR_CHARSET_ID, EDB_ATTR_STMT_LEVEL_TX, OCI_ATTR_MODULE | +| OCIAttrSet | Set handle attributes. Advanced server supports the following handle attributes: OCI_ATTR_USERNAME, OCI_ATTR_PASSWORD, OCI_ATTR_SERVER, OCI_ATTR_ENV, OCI_ATTR_SESSION, OCI_ATTR_ROW_COUNT, OCI_ATTR_CHARSET_FORM, OCI_ATTR_CHARSET_ID, EDB_ATTR_STMT_LEVEL_TX, OCI_ATTR_MODULE, OCI_ATTR_PREFETCH_ROWS | +| OCIDescriptorAlloc | Allocate and initialize a descriptor. | +| OCIDescriptorFree | Free an allocated descriptor. | +| OCIHandleAlloc | Allocate and initialize a handle. | +| OCIHandleFree | Free an allocated handle. | +| OCIParamGet | Get a parameter descriptor. | +| OCIParamSet | Set a parameter descriptor. | + +### EDB_ATTR_EMPTY_STRINGS + +By default, Advanced Server will treat an empty string as a `NULL` value. You can use the `EDB_ATTR_EMPTY_STRINGS` environment attribute to control the behavior of the OCL connector when mapping empty strings. To modify the mapping behavior, use the `OCIAttrSet()` function to set `EDB_ATTR_EMPTY_STRINGS` to one of the following: + +| Value | Description | +| ----------------------- | ------------------------------------------------- | +| OCI_DEFAULT | Treat an empty string as a NULL value. | +| EDB_EMPTY_STRINGS_NULL | Treat an empty string as a NULL value. | +| EDB_EMPTY_STRINGS_EMPTY | Treat an empty string as a string of zero length. | + +To find the value of `EDB_ATTR_EMPTY_STRINGS`, query `OCIAttrGet()`. + +### EDB_ATTR_HOLDABLE + +Advanced Server supports statements that execute as `WITH HOLD` cursors. The `EDB_ATTR_HOLDABLE` attribute specifies which statements execute as `WITH HOLD` cursors. The `EDB_ATTR_HOLDABLE` attribute can be set to any of the following three values: + +- `EDB_WITH_HOLD` - execute as a `WITH HOLD` cursor +- `EDB_WITHOUT_HOLD` - execute using a protocol-level prepared statement +- `OCI_DEFAULT` - see the definition that follows + +You can set the attribute in an `OCIStmt` handle or an `OCIServer` handle. When you create an `OCIServer` handle or an `OCIStmt` handle, the `EDB_ATTR_HOLDABLE` attribute for that handle is set to `OCI_DEFAULT`. + +You can change the `EDB_ATTR_HOLDABLE` attribute for a handle by calling `OCIAttrSet()` and retrieve the attribute by calling `OCIAttrGet()`. + +When Advanced Server executes a `SELECT` statement, it examines the `EDB_ATTR_HOLDABLE` attribute in the `OCIServer` handle. If that attribute is set to `EDB_WITH_HOLD`, the query is executed as a `WITH HOLD` cursor. + +If the `EDB_ATTR_HOLDABLE` attribute in the `OCIServer` handle is set to `EDB_WITHOUT_HOLD`, the query is executed as a normal prepared statement. + +If the `EDB_ATTR_HOLDABLE` attribute in the `OCIServer` handle is set to `OCI_DEFAULT`, Advanced Server uses the value of the `EDB_ATTR_HOLDABLE` attribute in the `OCIServer` handle (if the `EDB_ATTR_HOLDABLE` attribute in the `OCIServer` is set to `EDB_WITH_HOLD`, the query executes as a `WITH HOLD` cursor, otherwise, the query executes as a protocol-prepared statement). + +### EDB_HOLD_CURSOR_ACTION + +The `EDB_HOLD_CURSOR_ACTION` attribute alters the way `WITH HOLD` cursors are created using the OCL interface. You can set this attribute to any of the following values: + +- `EDB_COMMIT_AFTER_CURSOR` – commit the transaction after creating the cursor +- `EDB_CURSOR_WITHOUT_XACT_BLK` – do not begin a new transaction chain +- `OCI_DEFAULT` - see the definition that follows + +The following describes the attribute values. + +`OCI_DEFAULT` + +Each time you execute a statement, the OCL examines the transaction state on the database server. If a transaction is not already in progress, the OCL executes a BEGIN statement to create a new transaction block, and then executes the statement that you provide. The transaction block remains open until you call `OCITransCommit()` or `OCITransRollback()`. + +By default, the database server closes any open cursors when you commit or rollback. If you (or the OCL) declare a cursor that includes the `WITH HOLD` clause, the cursor result set is persisted on the database server, and you may continue to fetch from that cursor. However, the database server will not persist open cursors when you roll back a transaction. If you try to fetch from a cursor after a `ROLLBACK`, the database server will report an error. + +`EDB_COMMIT_AFTER_CURSOR` + +If your application must read from a `WITH HOLD` cursor after rolling back a transaction, you can arrange for the OCL to commit the transaction immediately after creating the cursor by setting `EDB_HOLD_CURSOR_ACTION` to `EDB_COMMIT_AFTER_CURSOR` prior to creating such a cursor. For example: + +```text +ub4 action = EDB_COMMIT_AFTER_CURSOR; + +OCIAttrSet(stmt, OCI_HTYPE_STMT, &action, sizeof(action), + EDB_ATTR_HOLD_CURSOR_ACTION, err); + +OCIStmtExecute( ... ); +``` + +It is important to understand that using `EDB_COMMIT_AFTER_CURSOR` will commit any pending changes. + +`EDB_CURSOR_WITHOUT_XACT_BLK` + +If your application will not run properly with the extra commits added by `EDB_COMMIT_AFTER_CURSOR`, you may try setting `EDB_ATTR_HOLD_CURSOR_ACTION` to `EDB_CURSOR_WITHOUT_XACT_BLK`. With this action, the OCL will not begin a new transaction chain. If you create a `WITH HOLD` cursor immediately after committing or rolling back a transaction, the cursor will be created in its own transaction, the database server will commit that transaction, and the cursor will persist. + +It is important to understand that you may still experience errors if the cursor declaration is not the first statement within a transaction – if you execute some other statement before declaring the cursor, the `WITH HOLD` cursor will be created in a transaction block and may be rolled back if an error occurs (or if your application calls `OCITransRollback()`). + +Please note that you can set the `EDB_HOLD_CURSOR_ACTION` on the server level (`OCIServer`) or for each statement handle (`OCIStmt`). If the statement attribute is set to a value other than `OCI_DEFAULT`, the value is derived from the statement handle, otherwise (if the statement attribute is set to `OCI_DEFAULT`), the value is taken from the server handle. So you can define a server-wide default action by setting the attribute in the server handle, and leaving the attribute set to `OCI_DEFAULT` in the statement handles. You can use different values for each statement handle (or server handle) as you see fit. + +### EDB_ATTR_STMT_LVL_TX + +Unless otherwise instructed, the OCL connector will `ROLLBACK` the current transaction whenever the server reports an error. If you choose, you can override the automatic `ROLLBACK` with the `edb_stmt_level_tx` parameter, which preserves modifications within a transaction, even if one (or several) statements raise an error within the transaction. + +You can use the `OCIServer` attribute with `OCIAttrSet()` and `OCIAttrGet()` to enable or disable `EDB_ATTR_STMT_LEVEL_TX`. By default, `edb_stmt_level_tx` is disabled. To enable `edb_stmt_level_tx`, the client application must call `OCIAttrSet()`: + +```text +OCIServer *server = myServer; +ub1 enabled = 1; + +OCIAttrSet(server, OCI_HTYPE_SERVER, &enabled, + sizeof(enabled), EDB_ATTR_STMT_LEVEL_TX, err); +``` + +To disable `edb_stmt_level_tx`: + +```text +OCIServer *server = myServer; +ub1 enabled = 0; + +OCIAttrSet(server, OCI_HTYPE_SERVER, &enabled, + sizeof(enabled), EDB_ATTR_STMT_LEVEL_TX, err); +``` + +## Bind, Define and Describe Functions + +| Function | Description | +| ----------------------- | ------------------------------------------------- | +| OCIBindByName | Bind by name. | +| OCIBindByPos | Bind by position. | +| OCIBindDynamic | Set additional attributes after bind. | +| OCIBindArrayOfStruct | Bind an array of structures for bulk operations. | +| OCIDefineArrayOfStruct | Specify the attributes of an array. | +| OCIDefineByPos | Define an output variable association. | +| OCIDefineDynamic | Set additional attributes for define. | +| OCIDescribeAny | Describe existing schema objects. | +| OCIStmtGetBindInfo | Get bind and indicator variable names and handle. | +| OCIUserCallbackRegister | Define a user-defined callback. | + +## Statement Functions + +| Function | Description | +| --------------- | --------------------------------- | +| OCIStmtExecute | Execute a prepared SQL statement. | +| OCIStmtFetch | Fetch rows of data (deprecated). | +| OCIStmtFetch2 | Fetch rows of data. | +| OCIStmtPrepare | Prepare a SQL statement. | +| OCIStmtPrepare2 | Prepare a SQL statement. | +| OCIStmtRelease | Release a statement handle. | + +## Transaction Functions + +| Function | Description | +| ---------------- | ------------------------ | +| OCITransCommit | Commit a transaction. | +| OCITransRollback | Roll back a transaction. | + +## XA Functions + +| Function | Description | +| --------- | ------------------------------- | +| xaoEnv | Returns OCL environment handle. | +| xaoSvcCtx | Returns OCL service context. | + +### xaoSvcCtx + +In order to use the xaoSvcCtx function, extensions in the `xaoSvcCtx` or `xa_open` connection string format must be provided as follows: + +`Oracle_XA{+ ...}` + +Where `required_fields` are the following: + +`HostName=host_ip_address` specifies the IP address of the Advanced Server database. + +`PortNumber=host_port_number` specifies the port number on which Advanced Server is running. + +`SqlNet=dbname` specifies the database name. + +`Acc=P/username/password` specifies the database username and password. *password* may be omitted in which case the field is specified as `Acc=P/username/`. + +`AppName=app_id` specifies a number that identifies the application. + +The following is an example of the connection string: + +```text +Oracle_XA+HostName=192.168.1.1+PortNumber=1533+SqlNet=XE+Acc=P/user/password+AppName=1234 +``` + +## Date and Datetime Functions + +| Function | Description | +| ---------------------------- | ----------------------------------------------------------------------------------------------------------------- | +| OCIDateAddDays | Add or subtract a number of days. | +| OCIDateAddMonths | Add or subtract a number of months. | +| OCIDateAssign | Assign a date. | +| OCIDateCheck | Check if the given date is valid. | +| OCIDateCompare | Compare two dates. | +| OCIDateDaysBetween | Find the number of days between two dates. | +| OCIDateFromText | Convert a string to a date. | +| OCIDateGetDate | Get the date portion of a date. | +| OCIDateGetTime | Get the time portion of a date. | +| OCIDateLastDay | Get the date of the last day of the month. | +| OCIDateNextDay | Get the date of the next day. | +| OCIDateSetDate | Set the date portion of a date. | +| OCIDateSetTime | Set the time portion of a date. | +| OCIDateSysDate | Get the current system date and time. | +| OCIDateToText | Convert a date to a string. | +| OCIDateTimeAssign | Perform datetime assignment. | +| OCIDateTimeCheck | Check if the date is valid. | +| OCIDateTimeCompare | Compare two datetime values. | +| OCIDateTimeConstruct | Construct a datetime descriptor. | +| OCIDateTimeConvert | Convert one datetime type to another. | +| OCIDateTimeFromArray | Convert an array of size OCI_DT_ARRAYLEN to an OCIDateTime descriptor. | +| OCIDateTimeFromText | Convert the given string to Oracle datetime type in the OCIDateTime descriptor according to the specified format. | +| OCIDateTimeGetDate | Get the date portion of a datetime value. | +| OCIDateTimeGetTime | Get the time portion of a datetime value. | +| OCIDateTimeGetTimeZoneName | Get the time zone name portion of a datetime value. | +| OCIDateTimeGetTimeZoneOffset | Get the time zone (hour, minute) portion of a datetime value. | +| OCIDateTimeSubtract | Take two datetime values as input and return their difference as an interval. | +| OCIDateTimeSysTimeStamp | Get the system current date and time as a timestamp with time zone. | +| OCIDateTimeToArray | Convert an OCIDateTime descriptor to an array. | +| OCIDateTimeToText | Convert the given date to a string according to the specified format. | + +## Interval Functions + +| Function | Description | +| ----------------------- | -------------------------------------------------------------------------------------------- | +| OCIIntervalAdd | Adds two interval values. | +| OCIIntervalAssign | Copies one interval value into another interval value. | +| OCIIntervalCompare | Compares two interval values. | +| OCIIntervalGetDaySecond | Extracts days, hours, minutes, seconds and fractional seconds from an interval. | +| OCIIntervalSetDaySecond | Modifies days, hours, minutes, seconds and fractional seconds in an interval. | +| OCIIntervalGetYearMonth | Extracts year and month values from an interval. | +| OCIIntervalSetYearMonth | Modifies year and month values in an interval. | +| OCIIntervalDivide | Implements division of OCIInterval values by OCINumber values. | +| OCIIntervalMultiply | Implements multiplication of OCIInterval values by OCINumber values. | +| OCIIntervalSubtract | Subtracts one interval value from another interval value. | +| OCIIntervalToText | Extrapolates a character string from an interval. | +| OCIIntervalCheck | Verifies the validity of an interval value. | +| OCIIntervalToNumber | Converts an OCIInterval value into a OCINumber value. | +| OCIIntervalFromNumber | Converts a OCINumber value into an OCIInterval value. | +| OCIDateTimeIntervalAdd | Adds an OCIInterval value to an OCIDatetime value, resulting in an OCIDatetime value. | +| OCIDateTimeIntervalSub | Subtracts an OCIInterval value from an OCIDatetime value, resulting in an OCIDatetime value. | +| OCIIntervalFromText | Converts a text string into an interval. | +| OCIIntervalFromTZ | Converts a time zone specification into an interval value. | + +## Number Functions + +| Function | Description | +| -------------------- | ------------------------------------------------------------ | +| OCINumberAbs | Compute the absolute value. | +| OCINumberAdd | Adds NUMBERs. | +| OCINumberArcCos | Compute the arc cosine. | +| OCINumberArcSin | Compute the arc sine. | +| OCINumberArcTan | Compute the arc tangent. | +| OCINumberArcTan2 | Compute the arc tangent of two NUMBERs. | +| OCINumberAssign | Assign one NUMBER to another. | +| OCINumberCeil | Compute the ceiling of NUMBER. | +| OCINumberCmp | Compare NUMBERs. | +| OCINumberCos | Compute the cosine. | +| OCINumberDec | Decrement a NUMBER. | +| OCINumberDiv | Divide two NUMBERs. | +| OCINumberExp | Raise e to the specified NUMBER power. | +| OCINumberFloor | Compute the floor of a NUMBER. | +| OCINumberFromInt | Convert an integer to an Oracle NUMBER. | +| OCINumberFromReal | Convert a real to an Oracle NUMBER. | +| OCINumberFromText | Convert a string to an Oracle NUMBER. | +| OCINumberHypCos | Compute the hyperbolic cosine. | +| OCINumberHypSin | Compute the hyperbolic sine. | +| OCINumberHypTan | Compute the hyperbolic tangent. | +| OCINumberInc | Increments a NUMBER. | +| OCINumberIntPower | Raise a given base to an integer power. | +| OCINumberIsInt | Test if a NUMBER is an integer. | +| OCINumberIsZero | Test if a NUMBER is zero. | +| OCINumberLn | Compute the natural logarithm. | +| OCINumberLog | Compute the logarithm to an arbitrary base. | +| OCINumberMod | Modulo division. | +| OCINumberMul | Multiply NUMBERs. | +| OCINumberNeg | Negate a NUMBER. | +| OCINumberPower | Exponentiation to base e. | +| OCINumberPrec | Round a NUMBER to a specified number of decimal places. | +| OCINumberRound | Round a NUMBER to a specified decimal place. | +| OCINumberSetPi | Initialize a NUMBER to Pi. | +| OCINumberSetZero | Initialize a NUMBER to zero. | +| OCINumberShift | Multiply by 10, shifting specified number of decimal places. | +| OCINumberSign | Obtain the sign of a NUMBER. | +| OCINumberSin | Compute the sine. | +| OCINumberSqrt | Compute the square root of a NUMBER. | +| OCINumberSub | Subtract NUMBERs. | +| OCINumberTan | Compute the tangent. | +| OCINumberToInt | Convert a NUMBER to an integer. | +| OCINumberToReal | Convert a NUMBER to a real. | +| OCINumberToRealArray | Convert an array of NUMBER to a real array. | +| OCINumberToText | Converts a NUMBER to a string. | +| OCINumberTrunc | Truncate a NUMBER at a specified decimal place. | + +## String Functions + +| Function | Description | +| ------------------- | --------------------------------------------- | +| OCIStringAllocSize | Get allocated size of string memory in bytes. | +| OCIStringAssign | Assign string to a string. | +| OCIStringAssignText | Assign text string to a string. | +| OCIStringPtr | Get string pointer. | +| OCIStringResize | Resize string memory. | +| OCIStringSize | Get string size. | + +## Cartridge Services and File I/O Interface Functions + +| Function | Description | +| ---------------- | -------------------------------------- | +| OCIFileClose | Close an open file. | +| OCIFileExists | Test to see if the file exists. | +| OCIFileFlush | Write buffered data to a file. | +| OCIFileGetLength | Get the length of a file. | +| OCIFileInit | Initialize the OCIFile package. | +| OCIFileOpen | Open a file. | +| OCIFileRead | Read from a file into a buffer. | +| OCIFileSeek | Change the current position in a file. | +| OCIFileTerm | Terminate the OCIFile package. | +| OCIFileWrite | Write buflen bytes into the file. | + +## LOB Functions + +| Function | Description | +| ----------------- | -------------------------------------------------- | +| OCILobRead | Returns a LOB value (or a portion of a LOB value). | +| OCILOBWriteAppend | Adds data to a LOB value. | +| OCILobGetLength | Returns the length of a LOB value. | +| OCILobTrim | Trims data from the end of a LOB value. | +| OCILobOpen | Opens a LOB value for use by other LOB functions. | +| OCILobClose | Closes a LOB value. | + +## Miscellaneous Functions + +| | | +| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Function | Description | +| OCIClientVersion | Return client library version. | +| OCIErrorGet | Return error message. | +| OCIPGErrorGet | Return native error messages reported by libpq or the server. The signature is:

sword OCIPGErrorGet(dvoid \*hndlp, ub4 recordno, OraText \*errcodep,ub4 errbufsiz, OraText \*bufp, ub4 bufsiz, ub4 type) | +| OCIPasswordChange | Change password. | +| OCIPing | Confirm that the connection and server are active. | +| OCIServerVersion | Get the Oracle version string. | + +## Supported Data Types + +| Function | Description | +| ------------------ | --------------------------------- | +| ANSI_DATE | ANSI date | +| SQLT_AFC | ANSI fixed character | +| SQLT_AVC | ANSI variable character | +| SQLT_BDOUBLE | Binary double | +| SQLT_BIN | Binary data | +| SQLT_BFLOAT | Binary float | +| SQLT_CHR | Character string | +| SQLT_DAT | Oracle date | +| SQLT_DATE | ANSI date | +| SQLT_FLT | Float | +| SQLT_INT | Integer | +| SQLT_LBI | Long binary | +| SQLT_LNG | Long | +| SQLT_LVB | Longer long binary | +| SQLT_LVC | Longer longs (character) | +| SQLT_NUM | Oracle numeric | +| SQLT_ODT | OCL date type | +| SQLT_STR | Zero-terminated string | +| SQLT_TIMESTAMP | Timestamp | +| SQLT_TIMESTAMP_TZ | Timestamp with time zone | +| SQLT_TIMESTAMP_LTZ | Timestamp with local time zone | +| SQLT_UIN | Unsigned integer | +| SQLT_VBI | VCS format binary | +| SQLT_VCS | Variable character | +| SQLT_VNU | Number with preceding length byte | +| SQLT_VST | OCL string type | diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/06_ocl_error_codes_reference.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/06_ocl_error_codes_reference.mdx new file mode 100644 index 00000000000..61c4864cc8c --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/06_ocl_error_codes_reference.mdx @@ -0,0 +1,67 @@ +--- +title: "OCL Error Codes – Reference" +--- + + + +The following table lists the error code mappings defined by the OCL Connector. When the database server reports an error code or condition (shown in the first or second column), the OCL converts the value to the compatible value displayed in the third column. + +| Error Code | Condition Name | Oracle Error Code | +| ---------- | ------------------------------------------------- | ----------------- | +| 42601 | syntax_error | ORA-16945 | +| 42P01 | undefined_table | ORA-00942 | +| 02000 | no_data | ORA-01403 | +| 08000 | connection_exception | ORA-12545 | +| 08003 | connection_does_not_exist | ORA-12545 | +| 08006 | connection_failure | ORA-12545 | +| 08001 | sqlclient_unable_to_establish_sqlconnection | ORA-12545 | +| 08004 | sqlserver_rejected_establishment_of_sqlconnection | ORA-12545 | +| 25000 | invalid_transaction_state | ORA-01453 | +| 08007 | transaction_resolution_unknown | ORA-01453 | +| 0A000 | feature_not_supported | ORA-03001 | +| 22012 | division_by_zero | ORA-01476 | +| 2200B | escape_character_conflict | ORA-01424 | +| 22019 | invalid_escape_character | ORA-00911 | +| 2200D | invalid_escape_octet | ORA-01424 | +| 22025 | invalid_escape_sequence | ORA-01424 | +| 22P06 | nonstandard_use_of_escape_character | ORA-01424 | +| 2200C | invalid_use_of_escape_character | ORA-01424 | +| 22004 | null_value_not_allowed | ORA-01400 | +| 23000 | integrity_constraint_violation | ORA-00001 | +| 23505 | unique_violation | ORA-00001 | +| 40P01 | t_r_deadlock_detected | ORA-00060 | +| 42701 | duplicate_column | ORA-01430 | +| 53000 | insufficient_resources | ORA-01659 | +| 53100 | disk_full | ORA-01659 | +| 53200 | out_of_memory | ORA-82100 | +| 42P07 | duplicate_table | ORA-00955 | +| 21000 | cardinality_violation | ORA-01427 | +| 22003 | numeric_value_out_of_range | ORA-01426 | +| 22P02 | invalid_text_representation | ORA-01858 | +| 28000 | invalid_authorization_specification | ORA-01017 | +| 28P01 | invalid_password | ORA-01017 | +| 2200F | zero_length_character_string | ORA-01425 | +| 42704 | undefined_object | ORA-01418 | +| 2BP01 | dependent_objects_still_exist | ORA-02429 | +| 22027 | trim_error | ORA-30001 | +| 22001 | string_data_right_truncation | ORA-01401 | +| 22002 | null_value_no_indicator_parameter | ORA-01405 | +| 22008 | datetime_field_overflow | ORA-01800 | +| 44000 | with_check_option_violation | ORA-01402 | +| 01007 | warning_privilege_not_granted | ORA-00000 | +| 01006 | warning_privilege_not_revoked | ORA-00000 | +| 02001 | no_additional_dynamic_result_sets_returned | ORA-00000 | +| 03000 | sql_statement_not_yet_complete | ORA-00000 | +| 08P01 | protocol_violation | ORA-00000 | +| 23001 | restrict_violation | ORA-00000 | +| 23502 | not_null_violation | ORA-00000 | +| 23505 | foreign_key_violation | ORA-00000 | +| 23514 | check_violation | ORA-00000 | +| 24000 | invalid_cursor_state | ORA-01001 | +| 26000 | invalid_sql_statement_name | ORA-00000 | +| 42830 | invalid_foreign_key | ORA-00000 | +| 55006 | object_in_use | ORA-00000 | +| 55P03 | lock_not_available | ORA-00054 | +| 72000 | snapshot_too_old | ORA-01555 | + +For more information about Postgres error codes, please see the PostgreSQL core [documentation](https://www.postgresql.org/docs/12/static/errcodes-appendix.html). diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/07_multithreading_support.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/07_multithreading_support.mdx new file mode 100644 index 00000000000..7c4a52586e0 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/07_multithreading_support.mdx @@ -0,0 +1,24 @@ +--- +title: "Multithreading Support" +--- + + + +OCL is supported in multithreaded environment. You can enable/use multithreading in a multithreaded environment by making an `OCIEnvNlsCreate()` call with `OCI_THREADED` as the value of the mode parameter. + +```text +retCode = OCIEnvNlsCreate( &envp, + OCI_THREADED, + NULL, + NULL, + NULL, + NULL, + 0, + NULL, + 0, + 0 ); +``` + +All subsequent calls to `OCIEnvNlsCreate()` must also be made with `OCI_THREADED`. + +OCI library manages mutexes for the application for each environment handle if a multithreaded application is running on a thread-safe operating system. diff --git a/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/index.mdx b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/index.mdx new file mode 100644 index 00000000000..0e14465b177 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/04_open_client_library/index.mdx @@ -0,0 +1,21 @@ +--- +title: "Open Client Library" +--- + + + +The Open Client Library provides application interoperability with the Oracle Call Interface - an application that was formerly locked in can now work with either an EDB Postgres Advanced Server or an Oracle database with minimal to no changes to the application code. + +The following diagram compares the Open Client Library and Oracle Call Interface application stacks. + +![Comparison with Oracle Call Interface](../images/oracle_call_interface.png) + +Comparison with Oracle Call Interface + +The EDB implementation of the Open Client Library is written in C. + +
+ +installing_and_configuring_the_ocl_connector forming_a_connection_string compiling_and_linking_a_program ref_cursor_support ocl_function_reference ocl_error_codes_reference multithreading_support otl_support + +
diff --git a/product_docs/docs/ocl_connector/12.1.2.1/05_generating_the_ocl_trace.mdx b/product_docs/docs/ocl_connector/12.1.2.1/05_generating_the_ocl_trace.mdx new file mode 100644 index 00000000000..a7ea045517a --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/05_generating_the_ocl_trace.mdx @@ -0,0 +1,22 @@ +--- +title: "Generating the OCL Trace" +--- + + + +The OCL tracing option logs direct communication (queries, updates, etc.) with the backend in specified `OCI_DEBUG_LOG file`. In addition, it also logs the functions/APIs that were invoked. The trace files are generated in the default working directory (`oci_log_file_name`). If you append the path with a file name (`directory path/oci_log_file_name`), then the trace files are generated at specific location. + +A tracefile is generated for each connection in text file (readable) format. + +!!! Note + OCL tracing is disabled by default. + +To generate the OCL Trace: + +1. Enable the EDB Client Side tracing for OCL. You can enable the OCL tracing by setting below environment variables: + +`export OCI_DEBUG_LEVEL=4` + +`export OCI_DEBUG_LOG=oci_log_file` + +2. Once you have exported the environment variables, execute the application. The OCL trace files are generated in the specified directory. diff --git a/product_docs/docs/ocl_connector/12.1.2.1/06_using_ssl.mdx b/product_docs/docs/ocl_connector/12.1.2.1/06_using_ssl.mdx new file mode 100644 index 00000000000..99c396b5c64 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/06_using_ssl.mdx @@ -0,0 +1,39 @@ +--- +title: "Using SSL" +--- + + + +EDB Postgres Advanced Server provides native support for using SSL connections to encrypt client/server communications for increased security. In OCL, it is controlled by setting the `sslmode` parameter to `verify-full` or `verify-ca`, and providing the system with a root certificate to verify against. + +**Steps of SSL configuration:** + +1. Configure the Server and Client Side Certificates; for detailed information about configuring SSL client and server side certificates, refer to the PostgreSQL SSL [documentation](https://www.postgresql.org/docs/12/libpq-ssl.html). + +2. Enable the SSL OCL Connection: + + In an OCL client application, you can enable SSL mode by setting the `EDB_ATTR_SSL` attribute in `Session`. + +```text +char*sslmode= "verify-full"; +retValue=OCIAttrSet((dvoid*)authp,(ub4)OCI_HTYPE_SESSION, + (dvoid*)sslmode,(ub4)strlen((char*)sslmode), + (ub4)EDB_ATTR_SSL, errhp); +``` + +!!! Note + `EDB_ATTR_SSL` is defined in `edboci.h` header file available in installation directory. + +3. After setting SSL attribute, you can use the `OCILogon` function to create a connection: + +```text +OCILogon(pEnv,pError,&pSvc,(OraText*)pUsername,ub4)UsernameLen, + (OraText*)pPassword,(ub4)PasswordLen, + (OraText*)pDatabase,(ub4)DatabaseLen); +``` + +Once the server is authenticated, then the client is ready to pass sensitive data. + +For more information about the supported SSL mode options, please see: + + diff --git a/product_docs/docs/ocl_connector/12.1.2.1/07_scram_compatibility.mdx b/product_docs/docs/ocl_connector/12.1.2.1/07_scram_compatibility.mdx new file mode 100644 index 00000000000..00825bbb9a1 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/07_scram_compatibility.mdx @@ -0,0 +1,7 @@ +--- +title: "Scram Compatibility" +--- + + + +The EDB OCL driver provides SCRAM-SHA-256 support for Advanced Server version 11 and onwards. This support is available from EDB OCL 11.0.1 release onwards. diff --git a/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_complete.png b/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_complete.png new file mode 100755 index 00000000000..18d535b6613 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_complete.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:67fbe6582167a1866bdc942f3fa4b236d317b9449ae379295a5ae4099cf9bc66 +size 271262 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_dialog.png b/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_dialog.png new file mode 100755 index 00000000000..f2c1ae42a67 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_dialog.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:cc1616ae47691ad7f62d9a83ff3a9d29e64764069f8f7fdb8c96519bdd32c0a3 +size 48180 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_wizard.png b/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_wizard.png new file mode 100755 index 00000000000..ac0f8bf3021 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/images/ocl_installation_wizard.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:7c58c59f17592bc5ecd2bb856b4d2ecb5bad19041902727531ed0eb39ae93e56 +size 280241 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/images/oracle_call_interface.png b/product_docs/docs/ocl_connector/12.1.2.1/images/oracle_call_interface.png new file mode 100755 index 00000000000..211ceda4b45 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/images/oracle_call_interface.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:c18e51dcc8b9ce545d2aaeb93ebcf7e51f95898ee0d408b8502cffcc27cfa193 +size 103652 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/images/ready_to_install.png b/product_docs/docs/ocl_connector/12.1.2.1/images/ready_to_install.png new file mode 100755 index 00000000000..4d2ce00c860 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/images/ready_to_install.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:198309699882c30c62c23f0889a2fc4299350803c6bbde38c34a62be67e878aa +size 43327 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/images/selecting_the_connectors_installer.png b/product_docs/docs/ocl_connector/12.1.2.1/images/selecting_the_connectors_installer.png new file mode 100644 index 00000000000..fb66d12cf3d --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/images/selecting_the_connectors_installer.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:34c829e958aba00782875a1bf6587ba45c44efc2072033b0b63dbbd4cd87d49d +size 160720 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/images/starting_stackbuilder_plus.png b/product_docs/docs/ocl_connector/12.1.2.1/images/starting_stackbuilder_plus.png new file mode 100644 index 00000000000..11665300652 --- /dev/null +++ b/product_docs/docs/ocl_connector/12.1.2.1/images/starting_stackbuilder_plus.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:ce6bcefb865ca14239fb7e0e2ac5149ed56251cfbc5153869070d039f70857c6 +size 91989 diff --git a/product_docs/docs/ocl_connector/12.1.2.1/index.mdx b/product_docs/docs/ocl_connector/12.1.2.1/index.mdx index 3575091f158..6b8eb4b1040 100644 --- a/product_docs/docs/ocl_connector/12.1.2.1/index.mdx +++ b/product_docs/docs/ocl_connector/12.1.2.1/index.mdx @@ -1,16 +1,24 @@ --- title: EDB OCL Connector -productStub: true directoryDefaults: description: "EDB OCL Connector Version 12.1.2.1 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/12.1.2.1/conclusion.html" - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/12.1.2.1/genindex.html" - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/12.1.2.1/whats_new.html" - - "/edb-docs/p/edb-postgres-ocl-connector/12.1.2.1" - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/12.1.2.1/index.html" --- - +The EDB OCL Connector provides an API similar to the Oracle Call Interface. Applications that are written to use the Oracle Call Interface may be recompiled using EDB's OCL connector in order to interact with an Advanced Server database server. + +This guide provides installation and usage instructions about: + +- How to install the connector. +- How to form an Oracle style connection string. +- How to compile and link a program. + +This guide also includes a reference section for the functions supported by Advanced Server. + +!!! Note + EDB does not support use of the Open Client Library with Oracle Real Application Clusters (RAC) and Oracle Exadata; the aforementioned Oracle products have not been evaluated nor certified with this EDB product. + +
+ +whats_new supported_platforms libpq_compatibility open_client_library generating_the_ocl_trace using_ssl scram_compatibility conclusion + +
diff --git a/product_docs/docs/ocl_connector/13.1.4.1/index.mdx b/product_docs/docs/ocl_connector/13.1.4.1/index.mdx deleted file mode 100644 index f7bde047871..00000000000 --- a/product_docs/docs/ocl_connector/13.1.4.1/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: EDB OCL Connector -productStub: true -directoryDefaults: - description: "EDB OCL Connector Version 13.1.4.1 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/13.1.4.1/conclusion.html" - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/13.1.4.1/whats_new.html" - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/13.1.4.1/genindex.html" - - "/edb-docs/p/edb-postgres-ocl-connector/13.1.4.1" - - "/edb-docs/d/edb-postgres-ocl-connector/user-guides/ocl-guide/13.1.4.1/index.html" ---- - - diff --git a/product_docs/docs/odbc_connector/12.0.0.1/index.mdx b/product_docs/docs/odbc_connector/12.0.0.1/index.mdx deleted file mode 100644 index d07ceb2e13c..00000000000 --- a/product_docs/docs/odbc_connector/12.0.0.1/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: EDB ODBC Connector -productStub: true -directoryDefaults: - description: "EDB ODBC Connector Version 12.0.0.1 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.0.0.1/conclusion.html" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.0.0.1/whats_new.html" - - "/edb-docs/p/edb-postgres-odbc-connector/12.0.0.1" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.0.0.1/genindex.html" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.0.0.1/index.html" ---- - - diff --git a/product_docs/docs/odbc_connector/12.0.0.2/02_requirements_overview.mdx b/product_docs/docs/odbc_connector/12.0.0.2/02_requirements_overview.mdx new file mode 100644 index 00000000000..ddfb9bd62d6 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/02_requirements_overview.mdx @@ -0,0 +1,43 @@ +--- +title: "Requirements Overview" + +legacyRedirectsGenerated: + # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/requirements_overview.html" +--- + +## Supported Versions + +The EDB ODBC Connector is certified with Advanced Server version 9.4 and above. + +## Supported Platforms + +The EDB ODBC Connector native packages are supported on the following platforms: + +64 bit Linux: + +- Red Hat Enterprise Linux (x86_64) 8.x and 7.x +- CentOS (x86_64) 8.x and 7.x +- OEL Linux 7.x +- PPC-LE 8 running RHEL or CentOS 7.x +- SLES 12.x +- Debian 9.x +- Ubuntu 18.04 LTS + +!!! Note + EDB ODBC Connector, version 12.00.0000.02 is no longer supported on CentOS/RHEL/OEL 6.x platforms. It is strongly recommended that EDB products running on these platforms be migrated to a supported platform + +The EDB ODBC Connector graphical installers are supported on the following Windows platforms: + +64-bit Windows: + +- Windows Server 2019 +- Windows Server 2016 +- Windows Server 2012 R2 +- Windows 10 +- Windows 8 + +32-bit Windows: + +- Windows 10 +- Windows 8 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/03_edb-odbc_overview/01_installing_edb-odbc.mdx b/product_docs/docs/odbc_connector/12.0.0.2/03_edb-odbc_overview/01_installing_edb-odbc.mdx new file mode 100644 index 00000000000..9166dee2416 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/03_edb-odbc_overview/01_installing_edb-odbc.mdx @@ -0,0 +1,266 @@ +--- +title: "Installing EDB-ODBC" + +legacyRedirectsGenerated: + # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/installing_edb-odbc.html" +--- + +The EDB ODBC Connector is distributed and installed with the EDB Postgres Advanced Server graphical or RPM installer. + +## Installing the Connector with an RPM Package + +### On RHEL 7 + +Before installing the ODBC connector, you must: + +Install the epel-release package: + +- On RHEL or CentOS 7: + ```text + yum -y install https://dl.fedoraproject.org/pub/epel/ + epel-release-latest-7.noarch.rpm + ``` +- On RHEL or CentOS 8: + ```text + dnf -y install https://dl.fedoraproject.org/pub/epel/ + epel-release-latest-7.noarch.rpm + ``` + +!!! Note + You may need to enable the `[extras]` repository definition in the CentOS-Base.repo file (located in `/etc/yum.repos.d`). + +You must also have credentials that allow access to the EDB repository. For information about requesting credentials, visit: + + + +After receiving your repository credentials you can: + +1. Create the repository configuration file. +2. Modify the file, providing your user name and password. +3. Install `edb-odbc`. + +**Creating a Repository Configuration File** + +To create the repository configuration file, assume superuser privileges, and invoke the following command: + +- On RHEL or CentOS 7: + +```text +yum -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm +``` + +- On RHEL or CentOS 8: + +```text +dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm +``` + +The repository configuration file is named `edb.repo`. The file resides in `/etc/yum.repos.d`. + +**Modifying the file, providing your user name and password** + +After creating the `edb.repo` file, use your choice of editor to ensure that the value of the `enabled` parameter is `1`, and replace the `username` and `password` placeholders in the `baseurl` specification with the name and password of a registered EDB user. + +```text +[edb] +name=EnterpriseDB RPMs $releasever - $basearch +baseurl=https://:@yum.enterprisedb.com/edb/redhat/rhel-$releasever-$basearch +enabled=1 +gpgcheck=1 +gpgkey=file:///etc/pki/rpm-gpg/ENTERPRISEDB-GPG-KEY +``` + +**Installing ODBC Connector** + +After saving your changes to the configuration file, use the following commands to install the ODBC Connector: + +- On RHEL or CentOS 7: + +```text +yum install edb-odbc + +yum install edb-odbc-devel +``` + +- On RHEL or CentOS 8: + +```text +dnf install edb-odbc + +dnf install edb-odbc-devel +``` + +When you install an RPM package that is signed by a source that is not recognized by your system, yum may ask for your permission to import the key to your local server. If prompted, and you are satisfied that the packages come from a trustworthy source, enter `y`, and press `Return` to continue. + +During the installation, yum may encounter a dependency that it cannot resolve. If it does, it will provide a list of the required dependencies that you must manually resolve. + + + +### Updating an RPM Installation + +If you have an existing EDB ODBC connector RPM installation, you can use yum or dnf to upgrade your repository configuration file and update to a more recent product version. To update the `edb.repo` file, assume superuser privileges and enter: + +- On RHEL or CentOS 7: + + ```text + yum upgrade edb-repo + ``` + +- On RHEL or CentOS 8: + + ```text + dnf upgrade edb-repo + ``` + +yum or dnf will update the `edb.repo` file to enable access to the current EDB repository, configured to connect with the credentials specified in your `edb.repo` file. Then, you can use yum or dnf to upgrade any installed packages: + +- On RHEL or CentOS 7: + + ```text + yum upgrade edb-odbc + + yum upgrade edb-odbc-devel + ``` + +- On RHEL or CentOS 8: + + ```text + dnf upgrade edb-odbc + + dnf upgrade edb-odbc-devel + ``` + +## Installing the Connector on an SLES 12 Host + +You can use the zypper package manager to install the connector on an SLES 12 host. zypper will attempt to satisfy package dependencies as it installs a package, but requires access to specific repositories that are not hosted at EDB. Before installing the connector, use the following commands to add EDB repository configuration files to your SLES host: + +```txt +zypper addrepo +https://zypp.enterprisedb.com/suse/epas12-sles.repo +zypper addrepo +https://zypp.enterprisedb.com/suse/epas-sles-tools.repo +zypper addrepo +https://zypp.enterprisedb.com/suse/epas-sles-dependencies.repo +``` + +Each command creates a repository configuration file in the `/etc/zypp/repos.d directory`. The files are named: + +- `Edbas12suse.repo` +- `edbasdependencies.repo` +- `edbastools.repo` + +After creating the repository configuration files, use the zypper refresh command to refresh the metadata on your SLES host to include the EDB repositories. + +```txt +/etc/zypp/repos.d # zypper refresh +``` + +When prompted for a `User Name` and `Password`, provide your connection credentials for the EDB repository. To request credentials for the repository, visit [the EDB website](https://www.enterprisedb.com/repository-access-request). + +Before installing EDB Postgres Advanced Server or supporting components, you must also add SUSEConnect and the SUSE Package Hub extension to the SLES host, and register the host with SUSE, allowing access to SUSE repositories. Use the commands: + +```txt +zypper install SUSEConnect +SUSEConnect -p PackageHub/12/x86_64 +SUSEConnect -p sle-sdk/12/x86_64 +``` + +For detailed information about registering a SUSE host, visit the [SUSE website](https://www.suse.com/support/kb/doc/?id=7016626). + +Then, you can use the zypper utility to install the connector: + +```txt +zypper install edb-odbc + +zypper install edb-odbc-devel +``` + +## Installing the Connector on a Debian or Ubuntu Host + +To install a DEB package on a Debian or Ubuntu host, you must have credentials that allow access to the EDB repository. To request credentials for the repository, visit the [EDB website](https://www.enterprisedb.com/repository-access-request/). + +The following steps will walk you through on using the EDB apt repository to install a DEB package. When using the commands, replace the `username` and `password` with the credentials provided by EDB. + +1. Assume superuser privileges: + + ```text + sudo su – + ``` + +2. Configure the EDB repository: + + ```text + sh -c 'echo "deb https://username:password@apt.enterprisedb.com/$(lsb_release -cs)-edb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/edb-$(lsb_release -cs).list' + ``` + +3. Add support to your system for secure APT repositories: + + ```text + apt-get install apt-transport-https + ``` + +4. Add the EDB signing key: + + ```text + wget -q -O - https://:@apt.enterprisedb.com/edb-deb.gpg.key | apt-key add - + ``` + +5. Update the repository metadata: + + ```text + apt-get update + ``` + +6. Install DEB package: + + ```text + apt-get install edb-odbc + apt-get install edb-odbc-dev + ``` + +## Using the Graphical Installer to Install the Connector + +You can use the EDB Connectors Installation wizard to add the ODBC connector to your system; the wizard is available at the [EDB website](https://www.enterprisedb.com/software-downloads-postgres/). + +Download the installer, and then, right-click on the installer icon, and select `Run As Administrator` from the context menu. + +When the `Language Selection` popup opens, select an installation language and click `OK` to continue to the `Setup` window (shown in Figure below). + +![The ODBC Connectors Installation wizard.](../images/odbc_installation_wizard.png) + +The ODBC Connectors Installation wizard. + +Click `Next` to continue. + +![The Installation dialog.](../images/odbc_installation_dialog.png) + +The Installation dialog + +Use the `Installation Directory` dialog to specify the directory in which the connector will be installed, and click `Next` to continue. + +![The Ready to Install dialog.](../images/ready_to_install.png) + +The Ready to Install dialog. + +Click `Next` on the `Ready to Install` dialog to start the installation; popup dialogs confirm the progress of the installation wizard. + +![The installation is complete.](../images/odbc_installation_complete.png) +ß +he installation is complete. + +When the wizard informs you that it has completed the setup, click the `Finish` button to exit the dialog. + +You can also use StackBuilder Plus to add or update the connector on an existing Advanced Server installation; to open StackBuilder Plus, select `StackBuilder Plus` from the `Windows Apps` menu or through Linux `Start` menu. + +![Starting StackBuilder Plus](../images/starting_stackbuilder_plus.png) + +Starting StackBuilder Plus + +When StackBuilder Plus opens, follow the onscreen instructions. Select the `EnterpriseDB ODBC Connector` option from the `Database Drivers` node of the tree control. + +![Selecting the Connectors installer.](../images/selecting_the_connectors_installer.png) + +Selecting the Connectors installer. + +Follow the directions of the onscreen wizard to add or update an installation of the EDB Connectors. diff --git a/product_docs/docs/odbc_connector/12.0.0.2/03_edb-odbc_overview/index.mdx b/product_docs/docs/odbc_connector/12.0.0.2/03_edb-odbc_overview/index.mdx new file mode 100644 index 00000000000..2124ba7911f --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/03_edb-odbc_overview/index.mdx @@ -0,0 +1,26 @@ +--- +title: "EDB-ODBC Overview" + +legacyRedirectsGenerated: + # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/edb-odbc_overview.html" +--- + +EDB ODBC is an interface that allows an ODBC compliant client application to connect to an Advanced Server database. The EDB-ODBC connector allows an application that was designed to work with other databases to run on Advanced Server; EDB ODBC provides a way for the client application to establish a connection, send queries and retrieve results from Advanced Server. + +While EDB ODBC provides a level of application portability, it should be noted that the portability is limited; EDB ODBC provides a connection, but does not guarantee command compatibility. Commands that are acceptable in another database, may not work in Advanced Server. + +The major components in a typical ODBC application are: + +- The client application - written in a language that has a binding for ODBC +- The ODBC Administrator - handles named connections for Windows or Linux +- The database specific ODBC driver - EDB ODBC +- The ODBC compliant server - EDB Postgres Advanced Server + +Client applications can be written in any language that has a binding for ODBC; C, MS-Access, and C++ are just a few. + +
+ +installing_edb-odbc + +
diff --git a/product_docs/docs/odbc_connector/12.0.0.2/04_creating_a_data_source.mdx b/product_docs/docs/odbc_connector/12.0.0.2/04_creating_a_data_source.mdx new file mode 100644 index 00000000000..903d06485eb --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/04_creating_a_data_source.mdx @@ -0,0 +1,37 @@ +--- +title: "Creating a Data Source" + +legacyRedirectsGenerated: + # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/creating_a_data_source.html" +--- + +When a client application tries to establish a connection with a server, it typically provides a data source name (also known as a "DSN"). The driver manager looks through the ODBC configuration database for a data source whose name matches the DSN provided by the application. + +On a Linux or Unix host, data sources are defined in a file; that file is usually named /etc/odbc.ini, but the name (and location) may vary. Use the following command to find out where unixODBC is searching for data source definitions: + +`$ odbc_config --odbcini --odbcinstini` + +On a Windows host, data sources are typically defined in the Windows registry. + +You can also store a data source definition (called a "File DSN") in a plain-text file of your choice. A typical data source definition for the EDB-ODBC driver looks like this: + +```text +$ cat /etc/odbc.ini +[EnterpriseDB] +Description = EnterpriseDB DSN +Driver = EnterpriseDB +Trace = yes +TraceFile = /tmp/odbc.log +Database = edb +Servername = localhost +UserName = enterprisedb +Password = manager +Port = 5444 +``` + +The first line in the data source is the data source name. The name is a unique identifier, enclosed in square brackets. The data source name is followed by a series of `'keyword=value'` pairs that identify individual connection properties that make up the data source. + +The ODBC administrator utility creates named data sources for ODBC connections. In most cases, an ODBC administrator utility is distributed with the operating system (if you’re using Windows or unixODBC, the tool is called the `ODBC Data Source Administrator`). If your operating system doesn’t include an ODBC administrator, third-party options are available online. + +Sections `Adding a Data Source Definition in Windows` and `Adding a Data Source Definition in Linux` walk you through adding a data source in Windows and Linux using the graphical tools available for each operating system. During the process of defining a data source, you’ll be asked to specify a set of connection properties. Section `EDB-ODBC Connection Properties` contains information about `optional` data source connection properties; you can specify connection properties with graphical tools or edit the `odbc.ini` file with a text editor. diff --git a/product_docs/docs/odbc_connector/12.0.0.2/05_edb-odbc_connection_properties.mdx b/product_docs/docs/odbc_connector/12.0.0.2/05_edb-odbc_connection_properties.mdx new file mode 100644 index 00000000000..f87c8c4ebd0 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/05_edb-odbc_connection_properties.mdx @@ -0,0 +1,300 @@ +--- +title: "EDB-ODBC Connection Properties" + +legacyRedirectsGenerated: + # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/edb-odbc_connection_properties.html" +--- + +The following table describes the connection properties that you can specify through the dialogs in the graphical connection manager tools, or in the `odbc.ini` file that defines a named data source. The columns identify the connection property (as it appears in the ODBC Administrator dialogs), the corresponding keyword (as it appears in the `odbc.ini` file), the default value of the property, and a description of the connection property. + +| Property | Keyword name | Default value | Description | +| ----------------------------------------- | ----------------------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Database | Database | None | The name of the database to which you are connecting. | +| Driver | Driver | EDB-ODBC | The name of the ODBC driver. | +| Server | Servername | Localhost | The name or IP address of the server that you are connecting to. | +| dbms_name | dbms_name | EnterpriseDB | Database system. Either EnterpriseDB or PostgreSQL. | +| Description | Description | | Descriptive name of the data source. | +| User Name | Username | | The name of the user that this data source uses to connect to the server. | +| Password | Password | | The password of the user associated with this named data source. | +| CPTimeout | CPTimeout | 0 | Number of seconds before a connection times out (in a connection pooling environment). | +| Port | Port | 5444 | The TCP port that the postmaster is listening on. | +| Protocol | Protocol | 7.4 | If specified, forces the driver to use the given protocol version. | +| Level of Rollback on Errors | Use the Protocol option to specify rollback behavior. | Transaction Level | Specifies how the driver handles errors:

0 - Don't rollback

1 - Rollback the transaction

2 - Rollback the statement | +| Usage Count | UsageCount | 1 | The number of installations using this driver. | +| Read Only | ReadOnly | No | Specifies that the connection is READONLY. | +| Show System Tables | ShowSystemTables | No | If enabled, the driver reports system tables in the result set of the SQLTables() function. | +| OID Options: Show Column | ShowOidColumn | No | If enabled, the SQLColumns() function reports the OID column. | +| OID Options: Fake Index | FakeOidIndex | No | If enabled, the SQLStatistics() function reports that a unique index exists on each OID column. | +| Keyset Query Optimization | Ksqo | On | If enabled, enforces server-side support for keyset queries (generated by the MS Jet database engine). | +| Recognize Unique Indexes | UniqueIndex | On | If enabled, the SQLStatistics() function will report unique indexes. If not enabled, the SQLStatistics() function reports that indexes allow duplicate values. | +| Use Declare/Fetch | UseDeclareFetch | Off | If enabled, the driver will use server-side cursors. To enable UseDeclareFetch, specify a value of 1; to disable UseDeclareFetch, specify a value of 0. | +| CommLog | CommLog | Off | If enabled, records all client/server traffic in a log file. | +| Parse Statements | Parse | Off | If enabled, the driver parses simple SELECT statements when you call the SQLNumResultCols(), SQLDescribeCol() or SQLColAttributes() functions. | +| Cancel as FreeStmt | CancelAsFreeStmt | Off | If enabled, the SQLCancel() function will call SQLFreeStmt(SQL_Close) on your behalf. | +| MyLog | Debug | Off | If enabled, the driver records its work in a log file. On Windows, the file name is C:m[ylog](<>)<process-id>; and on Linux the file name is /tmp/[mylog](<>)<username><process-id>.log. | +| Unknown Sizes | UnknownSizes | Maximum | Determines how the SQLDescribeCol() and SQLColAttributes() functions compute the size of a column. Specify 0 to force the driver to report the maximum size allowed for the type; specify 1 to force the driver to report an unknown length or 2 to force the driver to search the result set to find the longest value. Do not specify 2 if you have enabled UseDeclareFetch. | +| Text as LongVarchar | TextAsLongVarChar | 8190 | If enabled, the driver treats TEXT columns as if they are of type SQL_LONGVARCHAR. If disabled, the driver treats TEXT columns as SQL_VARCHAR values. | +| Unknown as Long Varchar | LongVarChar | False | If enabled, the driver treats values of unknown type as SQL_LONGVARCHAR values. If unchecked, the driver will treat values of unknown type as SQL_VARCHAR values. By default, values of unknown type are treated as Y values. | +| Bools as Char | BoolsAsChar | On | If enabled, the driver treats BOOL columns as SQL_CHAR values. If disabled, BOOL columns are treated as SQL_BIT values. | +| Max Varchar | MaxVarcharSize | 255 | If enabled, the driver treats VARCHAR and BPCHAR values longer than MaxVarCharSize as SQL_LONGVARCHAR values | +| Max Long Varchar Size | MaxLongVarcharSize | 8190 | If TextAsLongVarChar is on, the driver reports TEXT values are MaxLongVarcharSize bytes long.

If UnknownAsLongVarChar is on, columns of unknown type are MaxLongVarcharSize bytes long; otherwise, they are reported to be MaxVarcharSize bytes in length. | +| Cache Size | Fetch | 100 | Determines the number of rows fetched by the driver when UseDeclareFetch is enabled. | +| SysTable Prefixes | ExtraSysTablePrefixes | [dd](<>); | Use the SysTablePrefixes field to specify a semi-colon delimited list of prefixes that indicate that a table is a system table. By default, the list contains [dd](<>);. | +| Cumulative Row Count for Insert | MapSqlParcNoBatch | Off/0 | If enabled, the SQLRowCount() function will return a single, cumulative row count for the entire array of parameter settings for an INSERT statement. If disabled, an individual row count will be returned for each parameter setting. By default, this option is disabled. | +| LF<-> CR/LF conversion | LFConversion | System Dependent | The LF<->CR/LF conversion option instructs the driver to convert line-feed characters to carriage-return/line-feed pairs when fetching character values from the server and convert carriage-return/line-feed pairs back to line-feed characters when sending character values to the server. By default, this option is enabled. | +| Updatable Cursors | UpdatableCursors | Off | Permits positioned UPDATE and DELETE operations using the SQLSetPos() or SQLBulkOperations() functions. | +| Bytea as Long VarBinary | ByteaAsLongVarBinary | Off | If enabled, the driver treats BYTEA values as if they are of type SQL_LONGVARBINARY. If disabled, BYTEA values are treated as SQL_VARBINARY values. | +| Bytea as LO | ByteaAsLO | False | If enabled, the driver treats BYTEA values as if they are large objects. | +| Row versioning | RowVersioning | Off | The Row Versioning option specifies if the driver should include the xmin column when reporting the columns in a table. The xmin value is the ID of the transaction that created the row. You must use row versioning if you plan to create cursors where SQL_CONCURRENCY = SQL_CONCUR_ROWVER. | +| Disallow Premature | DisallowPremature | No/0 | Determines driver behavior if you try to retrieve information about a query without executing the query. If Yes, the driver declares a cursor for the query and fetches the meta-data from the cursor. If No, the driver executes the command as soon as you request any meta-data. | +| True is -1 | TrueIsMinus1 | Off/0 | TrueIsMinus1 tells the driver to return BOOL values of TRUE as -1. If this option is not enabled, the driver will return BOOL values of TRUE as 1. The driver always returns BOOL values of FALSE as 0. | +| Server side prepare | UseServerSidePrepare | No/0 | If enabled, the driver uses the PREPARE and EXECUTE commands to implement the Prepare/Execute model. | +| Use GSSAPI for GSS request | GssAuthUseGSS | False/0 | If set to True/1, the driver will send a GSSAPI authentication request to the server. Windows only. | +| Int8 As | BI | 0 | The value of BI determines how the driver treats BIGINT values:

If -5 as a SQL_BIGINT,

If 2 as a SQL_NUMERIC,

If 8 as a SQL_DOUBLE,

If 4 as a SQL_INTEGER,

If 12 as a SQL_VARCHAR,

If 0 (on an MS Jet client), as a SQL_NUMERIC,

If 0 on any other client, as a SQL_BIGINT. | +| Extra options

Connect Settings | AB

ConnSettings | 0x0 | 0x1 - Forces the output of short-length formatted connection strings. Specify this option if you are using the MFC CDatabase class.

0x2 - Allows MS Access to recognize PostgreSQL's serial type as AutoNumber type.

0x4 - Return ANSI character types for the inquiries from applications. Specify this option for applications that have difficulty handling Unicode data.

0x8 - If set, NULL dates are reported as empty strings and empty strings are interpreted as NULL dates on input.

0x10 - Determines if SQLGetInfo returns information about all tables, or only accessible tables. If set, only information is returned for accessible tables.

0x20 - If set, each SQL command is processed in a separate network round-trip, otherwise, SQL commands are grouped into as few round-trips as possible to reduce network latency. Contains a semicolon-delimited list of SQL commands that are executed when the driver connects to the server. | +| | Socket | 4096 | Specifies the buffer size that the driver uses to connect to the client. | +| | Lie | Off | If enabled, the driver claims to support unsupported ODBC features. | +| Lowercase Identifier | LowerCaseIdentifier | Off | If enabled, the driver translates identifiers to lowercase. | +| Disable Genetic Optimizer | Optimizer | Yes/1 | Disables the genetic query optimizer. | +| Allow Keyset | UpdatableCursors | Yes/1 | Allow Keyset driven cursors | +| SSL mode | SSLMode | Disabled | If libpq (and its dependencies) are installed in the same directory as the EDB-ODBC driver, enabling SSL Mode allows you to use SSL and other utilities. | +| Force Abbreviated Connection String | CX | No/0 | Enables the option to force abbreviation of connection string. | +| Fake MSS | FakeOidIndex | No/0 | Impersonates MS SQL Server enabling MS Access to recognize PostgreSQL’s serial type as AutoNumber type. | +| BDE Environment | BDE | No/0 | Enabling this option tunes EDB-ODBC to cater to Borland Database Engine compliant output (related to Unicode). | +| XA_Opt | INI_XAOPT | Yes/1 | If enabled, calls to SQL_TABLES only include user-accessible tables. | + +## Adding a Data Source Definition in Windows + +The Windows ODBC `Data Source Administrator` is a graphical interface that creates named data sources. You can open the `ODBC Data Source Administrator` by navigating to the `Control Panel`, opening the `Administrative Tools` menu, and double-clicking the appropriate `ODBC Data Sources` icon (`32- or 64- bit`). + +![The Windows Data Source Administrator](images/windows_data_source_administrator.png) + +The Windows Data Source Administrator + +Click the `Add` button to open the `Create New Data Source` dialog. Choose `EnterpriseDB (ANSI)` or `EnterpriseDB (UNICODE)` from the list of drivers and click `Finish`. + +![The Create New Data Source dialog](images/create_new_data_source.png) + +The Create New Data Source dialog + +The EnterpriseDB ODBC Driver dialog opens. + +![Define the data source](images/define_the_data_source.png) + +Define the data source + +Use the fields on the dialog to define the named data source: + +- Enter the Database name in the `Database` field. +- Enter the host name or IP address of Advanced Server in the `Server` field. +- Enter the name of a user in the `User Name` field. +- Enter a descriptive name for the named data source in the `Description` field. +- If libpq is installed in the same directory as the EDB-ODBC driver, the drop-down listbox next to the `SSL Mode` label will be active, allowing you to use SSL and other Advanced Server utilities. +- Accept the default port number (5444), or enter an alternative number in the `Port` field. +- Enter the password of the user in the `Password` field. + +Use the `Datasource` button (located in the `Options` box) to open the `Advanced Options` dialog and specify connection properties. + +The `Global` button opens a dialog on which you can specify logging options for the EDB-ODBC driver (not the data source, but the driver itself). + +![Page 1 of the Advanced Options dialog](images/advanced_options_1.png) + +Page 1 of the Advanced Options dialog + +- Check the box next to `Disable Genetic Optimizer` to disable the genetic query optimizer. By default, the query optimizer is `on`. +- Check the box next to `KSQO (Keyset Query Optimization)` to enable server-side support for keyset queries. By default, `Keyset Query Optimization` is `on`. +- Check the box next to `Recognize Unique Indexes` to force the `SQLStatistics()` function to report unique indexes; if the option is not checked, the `SQLStatistics()` function will report that all indexes allow duplicate values. By default, `Recognize Unique Indexes` is `on`. +- Check the box next to `Use Declare/Fetch` to specify that the driver should use server-side cursors whenever your application executes a `SELECT` command. By default, `Use Declare/Fetch` is `off`. +- Check the box next to `CommLog (C:\psqlodbc_xxxx.log)` to record all client/server traffic in a log file. By default, logging is `off`. +- Check the box next to `Parse Statements` to specify that the driver (rather than the server) should attempt to parse simple `SELECT` statements when you call the `SQLNumResultCols()`, `SQLDescribeCol()`, or `SQLColAttributes()` function. By default, this option is `off`. +- Check the box next to `Cancel as FreeStmt (Exp)` to specify that the `SQLCancel()` function should call `SQLFreeStmt(SQLClose)` on your behalf. By default, this option is `off`. +- Check the box next to `MyLog (C:\mylog_xxxx.log)` to record a detailed record of driver activity in a log file. The log file is named `c:\mylog\_\ *process-id*.log`. By default, logging is `off`. + +The radio buttons in the Unknown Sizes box specify how the `SQLDescribeCol()` and `SQLColAttributes()` functions compute the size of a column of unknown type (see Section `Supported Data Types` for a list of known data types). + +- Choose the button next to `Maximum` to specify that the driver report the maximum size allowed for a `VARCHAR` or `LONGVARCHAR` (dependent on the `Unknowns as LongVarChar` setting). If `Unknowns as LongVarChar` is enabled, the driver returns the maximum size of a `LONGVARCHAR` (specified in the `Max LongVarChar` field in the `Miscellaneous` box). If `Unknowns as LongVarChar` is not enabled, the driver returns the size specified in the `Max VarChar` field (in the `Miscellaneous` box). +- Choose the button next to `Don’t know` to specify that the driver report a length of "unknown". +- Choose the button next to `Longest` to specify that the driver search the result set and report the longest value found. (Note: you should not specify `Longest` if `UseDeclareFetch` is enabled.) + +The properties in the `Data Type Options` box determine how the driver treats columns of specific types: + +- Check the box next to `Text as LongVarChar` to treat `TEXT` values as if they are of type `SQL_LONGVARCHAR`. If the box is not checked, the driver will treat `TEXT` values as `SQL_VARCHAR` values. By default, `TEXT` values are treated as `SQL_LONGVARCHAR` values. +- Check the box next to `Unknowns as LongVarChar` to specify that the driver treat values of unknown type as `SQL_LONGVARCHAR` values. If unchecked, the driver will treat values of unknown type as `SQL_VARCHAR` values. By default, values of unknown type are treated as `SQL_VARCHAR` values. +- Check the box next to `Bools as Char` to specify that the driver treat `BOOL` values as `SQL_CHAR` values. If unchecked, `BOOL` values are treated as `SQL_BIT` values. By default, `BOOL` values are treated as `SQL_CHAR` values. + +You can specify values for some of the properties associated with the named data source in the fields in the `Miscellaneous` box: + +- Indicate the maximum length allowed for a `VARCHAR` value in the Max `VarChar` field. By default, this value is set to `255`. +- Enter the maximum length allowed for a `LONGVARCHAR` value in the Max `LongVarChar` field. By default, this value is set to `8190`. +- Specify the number of rows fetched by the driver (when `UseDeclareFetch` is enabled) in the `Cache Size` field. The default value is `100`. +- Use the `SysTablePrefixes` field to specify a semi-colon delimited list of prefixes that indicate that a table is a system table. By default, the list contains `dd_`;. + +You can reset the values on this dialog to their default settings by choosing the `Defaults` button. + +Click the `Apply` button to apply any changes to the data source properties, or the `Cancel` button to exit the dialog without applying any changes. Choose the `OK` button to apply any changes to the dialog and exit. + +Select the `Page 2` button (in the upper-left hand corner of the `Advanced Options` dialog) to access a second set of advanced options. + +![Page 2 of the Advanced Options dialog](images/odbc_advanced_options_2.png) + +Page 2 of the Advanced Options dialog + +- Check the box next to `Read Only` to prevent the driver from executing the following commands: `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `ALTER`, `DROP`, `GRANT`, `REVOKE` or `LOCK`. Invoking the `Read Only` option also prevents any calls that use ODBC’s procedure call escape syntax (`call=procedure-name?`). By default, this option is `off`. +- Check the box next to `Show System Tables` to include system tables in the result set of the `SQLTables()` function. If the option is enabled, the driver will include any table whose name starts with `pg\_` or any of the prefixes listed in the `SysTablePrefixes` field of `Page 1` of the `Advanced Options` dialog. By default, this option is `off`. +- Check the box next to `Show sys/dbo Tables [Access]` to access objects in the `sys` schema and `dbo` schema through the ODBC data source. By default, this option is enabled (checked). +- Check the box next to `Cumulative Row Count for Insert` to cause a single, cumulative row count to be returned for the entire array of parameter settings for an `INSERT` statement when a call to the `SQLRowCount()` method is performed. If this option is not enabled (the box is not checked), then an individual row count is available for each parameter setting in the array, and thus, a call to `SQLRowCount()` returns the count for the last inserted row. +- Check the box next to `LF<->CR/LF` conversion to instruct the driver to convert line-feed characters to carriage-return/line-feed pairs when fetching character values from the server and convert carriage-return/line-feed pairs back to line-feed characters when sending character values to the server. By default, this option is enabled. +- Check the box next to `Updatable Cursors` to specify that the driver should permit positioned `UPDATE` and `DELETE` operations with the `SQLSetPos()` or `SQLBulkOperations()` functions. By default, this option is enabled. +- Check the box next to `bytea as LO` to specify that the driver should treat `BYTEA` values as if they are `SQL_LONGVARBINARY` values. If the box is not checked, EDB-ODBC will treat `BYTEA` values as if they are `SQL_VARBINARY` values. By default, `BYTEA` values are treated as `SQL_VARBINARY` values. +- Check the box next to `Row Versioning` to include the `xmin` column when reporting the columns in a table. The `xmin` column is the ID of the transaction that created the row. You must use row versioning if you plan to create cursors where `SQL_CONCURRENCY = SQL_CONCUR_ROWVER`. By default, `Row Versioning` is `off`. +- Check the box next to `Disallow Premature` to specify that the driver should retrieve meta-data about a query (i.e., the number of columns in a result set, or the column types) without actually executing the query. If this option is not specified, the driver executes the query when you request meta-data about the query. By default, `Disallow Premature` is off. +- Check the box next to `True is -1` to tell the driver to return `BOOL` values of `True` as a `-1`. If this option is not enabled, the driver will return `BOOL` values of `True` as `1`. The driver always returns `BOOL` values of `False` as `0`. +- Check the box next to `Server side prepare` to tell the driver to use the `PREPARE` and `EXECUTE` commands to implement the `Prepare/Execute` model. By default, this box is checked. +- Check the box next to `use gssapi for GSS request` to instruct the driver to send a GSSAPI connection request to the server. +- Enter the database system (either `EnterpriseDB` or `PostgreSQL`) in the `dbms_name` field. The value entered here is returned in the `SQL_DBMS_NAME` argument when the `SQLGetInfo()` function is called. The default is `EnterpriseDB`. + +Use the radio buttons in the `Int8` As box to specify how the driver should return `BIGINT` values to the client. Select the radio button next to `default` to specify the default type of `NUMERIC` if the client is MS Jet, `BIGINT` if the client is any other ODBC client. You can optionally specify that the driver return `BIGINT` values as a `bigint (SQL_BIGINT)`, `numeric (SQL_NUMERIC)`, `varchar (SQL_VARCHAR)`, `double (SQL_DOUBLE)`, or `int4 (SQL_INTEGER)`. + +The default value of the `Extra Opts` field is `0x0`. `Extra Opts` may be: + +| Option | Specifies | +| ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0x1 | Forces the output of short-length formatted connection string. Select this option when you are using the MFC CDatabase class. | +| 0x2 | Allows MS Access to recognize PostgreSQL's serial type as AutoNumber type. | +| 0x4 | Return ANSI character types for the inquiries from applications. Select this option for applications that have difficulty handling Unicode data. | +| 0x8 | If set, NULL dates are reported as empty strings and empty strings are interpreted as NULL dates on input. | +| 0x10 | Determines if SQLGetInfo returns information about all tables, or only accessible tables. If set, only information is returned for accessible tables. | +| 0x20 | If set, each SQL command is processed in a separate network round-trip, otherwise, SQL commands are grouped into as few round-trips as possible to reduce network latency. | + +The `Protocol` box contains radio buttons that tell the driver to interact with the server using a specific front-end/back-end protocol version. By default, the `Protocol` selected is `7.4+`; you can optionally select from versions `6.4+`, `6.3` or `6.2`. + +The `Level of Rollback on errors` box contains radio buttons that specify how the driver handles error handling: + +| Option | Specifies | +| ----------- | -------------------------------------------------------------------------------------------------------------------------- | +| Transaction | If the driver encounters an error, it will rollback the current transaction. | +| Statement | If the driver encounters an error, it will rollback the current statement. | +| Nop | If the driver encounters an error, you must manually rollback the current transaction before the application can continue. | + +The `OID Options` box contains options that control the way the driver exposes the OID column contained in some tables: + +- Check the box next to `Show Column` to include the `OID` column in the result set of the `SQLColumns()` function. If this box is not checked, the `OID` column is hidden from `SQLColumns()`. +- Check the box next to `Fake Columns` to specify that the `SQLStatistics()` function should report that a unique index exists on each `OID` column. + +Use the `Connect Settings` field to specify a list of parameter assignments that the driver will use when opening this connection. Any configuration parameter that you can modify with a `SET` statement can be included in the semi-colon delimited list. For example: + +`set search_path to company1,public;` + +When you’ve defined the connection properties for the named data source, click the `Apply` button to apply the options; you can optionally exit without saving any options by choosing `Cancel`. Select the `OK` button to save the options and exit. + +Choose the `Global` button (on the `EnterpriseDB ODBC Driver` dialog) to open the `Global Settings` dialog. The options on this dialog control logging options for the EDB-ODBC driver. Use this dialog to enforce logging when the driver is used without a named data source, or for logging driver operations that occur before the connection string is parsed. + +![The Global Settings dialog](images/global_settings.png) + +The Global Settings dialog + +- Check the box next to the `CommLog` field to record all client/server traffic in a log file. The logfile is named `C:\psqlodbc_process-id` where `process-id` is the name of the process in use. +- Check the box next to the `Mylog` field to keep a logfile of the driver’s activity. The logfile is named `c:\mylog_process-id` where `process-id` is the name of the process in use. +- Specify a location for the logfiles in the `Folder for logging` field. + +When you’ve entered the connection information for the named data source, click the `Test` button to verify that the driver manager can connect to the defined data source. + +![The Connection is successful](images/connection_is_successful.png) + +The Connection is successful + +Click the OK button to exit `Connection Test` dialog. If the connection is successful, click the `Save` button to save the named data source. If there are problems establishing a connection, adjust the parameters and test again. + +## Adding a Data Source Definition in Linux + +The Linux `ODBC Administrator` is a graphical tool that is distributed with unixODBC; you can use the `ODBC Administrator` to manage ODBC drivers and named resources. To add the ODBC Administrator to your system, open a terminal window, assume superuser privileges, and enter: + + `yum install unixODBC` + +followed by: + + `yum install unixODBC-kde` + +To invoke the `ODBC Administrator`, open a terminal window and enter ODBCConfig. + +![The unixODBC Data Source Administrator](images/unixodbc_data_source_administrator.png) + +The unixODBC Data Source Administrator + +When you install the Advanced Server `Connectors` component, the EDB-ODBC driver is added to the list of drivers in the ODBC Administrator. Click `Advanced`, and then select the `Drivers` tab to verify that the `enterprisedb` driver appears in the list. + +![The Drivers tab shows the installed EDB-ODBC driver](images/installed_edb-odbc_driver.png) + +The Drivers tab shows the installed EDB-ODBC driver + +If the EDB-ODBC driver does not appear in the list of drivers, you can add it using the `ODBC Administrator`. To add a driver definition, select the `Drivers` tab, and click `Add`. The `Driver Properties (new)` window opens, as shown below: + +![The Driver Properties window](images/driver_properties_window.png) + +The Driver Properties window + +Complete the `Driver Properties` window to register the EDB-ODBC driver with the driver manager: + +- Add a unique name for the driver to the `Name` field. + +- Add a driver description to the `Description` field. + +- Add the path to the location of the EDB-ODBC driver in the `Driver` field. By default, the complete path to the driver is: + + `/usr/edb/odbc/lib/edb-odbc.so` + +- Add the path to the location of the EDB-ODBC driver setup file in the `Setup` field. By default, the complete path to the driver setup file is: + + `/usr/edb/odbc/lib/libodbcedbS.so` + +When you’ve described the driver properties for the EDB-ODBC driver, click `OK`. The ODBC Data Source Administrator window now includes the EDB-ODBC driver in the list of available ODBC drivers. + +![The Drivers tab shows the new driver definition](images/new_driver_definition.png) + +The Drivers tab shows the new driver definition + +With the EDB-ODBC driver available to the driver manager, you can add a data source. Click the `Data Source` Names option in the left panel, and then choose the appropriate DSN tab for the type of data source name you would like to add: + +- Choose the `User` tab to add a named data source that is available only to the current user (the data source will be stored in `/user/.odbc.ini`). +- Choose the `System` tab add a named data source that is available to all users. All system data sources are stored in a single file (usually `/etc/odbc.ini`). +- Choose the `File` tab to add a named data source that is available to all users, but that is stored in a file of your choosing. + +Select the appropriate tab and click `Add`. The `Create a New Data Source…` window opens, as shown below: + +![Select a driver for the named data source](images/select_driver_named_date_source.png) + +Select a driver for the named data source + +Select the EDB-ODBC driver from the list, and click `OK` to open the `Data Source Properties` window. + +Complete the `Data Source Properties (new)` window, specifying the connection properties for the EDB-ODBC driver. + +![The Data Source Properties window](images/data_source_properties_window.png) + +The Data Source Properties window + +- Enter the data source name in the `Name` field. +- Enter a description of the named data source in the `Description` field. +- The unixODBC driver includes a trace utility that records the sequence of calls made an ODBC application to a log file. Specify `Yes` in the `Trace` field to turn the trace utility on. Note that using the trace utility can slow down an application. +- Use the `TraceFile` field to specify a file to receive information returned by the `Trace` utility. +- Enter the name of the Advanced Server database in the `Database` field. +- Enter the host name or IP address of Advanced Server in the `Servername` field. +- Enter the name of a user in the `Username` field. +- Enter the password for the user in the `Password` field. +- Enter a port number (or accept the default value of `5444`) in the `Port` field. +- Use the `Protocol` field to specify a front-end/back-end protocol version; the default value is `7.4`. You can optionally select from protocol versions `7.4`, `6.4`, `6.3` or `6.2`. +- Use the `ReadOnly` field to specify `Yes` to prevent the driver from executing the following commands: `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `ALTER`, `DROP`, `GRANT`, `REVOKE` or `LOCK`. Enabling the `Read Only` option also prevents any calls that use the ODBC procedure call escape syntax (`call=procedure-name?`). By default, `ReadOnly` is set to `No`. +- Use the `RowVersioning` field to specify `Yes` if the driver should include the `xmin` column when reporting the columns in a table. The `xmin` column is the ID of the transaction that created the row. You must use row versioning if you plan to create cursors where `SQL_CONCURRENCY = SQL_CONCUR_ROWVER`. By default, `Row Versioning` is set to `No`. +- Use the `ShowSystemTables` field to specify `Yes` if the driver should include system tables in the result set of the `SQLTables()` function. By default, this field is set to `No`. +- Use the `ShowOidColumn` field to specify `Yes` if the driver should include the `OID` column in the result set of the `SQLColumns()` function. If `ShowOidColumn` is set to `No`, the `OID` column is hidden from `SQLColumns()`. By default, this option is set to `No`. +- Use the `FakeOidIndex` field to specify Yes if the `SQLStatistics()` function should report that a unique index exists on each `OID` column. This is useful when your application needs a unique identifier and your table doesn’t include one. The default value is `No`. +- Use the `ConnSettings` field to specify a list of parameter assignments that the driver will use when opening this connection. + +When you’ve defined the connection properties, click `OK`. + +The new data source is added to the list of data source names: + +![The new data source is included on the Data Source Names list](images/data_source_names.png) + +The new data source is included on the Data Source Names list diff --git a/product_docs/docs/odbc_connector/12.0.0.2/06_edb-odbc_driver_functionality.mdx b/product_docs/docs/odbc_connector/12.0.0.2/06_edb-odbc_driver_functionality.mdx new file mode 100644 index 00000000000..2654ee9fbaf --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/06_edb-odbc_driver_functionality.mdx @@ -0,0 +1,751 @@ +--- +title: "EDB-ODBC Driver Functionality" + +legacyRedirectsGenerated: + # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/edb-odbc_driver_functionality.html" +--- + +You can use ODBC functions to query ODBC for specific information about the various attributes of the connection between EDB-ODBC and the server. + +- `SQLGetInfo()` returns information about the EDB-ODBC driver and Advanced Server. +- `SQLGetEnvAttr()` returns information about ODBC environment attributes. +- `SQLGetConnectAttr()` returns information about attributes specific to an individual connection. +- `SQLGetStmtAttr()` returns information about the attributes specific to an individual statement. + +You can also use ODBC functions to set various attributes of the objects that you use to interface with ODBC: + +- Use the `SQLSetConnectAttr()` function to set connection attributes. +- Use the `SQLSetEnvAttr()` function to set environment attributes. +- Use the `SQLSetStmtAttr()` function to set statement attributes. + +## SQLGetInfo() + +The ODBC `SQLGetInfo()` function returns information about the EDB-ODBC driver and Advanced Server. You must have an open connection to call `SQLGetInfo()`, unless you specify `SQL_ODBC_VER` as the `info_type`. The signature for `SQLGetInfo()` is: + +```c++ +SQLRETURN SQLGetInfo +( + SQLHDBC conn_handle , // Input + SQLUSMALLINT info_type , // Input + SQLPOINTER info_pointer , // Output + SQLSMALLINT buffer_len , // Input + SQLSMALLINT * string_length_pointer // Output +); +``` + +- `conn_handle` The connection handle. + +- `info_type` The type of information SQLGetInfo() is retrieving. + +- `info_pointer` A pointer to a memory buffer that will hold the retrieved value. + + If the `info_type` argument is `SQL_DRIVER_HDESC` or `SQL_DRIVER_HSTMT`, the `info_pointer` argument is both `Input` and `Output`. + +- `buffer_len` is the length of the allocated memory buffer pointed to by `info_pointer`. If `info_pointer` is `NULL`, `buffer_len` is ignored. If the returned value is a fixed size, `buffer_len` is ignored. `buffer_len` is only used if the requested value is returned in the form of a character string. + +- `string_length_pointer` is a pointer to an `SQLSMALLINT` value. `SQLGetInfo()` writes the size of the requested value in this integer. + +A typical usage is to call `SQLGetInfo()` with a `NULL info_pointer` to obtain the length of the requested value, allocate the required number of bytes, and then call `SQLGetInfo()` again (providing the address of the newly allocated buffer) to obtain the actual value. The first call retrieves the number of bytes required to hold the value; the second call retrieves the value. + +If the size of the returned value exceeds `buffer_len`, the information is truncated and `NULL` terminated. If the returned value is a fixed size, `string_length` is ignored (and the size of the requested value is not provided by `SQLGetInfo()`). + +`SQLGetInfo()` writes information in one of the following formats: + +- a `SQLUINTEGER` bitmask +- a `SQLUINTEGER` flag +- a `SQLUINTEGER` binary value +- a `SQLUSMALLINT` value +- a `NULL` terminated character string + +`SQLGetInfo()` returns `SQL_SUCCESS`, `SQL_SUCCESS_WITH_INFO`, `SQL_ERROR`, or `SQL_INVALID_HANDLE`. + +The following table lists the information returned by EDB-ODBC about the Advanced Server connection: + +| **SQL info_type Argument and Description** | **EDB_ODBC/Advanced Server Returns:** | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| SQL_ACCESSIBLE_PROCEDURES: Indicates if procedures returned by SQLProcedures()can be executed by the application. | Returns N. Some procedures executed by the SQLProcedures() function may be executed by the application. | +| SQL_ACCESSIBLE_TABLES: Indicates if the user has SELECT privileges on all table names returned by SQLTables(). | Returns N. The user may not have select privileges on one or more tables returned by the SQLTables() function. | +| SQL_ACTIVE_CONNECTIONS prev. SQL_MAX_DRIVER_CONNECTIONS: Indicates the maximum number of connections EDB-ODBC can support. | Returns 0. There is no specified limit to the number of connections allowed. | +| SQL_ACTIVE_ENVIRONMENTS: The number of active environments EDB-ODBC can support. | Returns 0. There is no specified limit to the number of environments allowed. | +| SQL_ACTIVE_STATEMENTS prev. SQL_MAX_CONCURRENT_ACTIVITIES: Indicates the maximum number of active statements EDB-ODBC can support. | Returns 0. There is no specified limit to the number of active statements allowed. | +| SQL_AGGREGATE_FUNCTION: Identifies the aggregate functions supported by the server and driver. | Returns SQL_AF_ALL | +| SQL_ALTER_DOMAIN: Identifies the ALTER DOMAIN clauses supported by the server. | Returns 0. ALTER DOMAIN clauses are not supported. | +| SQL_ALTER_TABLE: Identifies the ALTER TABLE clauses supported by the server. | Returns SQL_AT_ADD_COLUMN, SQL_AT_DROP_TABLE_CONSTRAINT_CASCADE, SQL_AT_DROP_TABLE_CONSTRAINT, SQL_AT_CONSTRAINT_INITIALLY_DEFERRED, SQL_AT_CONSTRAINT_INITIALLY_IMMEDIATE, SQL_AT_CONSTRAINT_DEFERRABLE | +| SQL_ASYNC_MODE: Level of Asynchronous Mode Supported by EDB-ODBC. | Returns SQL_AM_NONE. Asynchronous mode is not supported. | +| SQL_BATCH_ROW_COUNT: Indicates how the driver returns row counts. | Returns SQL_BRC_EXPLICIT. Row Counts are available when executed by calling SQLExecute or SQLExecDirect. | +| SQL_BATCH_SUPPORT: Indicates support for batch statement execution. | Returns: SQL_BS_SELECT_EXPLICIT, SQL_BS_ROW_COUNT_EXPLICIT. The driver supports explicit batches with result set and row count generating statements. | +| SQL_BOOKMARK_PERSISTENCE: Indicates level of support for bookmarks. | Returns: SQL_BP_DELETE, SQL_BP_TRANSACTION, SQL_BP_UPDATE, SQL_BP_SCROLL. | +| SQL_CATALOG_LOCATION Now SQL_QUALIFIER_LOCATION: Indicates the position of the catalog in a qualified table name. | Returns SQL_CL_START. The catalog portion of a qualified table name is at the beginning of the name. | +| SQL_CATALOG_NAME Now SQL_QUALIFIER_NAME: Indicates support for catalog names. | Returns Y. The server supports catalog names. | +| SQL_CATALOG_NAME_SEPARATOR Now SQL_QUALIFIER_NAME_SEPARATOR: Character separating the catalog name from the adjacent name element. | Returns '.' The server expects a '.' character between the qualifier and the table name. | +| SQL_CATALOG_TERM Now SQL_QUALIFIER_TERM: The term used to describe a catalog. | Returns catalog. | +| SQL_CATALOG_USAGE Now SQL_QUALIFIER_USAGE: Indicates the SQL statements that may refer to catalogs. | Returns SQL_CU_DML_STATEMENTS. Catalog names can be used in SELECT, INSERT, UPDATE, DELETE, SELECT FOR UPDATE and positioned UPDATE and DELETE statements. | +| SQL_COLLATION_SEQ: Returns the name of the Collation Sequence. | Returns an empty string. The name of the default collation is unknown. | +| SQL_COLUMN_ALIAS: Indicates server support for column aliases. | Returns Y. The server supports column aliases. | +| SQL_CONCAT_NULL_BEHAVIOR: Indicates how the server handles concatenation of NULL values. | Returns SQL_CB_NON_NULL. Concatenation of a NULL value and a non NULL value will result in a NULL value. | +| SQL_CONVERT_BIGINT: Indicates conversion support from the BIGINT type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_BINARY: Indicates conversion support from the BINARY type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_BIT: Indicates conversion support from the BIT type using the CONVERT function. | Returns: SQL_CVT_INTEGER, SQL_CVT_BIT. | +| SQL_CONVERT_CHAR: Indicates conversion support from the CHAR type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_DATE: Indicates conversion support from the DATE type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_DECIMAL: Indicates conversion support from the DECIMAL type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_DOUBLE: Indicates conversion support from the DOUBLE type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_FLOAT: Indicates conversion support from the FLOAT type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_FUNCTIONS: Lists the scalar conversion functions supported by the server and driver using the CONVERT function. | Returns: SQL_FN_CVT_CONVERT. | +| SQL_CONVERT_INTEGER: Lists the conversion support from the INTEGER type using the CONVERT function. | Returns: SQL_CVT_INTEGER, SQL_CVT_BIT. | +| SQL_CONVERT_INTERVAL_DAY_TIME: Indicates conversion support from the INTERVAL_DAY_TIME type using the CONVERT function. | This info_type is not currently supported. | +| SQL_CONVERT_INTERVAL_YEAR_MONTH: Indicates conversion support from the INTERVAL_YEAR_MONTH type using the CONVERT function. | This info_type is not currently supported. | +| SQL_CONVERT_LONGVARBINARY: Indicates conversion support for the LONG_VARBINARY type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_LONGVARCHAR: Indicates conversion support for the LONGVARCHAR type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_NUMERIC: Indicates conversion support for the NUMERIC type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_REAL: Indicates conversion support for the REAL type using the CONVERT function | Returns 0. The server does not support conversion. | +| SQL_CONVERT_SMALLINT: Indicates conversion support for the SMALLINT type using the CONVERT function. | Returns: SQL_CVT_INTEGER, SQL_CVT_BIT. | +| SQL_CONVERT_TIME: Indicates conversion support for TIME type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CVT_TIMESTAMP: Indicates conversion support for TIMESTAMP type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_TINYINT: Indicates conversion support for the TINYINT type using the CONVERT function. | Returns: SQL_CVT_INTEGER, SQL_CVT_BIT. | +| SQL_CONVERT_VARBINARY: Indicates conversion support for the VARBINARY type using the CONVERT function. | Returns 0. The server does not support conversion. | +| SQL_CONVERT_VARCHAR: Indicates conversion support for VARCHAR type using the CONVERT function. | Returns: SQL_CVT_INTEGER, SQL_CVT_BIT. | +| SQL_CONVERT_WCHAR: Indicates conversion support for the WCHAR type using the CONVERT function. | This info_type is valid only when using the Unicode driver. Returns 0. The server does not support conversion. | +| SQL_CONVERT_WLONGVARCHAR: Indicates conversion support for the WLONGVARCHAR type using the CONVERT function. | This info_type is valid only when using the Unicode driver. Returns 0. The server does not support conversion. | +| SQL_CONVERT_WVARCHAR: Indicates conversion support for the WVARCHAR type using the CONVERT function. | This info_type is valid only when using the Unicode driver. Returns 0. The server does not support conversion. | +| SQL_CORRELATION_NAME: Indicates server support for correlation names. | Returns SQL_CN_ANY. Correlation names are supported and can be any valid name. | +| SQL_CREATE_ASSERTION: Indicates support for the CREATE ASSERTION statement. | Returns 0. The CREATE ASSERTION statement is not supported. | +| SQL_CREATE_CHARACTER_SET: Indicates support for CREATE CHARACTER statement. | Returns 0. The CREATE CHARACTER statement is not supported. | +| SQL_CREATE_COLLATION: Indicates support for the CREATE COLLATION. | Returns 0. The CREATE COLLATION statement is not supported. | +| SQL_CREATE_DOMAIN: Indicates support for the CREATE DOMAIN statement. | Returns 0. The CREATE DOMAIN statement is not supported. | +| SQL_CREATE_SCHEMA: Indicates support for the CREATE SCHEMA statement. | Returns: SQL_CS_CREATE_SCHEMA, SQL_CS_AUTHORIZATION. | +| SQL_CREATE_TABLE: Indicates support for the CREATE TABLE statement. | Returns: SQL_CT_CREATE_TABLE, SQL_CT_GLOBAL_TEMPORARY, SQL_CT_CONSTRAINT_INITIALLY_DEFERRED, SQL_CT_CONSTRAINT_INITIALLY_IMMEDIATE, SQL_CT_CONSTRAINT_DEFERRABLE, SQL_CT_COLUMN_CONSTRAINT, SQL_CT_COLUMN_DEFAULT, SQL_CT_TABLE_CONSTRAINT, SQL_CT_CONSTRAINT_NAME_DEFINITION | +| SQL_CREATE_TRANSLATION: Indicates support for the CREATE TRANSLATION statement. | Returns 0. The CREATE TRANSLATION statement is not supported. | +| SQL_CREATE_VIEW: Indicates support for the CREATE VIEW statement. | Returns SQL_CV_CREATE_VIEW. | +| SQL_CURSOR_COMMIT_BEHAVIOR: Indicates how a COMMIT operation affects the cursor. | Returns SQL_CB_PRESERVE. Cursors are unchanged, and can continue to fetch data. | +| SQL_CURSOR_ROLLBACK_BEHAVIOR: Indicates the server behavior after a ROLLBACK operation. | Returns SQL_CB_PRESERVE. Cursors are unchanged, and can continue to fetch data. | +| SQL_CURSOR_SENSITIVITY:Indicates how the server synchronizes changes to a result set. | This info_type is not currently supported. | +| SQL_DATA_SOURCE_NAME: Returns the server name used during connection. | The value returned is determined by the connection properties. | +| SQL_DATA_SOURCE_READ_ONLY: Indicates if the connection is in READ ONLY mode. | The value returned is determined by the connection properties. | +| SQL_DATABASE_NAME: Returns the name of the database. | The value returned is determined by the connection properties. | +| SQL_DATETIME_LITERALS: Indicates the DATETIME LITERALS supported by the server. | This info_type is not supported. | +| SQL_DBMS_NAME: Returns the name of the DBMS system. | Returns the value given by the dbms_name parameter from the odbc.ini file on Linux or the dbms_name field of page 2 of the Advanced Options dialog box when defining a data source in Windows. The default is EnterpriseDB. | +| SQL_DBMS_VER: Returns the server version. | Determined by the server. | +| SQL_DDL_INDEX: Indicates support for creating and dropping indexes. | Returns: SQL_DI_CREATE_INDEX, SQL_DI_DROP_INDEX. | +| SQL_DEFAULT_TXN_ISOLATION: Indicates support for transaction isolation by the server. | Returns TXN_READ_COMMITTED. Non-repeatable or phantom reads are possible; Dirty reads are not. | +| SQL_DESCRIBE_PARAMETER: Indicates support for the DESCRIBE INPUT statement. | Returns N. The DESCRIBE INPUT statement is not supported. | +| SQL_DM_VER: The version of the Driver Manager. | Determined by driver manager. | +| SQL_DRIVER_HDBC: The Driver's connection handle. | Returns an SQLULEN value that contains the driver’s connection handle. | +| SQL_DRIVER_HDESC: The Driver descriptor handle. | Returns an SQLULEN value that contains driver’s descriptor handle. | +| SQL_DRIVER_HENV: The Driver's environment handle. | Returns an SQLULEN value that contains the driver’s environment handle. | +| SQL_DRIVER_HLIB: The Driver handle. | Returns an SQLULEN value that contains the library handle (returned to the ODBC driver manager when the manager loaded the driver). | +| SQL_DRIVER_HSTMT: The Driver's statement handle. | Returns an SQLULEN value that contains the driver’s statement handle. | +| SQL_DRIVER_NAME: The name of the driver. | Returns EDB-ODBC.DLL | +| SQL_DRIVER_ODBC_VER: Identifies the ODBC version that the driver supports. | Returns 03.50 | +| SQL_DRIVER_VER: Identifies the driver version. | Returns 9.0.0.6 | +| SQL_DROP_ASSERTION: Lists the DROP ASSERTION clauses supported by the server. | Returns 0 | +| SQL_DROP_CHARACTER_SET: Lists the DROP CHARACTER clauses supported by the server. | Returns 0 | +| SQL_DROP_COLLATION: Lists the DROP COLLATION clauses supported by the server. | Returns 0 | +| SQL_DROP_DOMAIN: Lists the DROP DOMAIN clauses supported by the server. | Returns 0 | +| SQL_DROP_SCHEMA: Lists the DROP SCHEMA clauses supported by the server. | Returns: SQL_DS_DROP_SCHEMA, SQL_DS_RESTRICT, SQL_DS_CASCADE. | +| SQL_DROP_TABLE: Lists the DROP TABLE clauses supported by the server. | Returns: SQL_DT_DROP_TABLE, SQL_DS_RESTRICT, SQL_DS_CASCADE. | +| SQL_DROP_TRANSLATION: Lists the DROP TRANSLATION clauses supported by the server. | Returns 0. | +| SQL_DROP_VIEW: Lists the DROP VIEW clauses supported by the server. | Returns: SQL_DV_DROP_VIEW, SQL_DS_RESTRICT, SQL_DS_CASCADE. | +| SQL_DYNAMIC_CURSOR_ATTRIBUTES1: Describes the first set of dynamic cursor attributes supported by the driver. | Returns 0 | +| SQL_DYNAMIC_CURSOR_ATTRIBUTES2: Describes the second set of dynamic cursor attributes supported by the driver. | Returns 0 | +| SQL_EXPRESSIONS_IN_ORDERBY: Indicates server support for ORDER BY. | Returns Y. | +| SQL_FETCH_DIRECTION: Indicates FETCH order options (deprecated in ODBC 3.0). | Returns: SQL_FD_FETCH_NEXT, SQL_FD_FETCH_FIRS, SQL_FD_FETCH_LAST, SQL_FD_FETCH_PRIOR, SQL_FD_FETCH_ABSOLUTE, SQL_FD_FETCH_RELATIVE, SQL_FD_FETCH_BOOKMARK. | +| SQL_FILE_USAGE: Indicates how a single-tier driver treats files on the server. | Returns SQL_FILE_NOT_SUPPORTED. The driver is not a single-tier file. | +| SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES1: Describes the forward-only cursor attributes supported by the driver. | Returns SQL_CA1_NEXT. | +| SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES2: Describes extended attributes for the forward-only cursor designated by SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES1. | Returns: SQL_CA2_READ_ONLY_CONCURRENCY, SQL_CA2_CRC_EXACT. | +| SQL_GETDATA_EXTENSIONS: Lists supported extensions to SQLGetData. | Returns: SQL_GD_ANY_COLUMN, SQL_GD_ANY_ORDER, SQL_GD_BLOCK, SQL_GD_BOUND. | +| SQL_GROUP_BY: Indicates the relationship between a GROUP BY clause and columns in the SELECT list. | Returns SQL_GB_GROUP_BY_EQUALS_SELECT. | +| SQL_IDENTIFIER_CASE: Indicates case-sensitivity and case-storage of SQL identifiers. | Returns SQL_IC_LOWER. | +| SQL_INDEX_KEYWORDS: Indicates support for the CREATE INDEX statement. | Returns SQL_IK_NONE. | +| SQL_INFO_SCHEMA_VIEWS: Lists the views supported in the INFORMATION_SCHEMA. | Returns 0. | +| SQL_INTEGRITY Prev. SQL_ODBC_SQL_OPT_IEF: Indicates server support for referential integrity syntax checking. | Returns N. | +| SQL_INSERT_STATEMENT: Indicates level of support for the INSERT statement. | Returns: SQL_IS_INSERT_LITERALS, SQL_IS_INSERT_SEARCHED, SQL_IS_SELECT_INTO. | +| SQL_KEYSET_CURSOR_ATTRIBUTES1: Describes the first set of keyset cursor attributes supported by the driver. | Returns: SQL_CA1_NEXT, SQL_CA1_ABSOLUTE, SQL_CA1_RELATIVE, SQL_CA1_BOOKMARK, SQL_CA1_LOCK_NO_CHANGE, SQL_CA1_POS_POSITION, SQL_CA1_POS_UPDATE, SQL_CA1_POS_DELETE, SQL_CA1_POS_REFRESH, SQL_CA1_BULK_ADD, SQL_CA1_BULK_UPDATE_BY_BOOKMARK, SQL_CA1_BULK_DELETE_BY_BOOKMARK, SQL_CA1_BULK_FETCH_BY_BOOKMARK. | +| SQL_KEYSET_CURSOR_ATTRIBUTES2: Describes the second set of keyset cursor attributes supported by the driver. | Returns: SQL_CA2_READ_ONLY_CONCURRENCY, SQL_CA2_OPT_ROWVER_CONCURRENCY, SQL_CA2_SENSITIVITY_ADDITIONS, SQL_CA2_SENSITIVITY_DELETIONS, SQL_CA2_SENSITIVITY_UPDATES, SQL_CA2_CRC_EXACT. | +| SQL_KEYWORDS: Identifies the server specific reserved keywords. | Returns “”. There are no server specific reserved keywords. | +| SQL_LIKE_ESCAPE_CLAUSE: Indicates support for an escape character in LIKE predicates. | Returns N. Advanced Server does not support escape characters in LIKE predicates. | +| SQL_LOCK_TYPES: Lists supported lock types (deprecated in ODBC 3.0). | Returns SQL_LCK_NO_CHANGE. | +| SQL_MAX_ASYNC_CONCURRENT_STATEMENTS: The number of active concurrent statements that the driver can support. | This info_type is currently unsupported. | +| SQL_MAX_BINARY_LITERAL_LEN: The maximum length of a binary literal. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_CATALOG_NAME_LEN: The maximum length of a catalog name on the server. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_QUALIFIER_NAME_LEN: The maximum length of a qualifier. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_CHAR_LITERAL_LEN: The maximum number of characters in a character string. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_COLUMN_NAME_LEN: The maximum length of a column name. | Returns 64. Column names cannot exceed 64 characters in length. | +| SQL_MAX_COLUMNS_IN_GROUP_BY: The maximum number of columns allowed in a GROUP BY clause. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_COLUMNS_IN_INDEX: The maximum number of columns allowed in an index. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_COLUMNS_IN_ORDER_BY: The maximum number of columns allowed in an ORDER BY clause. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_COLUMNS_IN_SELECT: The maximum number of columns allowed in a SELECT list. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_COLUMNS_IN_TABLE: The maximum number of columns allowed in a table. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_CONCURRENT_ACTIVITIES prev. SQL_MAX_ACTIVE_STATEMENTS: The maximum number of active SQL statements that the driver can support. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_CURSOR_NAME_LEN: The maximum length of a cursor name. | Returns 32. A cursor name cannot exceed 32 characters in length. | +| SQL_MAX_DRIVER_CONNECTIONS prev. SQL_ACTIVE_CONNECTIONS: The maximum number of active connections the driver can support. | Returns 0. There is no specified limit to the number of connections supported. | +| SQL_MAX_IDENTIFIER_LEN: The maximum identifier length allowed by the server. | Returns 64. Identifiers cannot exceed 64 characters in length. | +| SQL_MAX_INDEX_SIZE: The maximum number of bytes allowed in the (combined) fields of an index. | Returns 0. The maximum size is unspecified. | +| SQL_MAX_OWNER_NAME_LEN Now SQL_MAX_SCHEMA_NAME_LEN: The maximum length of an owner name allowed by the server. | Returns 64. The maximum length of an owner name is 64 characters. | +| SQL_MAX_PROCEDURE_NAME_LEN: The maximum length of a procedure name allowed by the server. | Returns 0. The maximum length is unspecified. | +| SQL_MAX_QUALIFIER_NAME_LEN Now SQL_MAX_CATALOG_NAME_LEN: The maximum length of a qualifier name allowed by the server. | Returns 0. The maximum length of a qualifier is unspecified. | +| SQL_MAX_ROW_SIZE: The maximum length of a row. | Returns 0. The maximum row length is unspecified. | +| SQL_MAX_ROW_SIZE_INCLUDES_LONG: Indicates whether the SQL_MAX_ROW_SIZE includes the length of any LONGVARCHAR or LONGVARBINARY columns in the row. | Returns Y. SQL_MAX_ROW_SIZE includes the length of any LONGVARCHAR or LONGVARBINARY columns in the row. | +| SQL_MAX_SCHEMA_NAME_LEN: The maximum length of a schema name allowed by the server. | Returns 64. The maximum length of a schema name is 64 characters. | +| SQL_MAX_STATEMENT_LEN: The maximum length of a SQL statement. | Returns 0. Maximum statement length is limited by available memory. | +| SQL_MAX_TABLE_NAME_LEN: The maximum length of a table name allowed by the server. | Returns 64. The maximum length of a table name is 64 characters. | +| SQL_MAX_TABLES_IN_SELECT: The maximum number of tables allowed in the FROM clause of a SELECT statement. | Returns 0. The maximum number of tables allowed is unspecified. | +| SQL_MAX_USER_NAME_LEN: The maximum length of the user name allowed by the server. | Returns 0. The maximum length of a user name is unspecified. | +| SQL_MULT_RESULT_SETS: Indicates server support for multiple result sets. | Returns Y. Advanced Server supports multiple result sets. | +| SQL_MULTIPLE_ACTIVE_TXN: Indicates if the server supports multiple active transactions. | Returns Y. Advanced Server supports multiple active transactions. | +| SQL_NEED_LONG_DATA_LEN: Indicates if the server needs the length of a LONG data value before receiving the value. | Returns N. Advanced Server does not need the length of a LONG data value before receiving the value. | +| SQL_NON_NULLABLE_COLUMNS: Indicates if the server supports NOT NULL values in columns. | Returns SQL_NNC_NON_NULL. Advanced Server does support NOT NULL values in columns. | +| SQL_NULL_COLLATION: Indicates where NULL values are located in a result set. | Returns SQL_NC_HIGH. The location of NULL values in a data set is determined by the ASC and DESC keywords; NULL values are sorted to the high end of the data set. | +| SQL_NUMERIC_FUNCTIONS: Lists the numeric functions supported by the driver and the server. | Returns: SQL_FN_NUM_ABS, SQL_FN_NUM_ATAN, SQL_FN_NUM_CEILING, SQL_FN_NUM_COS, SQL_FN_NUM_EXP, SQL_FN_NUM_FLOOR, SQL_FN_NUM_LOG, SQL_FN_NUM_MOD, SQL_FN_NUM_SIGN, SQL_FN_NUM_SIN, SQL_FN_NUM_SQRT, SQL_FN_NUM_TAN, SQL_FN_NUM_RAND, SQL_FN_NUM_POWER, SQL_FN_NUM_ROUND. | +| SQL_ODBC_API_CONFORMANCE: Indicates the ODBC 3.0 compliance level | Returns SQL_OAC_LEVEL1. The driver conforms to ODBC Level 1 interface. | +| SQL_ODBC_INTERFACE_CONFORMANCE: Indicates the ODBC interface that the driver adheres to. | Returns SQL_OIC_CORE. | +| SQL_ODBC_SAG_CLI_CONFORMANCE: Indicates the SQL Access Group compliance level that the driver adheres to. | Returns SQL_OSCC_NOT_COMPLIANT. The driver is not SAG CLI compliant. | +| SQL_ODBC_SQL_CONFORMANCE: Indicates the SQL grammar level that the driver conforms to. | Returns SQL_OSC_CORE. The driver conforms to the core grammar level. | +| SQL_ODBC_SQL_OPT_IEF Now SQL_INTEGRITY: Indicates server support for referential integrity syntax checking. | Returns N. The server does not support referential integrity syntax checking. | +| SQL_ODBC_VER: The ODBC version supported by the driver manager | Returns 03.52.0000. | +| SQL_OJ_CAPABILITIES: Identifies the outer joins that are supported by the server. | Returns: SQL_OJ_LEFT, SQL_OJ_RIGHT, SQL_OJ_FULL, SQL_OJ_NESTED, SQL_OJ_NOT_ORDERED, SQL_OJ_INNER, SQL_OJ_ALL_COMPARISON_OPS. | +| SQL_OUTER_JOINS: Indicates support for outer joins and the outer join escape sequence. | Returns Y. Outer joins are supported. | +| SQL_OWNER_TERM prev. SQL_SCHEMA_TERM: The term used to describe a schema. | Returns schema. | +| SQL_ORDER_BY_COLUMNS_IN_SELECT: Indicates if the columns in an ORDER BY clause must be included in the SELECT list. | Returns N. Columns in an ORDER BY clause do not have to be in the SELECT list. | +| SQL_OWNER_USAGE prev. SQL_SCHEMA_USAGE: Returns a string that indicates which statements support schema qualifiers. | Returns: SQL_OU_DML_STATEMENTS, SQL_OU_TABLE_DEFINITION, SQL_OU_INDEX_DEFINITION, SQL_OU_PRIVILEGE_DEFINITION. | +| SQL_PARAM_ARRAY_ROW_COUNTS: Indicates if the server will return a single row count or separate row counts for each element in an array when executing a parameterized statement with at least one parameter bound to the array. | Returns SQL_PARC_BATCH, if separate row counts are available for each element in an array. SQL_PARC_NO_BATCH if a single, cumulative row count is available for the entire array. | +| SQL_PARAM_ARRAY_SELECTS: Indicates if the server will return one result set or a separate result set for each element in an array (or if the driver does not allow this feature) when executing a parameterized statement with at least one parameter bound to the array. | Returns SQL_PAS_BATCH. One data set is available for each element in an array. | +| SQL_POS_OPERATION: Lists the options supported by SQLSetPos(). | Returns: SQL_POS_POSITION, SQL_POS_REFRESH, SQL_POS_UPDATE, SQL_POS_DELETE, SQL_POS_ADD. | +| SQL_POSITIONED_STATEMENTS: Lists the supported positioned SQL statements. | Returns: SQL_PS_POSITIONED_DELETE, SQL_PS_POSITIONED_UPDATE, SQL_PS_SELECT_FOR_UPDATE. | +| SQL_PROCEDURE_TERM: The term used to describe a procedure. | Returns procedure. | +| SQL_PROCEDURES: Indicates if the server and the driver support SQL procedures and procedure invocation syntax. | Returns Y. The server and driver support procedures and procedure invocation syntax. | +| SQL_QUALIFIER_LOCATION prev. SQL_CATALOG_LOCATION: Indicates the position of the schema name in a qualified table name. | Returns SQL_CL_START. The catalog portion of a qualified table name is at the beginning of the name. | +| SQL_QUALIFIER_NAME prev. SQL_CATALOG_NAME: Indicates server support for catalog names. | Returns Y. The server supports catalog names. | +| SQL_QUALIFIER_NAME_SEPARATOR prev. SQL_CATALOG_NAME_SEPARATOR: Character separating the qualifier name from the adjacent name element. | Returns '.'. The server expects a '.' character between the qualifier and the table name. | +| SQL_QUALIFIER_TERM prev. SQL_CATALOG_TERM: The term used to describe a qualifier. | Returns catalog. | +| SQL_QUALIFIER_USAGE prev. SQL_CATALOG_USAGE: Indicates the SQL statements that may refer to qualifiers. | Returns SQL_CU_DML_STATEMENTS. Catalog names can be used in SELECT, INSERT, UPDATE, DELETE, SELECT FOR UPDATE and positioned UPDATE and DELETE statements. | +| SQL_QUALIFIER_USAGE Now SQL_CATALOG_USAGE: Identifies DML statements that support qualifier names. | Returns SQL_CU_DML_STATEMENTS. Qualifiers can be used in all DML statements (SELECT, INSERT, UPDATE, DELETE, SELECT FOR UPDATE). | +| SQL_QUOTED_IDENTIFIER_CASE: Indicates case sensitivity of quoted identifiers. | Returns SQL_IC_SENSITIVE. Quoted identifiers are case sensitive. | +| SQL_QUALIFIER_NAME_SEPARATOR Now SQL CATALOG_NAME_SEPARATOR: The character that separates the name qualifier from the name element. | Returns . The '.' character is used as a separator in qualified names. | +| SQL_QUALIFIER_TERM: The term used to describe a qualifier. | Returns catalog | +| SQL_QUALIFIER_LOCATION: The position of the qualifier in a qualified table name. | Returns SQL_CL_START. The qualifier precedes the table name in a qualified table name. | +| SQL_ROW_UPDATES: Indicates if keyset-driven or mixed cursors maintain row versions or values. | Returns Y. Cursors maintain values for all fetched rows and can detect updates to the row values. | +| SQL_SCHEMA_TERM: The term used to describe a schema. | Returns schema | +| SQL_SCHEMA_USAGE: Indicates the SQL statements that may refer to schemas. | Returns: SQL_OU_DML_STATEMENTS, SQL_OU_TABLE_DEFINITION, SQL_OU_INDEX_DEFINITION, SQL_OU_PRIVILEGE_DEFINITION. | +| SQL_SCROLL_CONCURRENCY: Indicates the cursor concurrency control options supported by the server. | Returns: SQL_SCCO_READ_ONLY, SQL_SCCO_OPT_ROWVER. | +| SQL_SCROLL_OPTIONS: Indicates the cursor scroll options supported by the server. | Returns: SQL_SO_FORWARD_ONLY, SQL_SO_KEYSET_DRIVEN, SQL_SO_STATIC. | +| SQL_SEARCH_PATTERN_ESCAPE: The escape character that allows use of the wildcard characters % and \_ in search patterns. | Returns . The '' character is used as an escape character for the '%' and '\_' characters in search patterns. | +| SQL_SERVER_NAME: Indicates the name of the host. | The returned value is determined by connection properties. | +| SQL_SPECIAL_CHARACTERS: Indicates any special characters allowed in identifier names. | Returns \_. The underscore character is allowed in identifier names. | +| SQL_SQL_CONFORMANCE: Indicates the level of SQL-92 compliance. | Returns SQL_SC_SQL92_ENTRY. The driver is SQL92 Entry level compliant. | +| SQL_SQL92_DATETIME_FUNCTIONS: Lists the datetime functions supported by the server. | Returns: SQL_SDF_CURRENT_DATE, SQL_SDF_CURRENT_TIME, SQL_SDF_CURRENT_TIMESTAMP. | +| SQL_SQL92_FOREIGN_KEY_DELETE_RULE: Indicates the server-enforced rules for using a foreign key in a DELETE statement. | Returns: SQL_SFKD_CASCADE, SQL_SFKD_NO_ACTION, SQL_SFKD_SET_DEFAULT, SQL_SFKD_SET_NULL. | +| SQL_SQL92_FOREIGN_KEY_UPDATE_RULE: Indicates the server-enforced rules for using a foreign key in an UPDATE statement. | Returns: SQL_SFKU_CASCADE, SQL_SFKU_NO_ACTION, SQL_SFKU_SET_DEFAULT, SQL_SFKU_SET_NULL. | +| SQL_SQL92_GRANT: Indicates the supported GRANT statement clauses. | Returns: SQL_SG_DELETE_TABLE, SQL_SG_INSERT_TABLE, SQL_SG_REFERENCES_TABLE, SQL_SG_SELECT_TABLE, SQL_SG_UPDATE_TABLE. | +| SQL_SQL92_NUMERIC_VALUE_FUNCTIONS: Lists the scalar numeric functions supported by the server and driver. | Returns: SQL_SNVF_BIT_LENGTH, SQL_SNVF_CHAR_LENGTH, SQL_SNVF_CHARACTER_LENGTH, SQL_SNVF_EXTRACT, SQL_SNVF_OCTET_LENGTH, SQL_SNVF_POSITION. | +| SQL_SQL92_PREDICATES, Identifies the predicates of a SELECT statement supported by the server. | Returns: SQL_SP_EXISTS, SQL_SP_ISNOTNULL, SQL_SP_ISNULL, SQL_SP_OVERLAPS, SQL_SP_LIKE, SQL_SP_IN, SQL_SP_BETWEEN, SQL_SP_COMPARISON, SQL_SP_QUANTIFIED_COMPARISON. | +| SQL_SQL92_RELATIONAL_JOIN_OPERATORS: Identifies the relational join operators supported by the server. | Returns: SQL_SRJO_CROSS_JOIN, SQL_SRJO_EXCEPT_JOIN, SQL_SRJO_FULL_OUTER_JOIN, SQL_SRJO_INNER_JOIN, SQL_SRJO_INTERSECT_JOIN, SQL_SRJO_LEFT_OUTER_JOIN, SQL_SRJO_NATURAL_JOIN, SQL_SRJO_RIGHT_OUTER_JOIN, SQL_SRJO_UNION_JOIN. | +| SQL_SQL92_REVOKE: Identifies the clauses in a REVOKE statement that are supported by the server. | Returns: SQL_SR_DELETE_TABLE, SQL_SR_INSERT_TABLE, SQL_SR_REFERENCES_TABLE, SQL_SR_SELECT_TABLE, SQL_SR_UPDATE_TABLE. | +| SQL_SQL92_ROW_VALUE_CONSTRUCTOR: Indicates the row value constructor expressions in a SELECT statement that are supported by the server. | Returns: SQL_SRVC_VALUE_EXPRESSION, SQL_SRVC_NULL. | +| SQL_SQL92_STRING_FUNCTIONS: Lists the string scalar functions supported by the server and driver. | Returns: SQL_SSF_CONVERT, SQL_SSF_LOWER, SQL_SSF_UPPER, SQL_SSF_SUBSTRING, SQL_SSF_TRANSLATE, SQL_SSF_TRIM_BOTH, SQL_SSF_TRIM_LEADING, SQL_SSF_TRIM_TRAILING. | +| SQL_SQL92_VALUE_EXPRESSIONS: Indicates the value expressions supported by the server. | Returns: SQL_SVE_CASE, SQL_SVE_CAST, SQL_SVE_COALESCE, SQL_SVE_NULLIF. | +| SQL_STANDARD_CLI_CONFORMANCE: Indicates the CLI standard the driver conforms to. | This info_type is currently unsupported. | +| SQL_STATIC_CURSOR_ATTRIBUTES1: Describes the first set of static cursor attributes supported by the driver. | Returns: SQL_CA1_NEXT, SQL_CA1_ABSOLUTE, SQL_CA1_RELATIVE, SQL_CA1_BOOKMARK, SQL_CA1_LOCK_NO_CHANGE, SQL_CA1_POS_POSITION, SQL_CA1_POS_UPDATE, SQL_CA1_POS_DELETE, SQL_CA1_POS_REFRESH, SQL_CA1_BULK_ADD, SQL_CA1_BULK_UPDATE_BY_BOOKMARK, SQL_CA1_BULK_DELETE_BY_BOOKMARK, SQL_CA1_BULK_FETCH_BY_BOOKMARK. | +| SQL_STATIC_CURSOR_ATTRIBUTES2: Describes the second set of static cursor attributes supported by the driver. | Returns: SQL_CA2_READ_ONLY_CONCURRENCY, SQL_CA2_OPT_ROWVER_CONCURRENCY, SQL_CA2_SENSITIVITY_ADDITIONS, SQL_CA2_SENSITIVITY_DELETIONS, SQL_CA2_SENSITIVITY_UPDATES, SQL_CA2_CRC_EXACT. | +| SQL_STATIC_SENSITIVITY: Indicates whether changes made to a static cursor by SQLSetPos() or UPDATE or DELETE statements are detected by the application. | Returns: SQL_SS_ADDITIONS, SQL_SS_DELETIONS, SQL_SS_UPDATES. | +| SQL_STRING_FUNCTIONS: Lists the scalar string functions supported by the server and driver. | Returns: SQL_FN_STR_CONCAT, SQL_FN_STR_LTRIM, SQL_FN_STR_LENGTH, SQL_FN_STR_LOCATE, SQL_FN_STR_LCASE, SQL_FN_STR_RTRIM, SQL_FN_STR_SUBSTRING, SQL_FN_STR_UCASE. | +| SQL_SUBQUERIES: Identifies the subquery predicates to a SELECT statement supported by the server. | Returns: SQL_SQ_COMPARISON, SQL_SQ_EXISTS, SQL_SQ_IN, SQL_SQ_QUANTIFIED. | +| SQL_SYSTEM_FUNCTIONS: Lists the scalar system functions supported by the server and driver. | Returns 0. | +| SQL_TABLE_TERM: The term used to describe a table. | Returns table. | +| SQL_TIMEDATE_ADD_INTERVALS: Indicates the timestamp intervals supported by the server for the TIMESTAMPADD scalar function. | Returns 0. | +| SQL_TIMEDATE_DIFF_INTERVALS: Indicates the timestamp intervals supported by the server for the TIMESTAMPDIFF scalar function. | Returns 0 | +| SQL_TIMEDATE_FUNCTIONS: Indicates the date and time functions supported by the server. | Returns: SQL_FN_TD_NOW, SQL_FN_TD_CURDATE, SQL_FN_TD_CURTIME. | +| SQL_TXN_CAPABLE: Identifies the transaction support offered by the server and driver. | Returns SQL_TC_ALL. Transactions can contain both DML and DDL statements. | +| SQL_TXN_ISOLATION_OPTION: Indicates the transaction isolation level supported by the server. | Returns: SQL_TXN_READ_COMMITTED, SQL_TXN_SERIALIZABLE. | +| SQL_UNION: Indicates server support for the UNION clause. | Returns: SQL_U_UNION, SQL_U_UNION_ALL. | +| SQL_USER_NAME: Identifies the name of the user connected to a database; may be different than the login name. | This value is determined by the connection properties. | +| SQL_XOPEN_CLI_YEAR: The publication year of the X/Open specification that the driver manager complies with. | This info_type is currently unsupported. | + +## Connection Attributes + +You can use the ODBC `SQLGetConnectAttr()` and `SQLSetConnectAttr()` functions to retrieve or set the value of a connection attribute. + +### SQLGetConnectAttr() + +The `SQLGetConnectAttr()` function returns the current value of a connection attribute. The signature is: + +```c++ +SQLRETURN SQLGetConnectAttr +( + SQLHDBC conn_handle, //Input + SQLINTEGER attribute, //Input + SQLPOINTER value_pointer, //Output + SQLINTEGER buffer_length, //Input + SQLINTEGER * string_length_pointer //Output +); +``` + +- `conn_handle` The connection handle. + +- `attribute` identifies the attribute whose value you wish to retrieve. + +- `value_pointer` A pointer to the location in memory that will receive the `attribute` value. + +- `buffer_length` If `attribute` is defined by ODBC and `value_pointer` points to a character string or binary buffer, `buffer_length` is the length of `value_pointer`. If `value_pointer` points to a fixed-size value (such as an integer), `buffer_length` is ignored. + + If EDB-ODBC defines the attribute, `SQLGetConnectAttr()` sets the `buffer_length` parameter. `buffer_length` can be: + + | Value type | Meaning | + | ---------------------- | ----------------------------------------- | + | Character string | The length of the character string | + | Binary buffer | The result of SQL_LEN_BINARY_ATTR(length) | + | Fixed length data type | SQL_IS_INTEGER or SQL_IS_UINTEGER | + | Any other type | SQL_IS_POINTER | + +- `string_length_pointer` A pointer to a `SQLINTEGER` that receives the number of bytes available to return in `value_pointer`. If `value_pointer` is `NULL`, `string_length_pointer` is not returned. + +This function returns `SQL_SUCCESS`, `SQL_SUCCESS_WITH_INFO`, `SQL_NO_DATA`, `SQL_ERROR` or `SQL_INVALID_HANDLE`. + +The following table lists the connection attributes supported by EDB-ODBC. + +| Attribute | Supported? | Notes | +| ---------------------------- | ---------- | ----------------------------------------------------- | +| SQL_ATTR_ACCESS_MODE | NO | SQL_MODE_READ_WRITE | +| SQL_ATTR_ASYNC_ENABLE | NO | SQL_ASYNC_ENABLE_OFF | +| SQL_ATTR_AUTO_IPD | NO | | +| SQL_ATTR_AUTOCOMMIT | YES | SQL_AUTOCOMMIT, SQL_AUTOCOMMIT_ON, SQL_AUTOCOMMIT_OFF | +| SQL_ATTR_CONNECTION_TIMEOUT | NO | | +| SQL_ATTR_CURRENT_CATALOG | NO | | +| SQL_ATTR_DISCONNECT_BEHAVIOR | NO | | +| SQL_ATTR_ENLIST_IN_DTC | YES | For win32 and with conditional compilation | +| SQL_ATTR_ENLIST_IN_XA | NO | | +| SQL_ATTR_LOGIN_TIMEOUT | NO | SQL_LOGIN_TIMEOUT | +| SQL_ATTR_ODBC_CURSORS | NO | | +| SQL_ATTR_PACKET_SIZE | NO | | +| SQL_ATTR_QUIET_MODE | NO | | +| SQL_ATTR_TRACE | NO | | +| SQL_ATTR_TRACEFILE | NO | | +| SQL_ATTR_TRANSLATE_LIB | NO | | +| SQL_ATTR_TRANSLATE_OPTION | NO | | +| SQL_ATTR_TXN_ISOLATION | YES | SQL_TXN_ISOLATION, SQL_DEFAULT_TXN_ISOLATION | + +### SQLSetConnectAttr() + +You can use the ODBC `SQLSetConnectAttr()` function to set the values of connection attributes. The signature of the function is: + +```c++ +SQLRETURN SQLSetConnectAttr +( + SQLHDBC conn_handle , // Input + SQLINTEGER attribute , // Input + SQLPOINTER value_pointer , // Input + SQLINTEGER string_length , // Input +); +``` + +`conn_handle` + +The connection handle + +`attribute` + +`attribute` identifies the attribute whose value you wish to set + +`value_pointer` + +A pointer to the value that the `attribute` will assume. + +`string_length` + +If `attribute` is defined by ODBC and `value_pointer` points to a binary buffer or character string, `string_length` is the length of `value_pointer`. If `value_pointer` points to a fixed-length value (such as an integer), `string_length` is ignored. + +If EDB-ODBC defines the attribute, the application sets the `string_length` parameter. Possible `string_length` values are: + +| Value Type | Meaning | +| ---------------------- | --------------------------------------------- | +| Character string | The length of the character string or SQL_NTS | +| Binary buffer | The result of SQL_LEN_BINARY_ATTR(length) | +| Fixed length data type | SQL_IS_INTEGER or SQL_IS_UINTEGER | +| Any other type | SQL_IS_POINTER | + +`SQLSetConnectAttr()` returns `SQL_SUCCESS`, `SQL_SUCCESS_WITH_INFO`, `SQL_ERROR`, `SQL_STILL_EXECUTING` or `SQL_INVALID_HANDLE`. + +You can call `SQLSetConnectAttr()` any time after the connection handle is allocated, until the time that the connection is closed with a call to `SQLFreeHandle()`. All attributes set by the call persist until the call to `SQLFreeHandle()`. + +Connection attributes have a specific time frame in which they can be set. Some attributes must be set before the connection is established, while others can only be set after a connection is established. + +The following table lists the connection attributes and the time frame in which they can be set: + +| Attribute | Set Before or After establishing a connection? | +| --------------------------- | ---------------------------------------------- | +| SQL_ATTR_ACCESS_MODE | Before or After | +| SQL_ATTR_ASYNC_ENABLE | Before or After | +| SQL_ATTR_AUTO_IPD | Before or After | +| SQL_ATTR_AUTOCOMMIT | Before or After | +| SQL_ATTR_CONNECTION_TIMEOUT | Before or After | +| SQL_ATTR_CURRENT_CATALOG | Before or After | +| SQL_ATTR_ENLIST_IN_DTC | After | +| SQL_ATTR_ENLIST_IN_XA | After | +| SQL_ATTR_LOGIN_TIMEOUT | Before | +| SQL_ATTR_ODBC_CURSORS | Before | +| SQL_ATTR_PACKET_SIZE | Before | +| SQL_ATTR_QUIET_MODE | Before or After | +| SQL_ATTR_TRACE | Before or After | +| SQL_ATTR_TRACEFILE | Before or After | +| SQL_ATTR_TRANSLATE_LIB | After | +| SQL_ATTR_TRANSLATE_OPTION | After | +| SQL_ATTR_TXN_ISOLATION | Before or After | + +## Environment Attributes + +You can use the ODBC `SQLGetEnvAttr()` and `SQLSetEnvAttr()` functions to retrieve or set the value of an environment attribute. + +### SQLGetEnvAttr() + +Use the `SQLGetEnvAttr()` function to find the current value of environment attributes on your system. The signature of the function is: + +```c++ +SQLRETURN SQLGetConnectAttr +( + SQLHDBC env_handle, // Input + SQLINTEGER attribute, // Input + SQLPOINTER value_ptr, // Output + SQLINTEGER buffer_length, // Input + SQLINTEGER * string_length_pointer // Output +); +``` + +`env_handle` + +The environment handle. + +`attribute` + +`attribute` identifies the attribute whose value you wish to retrieve. + +`value_pointer` + +A pointer to the location in memory that will receive the `attribute` value. + +`buffer_length` + +If the attribute is a character string, `buffer_length` is the length of `value_ptr`. If the value of the attribute is not a character string, `buffer_length` is unused. + +`string_length_pointer` + +A pointer to a `SQLINTEGER` that receives the number of bytes available to return in `value_pointer`. If `value_pointer` is NULL, `string_length_pointer` is not returned. + +This function returns `SQL_SUCCESS`, `SQL_SUCCESS_WITH_INFO` , `SQL_NO_DATA`, `SQL_ERROR` or `SQL_INVALID_HANDLE`. + +The following table lists the environment attributes supported by EDB-ODBC. + +| Attribute | Supported? | Restrictions? | +| --------------------------- | ----------------------------------- | ----------------------------------- | +| SQL_ATTR_CONNECTION_POOLING | SQL_CP_ONE_PER_DRIVER or SQL_CP_OFF | Determined by connection properties | +| SQL_ATTR_ODBC_VERSION | (SQL_OV_ODBC3), (SQL_OV_ODBC2) | NONE | +| SQL_ATTR_OUTPUT_NTS | SQL_SUCCESS | NONE | + +## SQLSetEnvAttr() + +You can use the `SQLSetEnvAttr()` function to set the values of environment attributes. The signature of the function is: + +```c++ +SQLRETURN SQLSetEnvAttr +( + SQLHENV env_handle , //Input + SQLINTEGER attribute , //Input + SQLPOINTER value_pointer , //Input + SQLINTEGER string_length //Input +); +``` + +- `env_handle` The environment handle. +- `attribute` identifies the attribute whose value you wish to set. +- `value_pointer` A pointer to the value assigned to the `attribute`. +- The value will be a `NULL` terminated character string or a 32 bit integer value depending on the specified `attribute`. +- `string_length` If `value_pointer` is a pointer to a binary buffer or character string,`string\_length` is the length of `value_pointer`. If the value being assigned to the attribute is a character, `string_length` is the length of that character string. If `value_pointer` is NULL, `string_length` is not returned. If value_pointer is an integer,`string_length`is ignored. + +`SQLSetEnvAttr()` returns `SQL_SUCCESS`, `SQL_INVALID_HANDLE`, `SQL_ERROR` or `SQL_SUCCESS_WITH_INFO`. The application must call `SQLSetEnvAttr()` before allocating a connection handle; all values applied to environment attributes will persist until `SQLFreeHandle()` is called for the connection. ODBC version 3.x allows you to allocate multiple environment handles simultaneously. + +The following table lists the environment attributes you can set with `SQLSetAttr()`. + +| Attribute | Value_pointer type | Restrictions? | +| --------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------- | +| SQL_ATTR_ODBC_VERSION | 32 bit Integer | Set this attribute before the application calls any function that includes an SQLHENV argument. | +| SQL_ATTR_OUTPUT_NTS | 32-bit Integer | Defaults to SQL_TRUE. Calls that set this attribute to SQL_FALSE return SQL_ERROR/SQLSTATEHYC00 (feature not implemented). | + +## Statement Attributes + +You can use the ODBC `SQLGetStmtAttr()` and `SQLSetStmtAttr()`functions to retrieve and set the value of a statement attribute. + +### SQLGetStmtAttr() + +The `SQLGetStmtAttr()` function returns the current value of statement attribute. The signature is: + +```c++ +SQLRETURN SQLGetConnectAttr +( + SQLHDBC stmt_handle, //Input + SQLINTEGER attribute, //Input + SQLPOINTER value_ptr, //Output + SQLINTEGER buffer_length, //Input + SQLINTEGER * string_length_pointer //Output +); +``` + +- `stmt_handle` The statement handle + +- `attribute` is the attribute value + +- `value_pointer` A pointer to the location in memory that will receive the `attribute` value. + +- `buffer_length` If the attribute is defined by ODBC, `buffer_length` is the length of `value_pointer` (if `value_pointer` points to a character string or binary buffer). If `value_pointer` points to an integer, `buffer_length` is ignored. + + If EDB-ODBC defines the attribute, the application sets the `buffer_length` parameter. `buffer_length`can be: + + | Value Type | Meaning | + | ---------------------- | ----------------------------------------- | + | Character string | The length of the character string | + | Binary buffer | The result of SQL_LEN_BINARY_ATTR(length) | + | Fixed length data type | SQL_IS_INTEGER or SQL_IS_UINTEGER | + | Any other type | SQL_IS_POINTER | + +- `string_length_pointer` A pointer to an `SQLINTEGER` that receives the number of bytes required to hold the requested value. If `value_pointer` is NULL, `string_length_pointer` is not returned. + + This function returns `SQL_SUCCESS`, `SQL_SUCCESS_WITH_INFO`, `SQL_ERROR` or `SQL_INVALID_HANDLE`. + +The following table lists the statement attributes supported by EDB_ODBC: + + | Attribute | Supported? | Restrictions? | + | ------------------------------ | ---------- | ----------------------- | + | SQL_ATTR_APP_PARAM_DESC | YES | | + | SQL_ATTR_APP_ROW_DESC | YES | | + | SQL_ATTR_ASYNC_ENABLE | NO | | + | SQL_ATTR_CONCURRENCY | YES | SQL_CONCUR_READ_ONLY | + | SQL_ATTR_CURSOR_SCROLLABLE | YES | | + | SQL_ATTR_CURSOR_TYPE | YES | SQL_CURSOR_FORWARD_ONLY | + | SQL_ATTR_CURSOR_SENSITIVITY | YES | SQL_INSENSITIVE | + | SQL_ATTR_ENABLE_AUTO_IPD | NO | | + | SQL_ATTR_FETCH_BOOKMARK_PTR | YES | | + | SQL_ATTR_IMP_PARAM_DESC | YES | | + | SQL_ATTR_IMP_ROW_DESC | YES | | + | SQL_ATTR_KEYSET_SIZE | NO | | + | SQL_ATTR_MAX_LENGTH | NO | | + | SQL_ATTR_MAX_ROWS | NO | | + | SQL_ATTR_METADATA_ID | YES | | + | SQL_ATTR_NOSCAN | NO | | + | SQL_ATTR_PARAM_BIND_OFFSET_PTR | YES | ODBC V2.0 | + | SQL_ATTR_PARAM_BIND_TYPE | YES | | + | SQL_ATTR_PARAM_OPERATION_PTR | YES | | + | SQL_ATTR_PARAM_STATUS_PTR | YES | | + | SQL_ATTR_PARAMS_PROCESSED_PTR | YES | | + | SQL_ATTR_PARAMSET_SIZE | YES | | + | SQL_ATTR_QUERY_TIMEOUT | NO | | + | SQL_ATTR_RETRIEVE_DATA | NO | | + | SQL_ATTR_ROW_BIND_OFFSET_PTR | YES | | + | SQL_ATTR_ROW_BIND_TYPE | NO | | + | SQL_ATTR_ROW_NUMBER | YES | | + | SQL_ATTR_ROW_OPERATION_PTR | YES | | + | SQL_ATTR_ROW_STATUS_PTR | YES | | + | SQL_ATTR_ROWS_FETCHED_PTR | YES | | + | SQL_ATTR_ROW_ARRAY_SIZE | YES | | + | SQL_ATTR_SIMULATE_CURSOR | NO | | + | SQL_ATTR_USE_BOOKMARKS | YES | | + | SQL_ROWSET_SIZE | YES | | + +### SQLSetStmtAttr() + +You can use the `SQLSetStmtAttr()` function to set the values of environment attributes. The signature is: + +```c++ +SQLRETURN SQLSetStmtAttr +( + SQLHENV stmt_handle , //Input + SQLINTEGER attribute , //Input + SQLPOINTER value_pointer , //Input + SQLINTEGER string_length //Input +); +``` + +- `stmt_handle` is the environment handle. + +- `attribute` identifies the statement attribute whose value you wish to set. + +- `value_pointer` is a pointer to the location in memory that holds the value that will be assigned to the attribute. `value_pointer`can be a pointer to: + + - A null-terminated character string + - A binary buffer + - A value defined by the driver + - A value of the type `SQLLEN`, `SQLULEN` or `SQLUSMALLINT` + + Value-pointer can also optionally hold one of the following values: + - An ODBC descriptor handle + - A `SQLUINTEGER` value + - A `SQLULEN` value + - A signed INTEGER (if attribute is a driver-specific value) + +- `string_length` If `attribute` is defined by ODBC and `value_pointer` points to a binary buffer or character string, `string_length` is the length of `value_pointer`. If `value_pointer` points to an integer, `string_length` is ignored. + If EDB-ODBC defines the attribute, the application sets the `string_length` parameter. Possible `string_length` values are: + +| Value Type | Meaning | +| ---------------------- | --------------------------------------------- | +| Character string | The length of the character string or SQL_NTS | +| Binary buffer | The result of SQL_LEN_BINARY_ATTR(length) | +| Fixed length data type | SQL_IS_INTEGER or SQL_IS_UINTEGER | +| Any other type | SQL_IS_POINTER | + +## Error Handling + +Diagnostic information for the ODBC functions mentioned in this guide can be retrieved via the ODBC `SQLGetDiagRec()` function. + +### SQLGetDiagRec() + + The `SQLGetDiagRec()` function returns status and error information from a diagnostic record written by the ODBC functions that retrieve or set attribute values. The signature is: + +```c++ +SQLRETURN SQLGetDiagRec +( + SQLSMALLINT handle_type, // Input + SQLHANDLE handle, // Input + SQLSMALLINT record_number, // Input + SQLCHAR *SQLState_pointer, // Output + SQLINTEGER *native_error_pointer, // Output + SQLCHAR *error_text_pointer, // Output + SQLSMALLINT buffer_length, // Input + SQLSMALLINT *text_length_pointer // Output +); +``` + +- `handle_type` The handle type of the `handle` argument. `handle_type`must be one of the following: + + - `SQL_HANDLE_ENV` specifies an environment handle. + - `SQL_HANDLE_STMT` specifies a statement handle. + - `SQL_HANDLE_DBC` specifies a connection handle. + - `SQL_HANDLE_DESC` specifies a descriptor handle. + +- `handle` The handle associated with the attribute error message. + +- `record_number` The status record that the application is seeking information from (must be greater than or equal to 1). + +- `SQLState_pointer` Pointer to a memory buffer that receives the `SQLState` error code from the record. + +- `native_error_pointer` Pointer to a buffer that receives the native error message for the data source (contained in the `SQL_DIAG_NATIVE` field). + +- `error_text_pointer` Pointer to a memory buffer that receives the error text (contained in the `SQL_DIAG_MESSAGE_TEXT` field) + +- `buffer_length` The length of the `error_text` buffer. + +- `text_length_pointer` Pointer to the buffer that receives the size (in characters) of the `error_text_pointer` field. If the number of characters in the `error_text_pointer` parameter exceeds the number available (in `buffer_length`), `error_text_pointer` will be truncated. + +`SQLGetDiagRec()` returns `SQL_SUCCESS`, `SQL_ERROR`, `SQL_INVALID_HANDLE`, `SQL_SUCCESS_WITH_DATA` or `SQL_NO_DATA`. + +## Supported ODBC API Functions + +The following table lists the ODBC API functions; the right column specifies `Yes` if the API is supported by the EDB-ODBC driver. Use the ODBC `SQLGetFunctions()` function (specifying a function ID of `SQL_API_ODBC3_ALL_FUNCTIONS`) to return a current version of this list. + +| ODBC API Function Name | Supported by EDB-ODBC? | +| ---------------------- | ---------------------- | +| SQLAllocConnect() | Yes | +| SQLAllocEnv() | Yes | +| SQLAllocStmt() | Yes | +| SQLBindCol() | Yes | +| SQLCancel() | Yes | +| SQLColAttributes() | Yes | +| SQLConnect() | Yes | +| SQLDescribeCol() | Yes | +| SQLDisconnect() | Yes | +| SQLError() | Yes | +| SQLExecDirect() | Yes | +| SQLExecute() | Yes | +| SQLFetch() | Yes | +| SQLFreeConnect() | Yes | +| SQLFreeEnv() | Yes | +| SQLFreeStmt() | Yes | +| SQLGetCursorName() | Yes | +| SQLNumResultCols() | Yes | +| SQLPrepare() | Yes | +| SQLRowCount() | Yes | +| SQLSetCursorName() | Yes | +| SQLSetParam() | Yes | +| SQLTransact() | Yes | +| SQLColumns() | Yes | +| SQLDriverConnect() | Yes | +| SQLGetConnectOption() | Yes | +| SQLGetData() | Yes | +| SQLGetFunctions() | Yes | +| SQLGetInfo() | Yes | +| SQLGetStmtOption() | Yes | +| SQLGetTypeInfo() | Yes | +| SQLParamData() | Yes | +| SQLPutData() | Yes | +| SQLSetConnectOption() | Yes | +| SQLSetStmtOption() | Yes | +| SQLSpecialColumns() | Yes | +| SQLStatistics() | Yes | +| SQLTables() | Yes | +| SQLBrowseConnect() | No | +| SQLColumnPrivileges() | No | +| SQLDataSources() | Yes | +| SQLDescribeParam() | No | +| SQLExtendedFetch() | Yes | +| SQLForeignKeys() | Yes | +| SQLMoreResults() | Yes | +| SQLNativeSQL() | Yes | +| SQLNumParams() | Yes | +| SQLParamOptions() | Yes | +| SQLPrimaryKeys() | Yes | +| SQLProcedureColumns() | Yes | +| SQLProcedures() | Yes | +| SQLSetPos() | Yes | +| SQLSetScrollOptions() | No | +| SQLTablePrivileges() | Yes | +| SQLDrivers() | Yes | +| SQLBindParameter() | Yes | +| SQLAllocHandle() | Yes | +| SQLBindParam() | Yes | +| SQLCloseCursor() | Yes | +| SQLColAttribute() | Yes | +| SQLCopyDesc() | Yes | +| SQLendTran() | Yes | +| SQLFetchScroll() | Yes | +| SQLFreeHandle() | Yes | +| SQLGetConnectAttr() | Yes | +| SQLGetDescField() | Yes | +| SQLGetDescRec() | Yes | +| SQLGetDiagField() | Yes | +| SQLGetDiagRec() | Yes | +| SQLGetEnvAttr() | Yes | +| SQLGetStmtAttr() | Yes | +| SQLSetConnectAttr() | Yes | +| SQLSetDescField() | Yes | +| SQLSetDescRec() | No | +| SQLSetEnvAttr() | Yes | +| SQLSetStmtAttr() | Yes | +| SQLBulkOperations() | Yes | + +## Supported Data Types + +EDB-ODBC supports the following ODBC data types: + +| ODBC Data Type | Corresponding Advanced Server Data Type | +| ------------------ | --------------------------------------- | +| SQL_BIGINT | PG_TYPE_INT8 | +| SQL_BINARY | PG_TYPE_BYTEA | +| SQL_BIT | PG_TYPE_BOOL or PG_TYPE_CHAR | +| SQL_CHAR | PG_TYPE_BPCHAR | +| SQL_TYPE_DATE | PG_TYPE_DATE | +| SQL_DECIMAL | PG_TYPE_NUMERIC | +| SQL_DOUBLE | PG_TYPE_FLOAT8 | +| SQL_FLOAT | PG_TYPE_FLOAT8 | +| SQL_INTEGER | PG_TYPE_INT4 | +| SQL_LONGVARBINARY | PG_TYPE_BYTEA | +| SQL_LONGVARCHAR | PG_TYPE_VARCHAR or PG_TYPE_TEXT | +| SQL_NUMERIC | PG_TYPE_NUMERIC | +| SQL_NUMERIC | PG_TYPE_NUMERIC | +| SQL_REAL | PG_TYPE_FLOAT4 | +| SQL_SMALLINT | PG_TYPE_INT2 | +| SQL_TYPE_TIME | PG_TYPE_TIME | +| SQL_TYPE_TIMESTAMP | PG_TYPE_DATETIME | +| SQL_TINYINT | PG_TYPE_INT2 | +| SQL_VARBINARY | PG_TYPE_BYTEA | +| SQL_VARCHAR | PG_TYPE_VARCHAR | + +## Thread Safety + +EDB-ODBC is thread safe. diff --git a/product_docs/docs/odbc_connector/12.0.0.2/07_scram_compatibility.mdx b/product_docs/docs/odbc_connector/12.0.0.2/07_scram_compatibility.mdx new file mode 100644 index 00000000000..44a60d89c9e --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/07_scram_compatibility.mdx @@ -0,0 +1,13 @@ +--- +title: "Scram Compatibility" +legacyRedirects: + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/security_and_encryption.html" + +legacyRedirectsGenerated: + # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. + - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.2/scram_compatibility.html" +--- + + + +The EDB ODBC Connector provides SCRAM-SHA-256 support for Advanced Server versions 10 and above. This support is available from EDB ODBC 10.01.0000.01 release onwards. diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/advanced_options_1.png b/product_docs/docs/odbc_connector/12.0.0.2/images/advanced_options_1.png new file mode 100755 index 00000000000..ca572ffb228 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/advanced_options_1.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:3e6f03b0307da9b9a0fa34ee58c331aa5a64a890dbd236b5b0de4eadd6a6880e +size 66479 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/connection_is_successful.png b/product_docs/docs/odbc_connector/12.0.0.2/images/connection_is_successful.png new file mode 100755 index 00000000000..9a16b5a9568 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/connection_is_successful.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:8d620de8c559038fcaed267c1933e42d026bcfd8385c0aec50d2665f2a291b06 +size 11904 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/create_new_data_source.png b/product_docs/docs/odbc_connector/12.0.0.2/images/create_new_data_source.png new file mode 100755 index 00000000000..9aef5128b26 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/create_new_data_source.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:81fa2a21c9e45ffb0bc49ab00f461eb49fdfde5792acb98bf7d53dae3cac71ff +size 79950 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/data_source_names.png b/product_docs/docs/odbc_connector/12.0.0.2/images/data_source_names.png new file mode 100755 index 00000000000..94b86591441 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/data_source_names.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:ff2d2f1794c2d9d1872904ec17228dc6ad2833840deb281486f089f768e1c2ef +size 79437 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/data_source_properties_window.png b/product_docs/docs/odbc_connector/12.0.0.2/images/data_source_properties_window.png new file mode 100755 index 00000000000..d56d373ab89 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/data_source_properties_window.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:3cbaafeb117554d23d2b2900160a849d5a769961da6c9cd4651999d3c567d01b +size 43846 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/define_the_data_source.png b/product_docs/docs/odbc_connector/12.0.0.2/images/define_the_data_source.png new file mode 100755 index 00000000000..cb0d3378e6d --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/define_the_data_source.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:ed196314172d2361e74db1dc375bf9665594b508c12f4ce18ed5d6be013dc9a8 +size 28976 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/driver_properties_window.png b/product_docs/docs/odbc_connector/12.0.0.2/images/driver_properties_window.png new file mode 100755 index 00000000000..274bb8a8bf0 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/driver_properties_window.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:21b21544592514a735c7c3562313f9c1207a81bbcebba7ea2911bf6ff0c06bf5 +size 19360 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/global_settings.png b/product_docs/docs/odbc_connector/12.0.0.2/images/global_settings.png new file mode 100755 index 00000000000..34d359a1b46 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/global_settings.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:702119d63552fd2b78acf0a4b21b53fa6efd6ec2c38324965d8ab4be12fc99db +size 26399 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/installed_edb-odbc_driver.png b/product_docs/docs/odbc_connector/12.0.0.2/images/installed_edb-odbc_driver.png new file mode 100755 index 00000000000..0704d4cc5b7 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/installed_edb-odbc_driver.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:1e0d273b43ac65b71c974c95e742c6c01c28f7562b7cd590cf2d811b8783e72a +size 79978 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/new_driver_definition.png b/product_docs/docs/odbc_connector/12.0.0.2/images/new_driver_definition.png new file mode 100755 index 00000000000..487f387a0ce --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/new_driver_definition.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:287ef91217e2b8a340a8dcfe66cc89d6c50469888d00f7a2772f96fe9bdc0347 +size 82264 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_advanced_options_2.png b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_advanced_options_2.png new file mode 100755 index 00000000000..6730245f187 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_advanced_options_2.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:adea506cc173b7d5058081dff9c9de1b7e1930d446c347b390ff0e2d32bf9144 +size 72827 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_complete.png b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_complete.png new file mode 100755 index 00000000000..9bfd3cec13b --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_complete.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:2e70d448c745bff4289b1dd67ccdd2533d0b3f18dc20347f3569eac88144fa50 +size 84226 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_dialog.png b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_dialog.png new file mode 100755 index 00000000000..3f3673d742d --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_dialog.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:5db061d96d1e279088f52810d688497bc11506cb079e787dd7005110f59d2800 +size 45643 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_wizard.png b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_wizard.png new file mode 100755 index 00000000000..8cb67f576b5 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/odbc_installation_wizard.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:1b2c969e2e5dd0a026cb1394cdde975fac478fdb99cc5dff3e8f8b22f200ff43 +size 219907 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/ready_to_install.png b/product_docs/docs/odbc_connector/12.0.0.2/images/ready_to_install.png new file mode 100755 index 00000000000..e80caf88cd7 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/ready_to_install.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:937956839307701b19e8d81518fc96363bd6998137828355258f3576f687ab13 +size 43726 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/select_driver_named_date_source.png b/product_docs/docs/odbc_connector/12.0.0.2/images/select_driver_named_date_source.png new file mode 100755 index 00000000000..57b41f7eb27 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/select_driver_named_date_source.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:fe4b534a2b466e7d4de8563e728e74b9cb58a4605c8388d0dd4a7ae0fd4e5a8b +size 27316 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/selecting_the_connectors_installer.png b/product_docs/docs/odbc_connector/12.0.0.2/images/selecting_the_connectors_installer.png new file mode 100755 index 00000000000..483297476b6 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/selecting_the_connectors_installer.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:153774abbc8fec6720b6795338bc5339f04f09385b8e09b6787becab8bd5bf5e +size 97551 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/starting_stackbuilder_plus.png b/product_docs/docs/odbc_connector/12.0.0.2/images/starting_stackbuilder_plus.png new file mode 100755 index 00000000000..ada7848a6ef --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/starting_stackbuilder_plus.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:03096a796d34d79ab5aa884ad49ff098dfa4232a3f172c1cc8597ded31a6fe56 +size 100810 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/unixodbc_data_source_administrator.png b/product_docs/docs/odbc_connector/12.0.0.2/images/unixodbc_data_source_administrator.png new file mode 100755 index 00000000000..cf3893d9575 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/unixodbc_data_source_administrator.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:daeab0b9844442fcf1a5484a184cfe9bb38ff5f5cea315ccf2fb1332d5c8f902 +size 69084 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/images/windows_data_source_administrator.png b/product_docs/docs/odbc_connector/12.0.0.2/images/windows_data_source_administrator.png new file mode 100755 index 00000000000..ab29ce6f5d9 --- /dev/null +++ b/product_docs/docs/odbc_connector/12.0.0.2/images/windows_data_source_administrator.png @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:77ea546d98802b3a3cc12bb1000aef47be802e668da438e591f353b9d7d72693 +size 102851 diff --git a/product_docs/docs/odbc_connector/12.0.0.2/index.mdx b/product_docs/docs/odbc_connector/12.0.0.2/index.mdx index 0bd458f4050..0b9c37b2c54 100644 --- a/product_docs/docs/odbc_connector/12.0.0.2/index.mdx +++ b/product_docs/docs/odbc_connector/12.0.0.2/index.mdx @@ -1,15 +1,9 @@ --- title: EDB ODBC Connector -productStub: true directoryDefaults: description: "EDB ODBC Connector Version 12.0.0.2 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.0.0.2/conclusion.html" - - "/edb-docs/p/edb-postgres-odbc-connector/12.0.0.2" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.0.0.2/genindex.html" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.0.0.2/index.html" --- - +ODBC (Open Database Connectivity) is a programming interface that allows a client application to connect to any database that provides an ODBC driver. EDB-ODBC provides connectivity between EDB Postgres Advanced Server (Advanced Server) and ODBC-compliant applications. + +This guide contains installation information for EDB-ODBC as well as information about creating data source definitions for EDB-ODBC. This guide also contains reference information that details the ODBC functionality supported by EDB-ODBC. \ No newline at end of file diff --git a/product_docs/docs/odbc_connector/12.2.0.1/index.mdx b/product_docs/docs/odbc_connector/12.2.0.1/index.mdx deleted file mode 100644 index 3cf5b6a676d..00000000000 --- a/product_docs/docs/odbc_connector/12.2.0.1/index.mdx +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: EDB ODBC Connector -productStub: true -directoryDefaults: - description: "EDB ODBC Connector Version 12.2.0.1 Documentation and release notes." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.1/conclusion.html" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.1/whats_new.html" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.1/genindex.html" - - "/edb-docs/p/edb-postgres-odbc-connector/12.2.0.1" - - "/edb-docs/d/edb-postgres-odbc-connector/user-guides/odbc-guide/12.2.0.1/index.html" ---- - - diff --git a/product_docs/docs/odbc_connector/12.2.0.2/05_edb-odbc_connection_properties.mdx b/product_docs/docs/odbc_connector/12.2.0.2/05_edb-odbc_connection_properties.mdx index 85b793f2e4c..f87c8c4ebd0 100644 --- a/product_docs/docs/odbc_connector/12.2.0.2/05_edb-odbc_connection_properties.mdx +++ b/product_docs/docs/odbc_connector/12.2.0.2/05_edb-odbc_connection_properties.mdx @@ -13,7 +13,10 @@ The following table describes the connection properties that you can specify thr | Database | Database | None | The name of the database to which you are connecting. | | Driver | Driver | EDB-ODBC | The name of the ODBC driver. | | Server | Servername | Localhost | The name or IP address of the server that you are connecting to. | -| dbms_name Description User Name Password | dbms_name Description Username Password | EnterpriseDB | Database system. Either EnterpriseDB or PostgreSQL. Descriptive name of the data source. The name of the user that this data source uses to connect to the server. The password of the user associated with this named data source. | +| dbms_name | dbms_name | EnterpriseDB | Database system. Either EnterpriseDB or PostgreSQL. | +| Description | Description | | Descriptive name of the data source. | +| User Name | Username | | The name of the user that this data source uses to connect to the server. | +| Password | Password | | The password of the user associated with this named data source. | | CPTimeout | CPTimeout | 0 | Number of seconds before a connection times out (in a connection pooling environment). | | Port | Port | 5444 | The TCP port that the postmaster is listening on. | | Protocol | Protocol | 7.4 | If specified, forces the driver to use the given protocol version. | diff --git a/product_docs/docs/pem/7.16/images/BART_backup_restore_advanced.png b/product_docs/docs/pem/7.16/images/BART_backup_restore_advanced.png index 63fc437a2e8..46745589fe3 100644 --- a/product_docs/docs/pem/7.16/images/BART_backup_restore_advanced.png +++ b/product_docs/docs/pem/7.16/images/BART_backup_restore_advanced.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:09e0de686454c757ceb690daf99ff3467e769e5ac9b4f306068ab648abf3625e -size 102068 +oid sha256:66ee0ea5e5345967a6f260c077b99765d3d197dd0c494b322d68264458f9fe7d +size 130996 diff --git a/product_docs/docs/pem/7.16/images/BART_backup_restore_general.png b/product_docs/docs/pem/7.16/images/BART_backup_restore_general.png index 6e9c24b34a9..ba054b5357a 100644 --- a/product_docs/docs/pem/7.16/images/BART_backup_restore_general.png +++ b/product_docs/docs/pem/7.16/images/BART_backup_restore_general.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:1768bd7af02645e43b8b205d3fa8f5b18d63e47c6bb602a8ae78c5a05ee026f6 -size 132531 +oid sha256:eceb1aa39589af750a104ac0f33789cbe70d7dcf99bc15c8a06c40b0266a8b05 +size 167499 diff --git a/product_docs/docs/pem/7.16/images/BART_backup_restore_notifications.png b/product_docs/docs/pem/7.16/images/BART_backup_restore_notifications.png index 427e940e340..88d0d8fb43d 100644 --- a/product_docs/docs/pem/7.16/images/BART_backup_restore_notifications.png +++ b/product_docs/docs/pem/7.16/images/BART_backup_restore_notifications.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:ac397d41556e18c2a42d6b8e13c2145b157bd937622251c36a44e4ca6e882bc3 -size 104710 +oid sha256:13266e4a056fd56d6dfe68d530ddf40b99e892ffd9b7475ed956ec704bb295dc +size 136974 diff --git a/product_docs/docs/pem/7.16/images/BART_backup_scheduler_general.png b/product_docs/docs/pem/7.16/images/BART_backup_scheduler_general.png index 3e365e2dfbc..3134147bee2 100644 --- a/product_docs/docs/pem/7.16/images/BART_backup_scheduler_general.png +++ b/product_docs/docs/pem/7.16/images/BART_backup_scheduler_general.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:84ebff3dc9a9d0c04adf5786447bea03ac956ae7ed27df3c03bdc73f8f9a5dfe -size 122504 +oid sha256:cd90950a5c822b1f9b04a68671c8b8a34430d89d2b60a5f841238437175f4131 +size 116357 diff --git a/product_docs/docs/pem/7.16/images/BART_backup_scheduler_schedule_general.png b/product_docs/docs/pem/7.16/images/BART_backup_scheduler_schedule_general.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/BART_backup_scheduler_schedule_notifications.png b/product_docs/docs/pem/7.16/images/BART_backup_scheduler_schedule_notifications.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/BART_backup_scheduler_schedule_repeat.png b/product_docs/docs/pem/7.16/images/BART_backup_scheduler_schedule_repeat.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/bart_backup_dashboard.png b/product_docs/docs/pem/7.16/images/bart_backup_dashboard.png index d1a95fa80fc..24465e51021 100644 --- a/product_docs/docs/pem/7.16/images/bart_backup_dashboard.png +++ b/product_docs/docs/pem/7.16/images/bart_backup_dashboard.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:97d6c4a4fe69e915c49b426a6f9333229928d8d5d01e8609b297060ec7e805f5 -size 182631 +oid sha256:5b7026bb4028208f6a0cf67aff2e938d09f964798dc2ce5b2ba5e3b6ebbe4ff6 +size 183782 diff --git a/product_docs/docs/pem/7.16/images/bart_backup_dialog_general.png b/product_docs/docs/pem/7.16/images/bart_backup_dialog_general.png index 1e450e93ef5..74f842c6e2e 100644 --- a/product_docs/docs/pem/7.16/images/bart_backup_dialog_general.png +++ b/product_docs/docs/pem/7.16/images/bart_backup_dialog_general.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:76bd8e14772540ea75f4a658aaeefe108aaea88ef8564f358fe3b9b1de6d20bf -size 125411 +oid sha256:2eab2dc539b82368fb91d82e58084639666f62b7944b4015db925a6d20b09795 +size 164967 diff --git a/product_docs/docs/pem/7.16/images/capacity_manager_metrics.png b/product_docs/docs/pem/7.16/images/capacity_manager_metrics.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/capacity_manager_opens.png b/product_docs/docs/pem/7.16/images/capacity_manager_opens.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/capacity_manager_options.png b/product_docs/docs/pem/7.16/images/capacity_manager_options.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/chart_icons.png b/product_docs/docs/pem/7.16/images/chart_icons.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/copy_probe_config.png b/product_docs/docs/pem/7.16/images/copy_probe_config.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/core_usage_report.png b/product_docs/docs/pem/7.16/images/core_usage_report.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_BART_server_general.png b/product_docs/docs/pem/7.16/images/create_BART_server_general.png old mode 100755 new mode 100644 index 2a9122b3986..b59fcce836a --- a/product_docs/docs/pem/7.16/images/create_BART_server_general.png +++ b/product_docs/docs/pem/7.16/images/create_BART_server_general.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:f7a5b5df04f2a1df9fed9a23274bcb31a43651cfef0492c228502378717cf61e -size 178118 +oid sha256:f5adb1234bdbf5526bbb08b14a7ee379496bb14d85a9ab5f06100acf24787831 +size 153735 diff --git a/product_docs/docs/pem/7.16/images/create_BART_server_misc.png b/product_docs/docs/pem/7.16/images/create_BART_server_misc.png index 613da0b689c..4010fa5004d 100644 --- a/product_docs/docs/pem/7.16/images/create_BART_server_misc.png +++ b/product_docs/docs/pem/7.16/images/create_BART_server_misc.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:62c0834dfa01f9e6044faf4110fd7a606010bceae823b98c75889ead0f12244f -size 242898 +oid sha256:7ce680197826ff066a199d359cc8d04887f5abd9659d1e80a5cb7fcc39061b10 +size 289158 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_general.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_general.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_notifications.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_notifications.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_schedules.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_schedules.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_schedules_exceptions.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_schedules_exceptions.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_schedules_repeat.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_schedules_repeat.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_sql.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_sql.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_steps.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_steps.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_steps_definition.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_steps_definition.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_pem_jobs_steps_definition_code.png b/product_docs/docs/pem/7.16/images/create_pem_jobs_steps_definition_code.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_server_advanced_tab.png b/product_docs/docs/pem/7.16/images/create_server_advanced_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_server_bart_general.png b/product_docs/docs/pem/7.16/images/create_server_bart_general.png old mode 100755 new mode 100644 index ed2f3218b84..6fb2cf9d893 --- a/product_docs/docs/pem/7.16/images/create_server_bart_general.png +++ b/product_docs/docs/pem/7.16/images/create_server_bart_general.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:5d92143e6d790004f176588aa5d91c28ece7e3e3e725a09d34c2bc7a3333a81e -size 156378 +oid sha256:a4ee2085e0d4cbcf7136a6187863faf5e67652798dff41697506a820640a64ea +size 192021 diff --git a/product_docs/docs/pem/7.16/images/create_server_bart_misc.png b/product_docs/docs/pem/7.16/images/create_server_bart_misc.png old mode 100755 new mode 100644 index fdd758a85ad..02027d67438 --- a/product_docs/docs/pem/7.16/images/create_server_bart_misc.png +++ b/product_docs/docs/pem/7.16/images/create_server_bart_misc.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:c22a97b6d4816e919f499c1aa13a486072c68267f4ac144edaebf7d71ea6a20c -size 175592 +oid sha256:d6df09f878b677a4cb0005277e8b8b5006929abae9b548d61f9299b9378993d3 +size 149367 diff --git a/product_docs/docs/pem/7.16/images/create_server_bart_tab.png b/product_docs/docs/pem/7.16/images/create_server_bart_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_server_connection_tab.png b/product_docs/docs/pem/7.16/images/create_server_connection_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_server_general_tab.png b/product_docs/docs/pem/7.16/images/create_server_general_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_server_pem_agent_tab.png b/product_docs/docs/pem/7.16/images/create_server_pem_agent_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_server_ssh_tunnel_tab.png b/product_docs/docs/pem/7.16/images/create_server_ssh_tunnel_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/create_server_ssl_tab.png b/product_docs/docs/pem/7.16/images/create_server_ssl_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/custom_probes.png b/product_docs/docs/pem/7.16/images/custom_probes.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/custom_probes_alt_code.png b/product_docs/docs/pem/7.16/images/custom_probes_alt_code.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/custom_probes_code.png b/product_docs/docs/pem/7.16/images/custom_probes_code.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/custom_probes_columns.png b/product_docs/docs/pem/7.16/images/custom_probes_columns.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/custom_probes_general.png b/product_docs/docs/pem/7.16/images/custom_probes_general.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/dashboard_configuration.png b/product_docs/docs/pem/7.16/images/dashboard_configuration.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/define_ops_dashboard.png b/product_docs/docs/pem/7.16/images/define_ops_dashboard.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/edb_logo.svg b/product_docs/docs/pem/7.16/images/edb_logo.svg index f24d1dfefee..400b5547ef3 100644 --- a/product_docs/docs/pem/7.16/images/edb_logo.svg +++ b/product_docs/docs/pem/7.16/images/edb_logo.svg @@ -1,19 +1,18 @@ - - - edb-logo-disc-dark - - - - \ No newline at end of file + + edb-logo-disc-dark-2 + + + + diff --git a/product_docs/docs/pem/7.16/images/email_group_add.png b/product_docs/docs/pem/7.16/images/email_group_add.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/email_group_delete.png b/product_docs/docs/pem/7.16/images/email_group_delete.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/email_groups_tab.png b/product_docs/docs/pem/7.16/images/email_groups_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/exclusion_constraint_columns.png b/product_docs/docs/pem/7.16/images/exclusion_constraint_columns.png index 62233679b7d..ec79ec24167 100644 --- a/product_docs/docs/pem/7.16/images/exclusion_constraint_columns.png +++ b/product_docs/docs/pem/7.16/images/exclusion_constraint_columns.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:65af27b1997a4ddf5b2b7c46473246c315759c9af486877803ef80ed235c94fa -size 95428 +oid sha256:6dc442e11086ede1ee586937773f54a364783c20c6a1ebc57ebdbdf0a718db72 +size 101062 diff --git a/product_docs/docs/pem/7.16/images/global_overview.png b/product_docs/docs/pem/7.16/images/global_overview.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/installing_pem_sql_plugin_windows_ready_to_install.png b/product_docs/docs/pem/7.16/images/installing_pem_sql_plugin_windows_ready_to_install.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_finish.png b/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_finish.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_in_progress.png b/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_in_progress.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_installation_directory.png b/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_installation_directory.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_license_agreement.png b/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_license_agreement.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_welcome.png b/product_docs/docs/pem/7.16/images/installing_pem_sql_profiler_plugin_windows_welcome.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/job_notifications_agent_level.png b/product_docs/docs/pem/7.16/images/job_notifications_agent_level.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/job_notifications_job_level.png b/product_docs/docs/pem/7.16/images/job_notifications_job_level.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/job_notifications_server_level.png b/product_docs/docs/pem/7.16/images/job_notifications_server_level.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/lgfullscreen.png b/product_docs/docs/pem/7.16/images/lgfullscreen.png old mode 100755 new mode 100644 index 25f3cc9e17b..663477d4c1d --- a/product_docs/docs/pem/7.16/images/lgfullscreen.png +++ b/product_docs/docs/pem/7.16/images/lgfullscreen.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:734eeb5b093de9d187a770709000502817f8b01242562029b2d07179c664004d -size 4206 +oid sha256:b929a0826ce728d1de88f3d474e119653bbf8665ca0852b345815accaf8e03cc +size 4963 diff --git a/product_docs/docs/pem/7.16/images/lginformation.png b/product_docs/docs/pem/7.16/images/lginformation.png old mode 100755 new mode 100644 index 4da2b27e4c7..d3eb8b8fb7f --- a/product_docs/docs/pem/7.16/images/lginformation.png +++ b/product_docs/docs/pem/7.16/images/lginformation.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:dc0b43993ecbb58882cb0521c200195337c85c2ed70e4189d9b99f35df3130b8 -size 4205 +oid sha256:1cb15190fb3ec0993bbb26c9e62ef82477fef0ea1e28c3005cf30374b1787a48 +size 4252 diff --git a/product_docs/docs/pem/7.16/images/lgpersonalize.png b/product_docs/docs/pem/7.16/images/lgpersonalize.png old mode 100755 new mode 100644 index 29bf34a76d0..93305cdcd36 --- a/product_docs/docs/pem/7.16/images/lgpersonalize.png +++ b/product_docs/docs/pem/7.16/images/lgpersonalize.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:956e73a53671184d30b80ddf931415ced488c4be1ce77f4b1a6c851f7187b12b -size 1685 +oid sha256:406acdf7e580b705a9a262547327997d03287541842acfb6e6f8715a5888f6c0 +size 5593 diff --git a/product_docs/docs/pem/7.16/images/lgrefresh.png b/product_docs/docs/pem/7.16/images/lgrefresh.png old mode 100755 new mode 100644 index 920a965716d..0342da18bab --- a/product_docs/docs/pem/7.16/images/lgrefresh.png +++ b/product_docs/docs/pem/7.16/images/lgrefresh.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:3cf7efaa0fef20aa391c0d6861ccef5035fa33e204b316e93335db67f3965d3a -size 4482 +oid sha256:8e7d9fa926021c3d08f1b3dacf5a7ae6925df335ff6926d8a9469943025957e0 +size 5232 diff --git a/product_docs/docs/pem/7.16/images/lm_import_rotation.png b/product_docs/docs/pem/7.16/images/lm_import_rotation.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/lm_scheduling.png b/product_docs/docs/pem/7.16/images/lm_scheduling.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/lm_server_select.png b/product_docs/docs/pem/7.16/images/lm_server_select.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/lm_welcome.png b/product_docs/docs/pem/7.16/images/lm_welcome.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/lm_what_to_log.png b/product_docs/docs/pem/7.16/images/lm_what_to_log.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/lm_when_to_log.png b/product_docs/docs/pem/7.16/images/lm_when_to_log.png old mode 100755 new mode 100644 index 825b7d6ae82..508bd7f8a97 --- a/product_docs/docs/pem/7.16/images/lm_when_to_log.png +++ b/product_docs/docs/pem/7.16/images/lm_when_to_log.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:15005d710c848af8d4322e94720863ba271c8714931d8297857e327c90626701 -size 170908 +oid sha256:2da212a5fee466fb9b42cd64b5dbcce46275c69441d02b4dbc2dfcec5436896f +size 151928 diff --git a/product_docs/docs/pem/7.16/images/lm_where_to_log.png b/product_docs/docs/pem/7.16/images/lm_where_to_log.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/nagios_alert_notification.png b/product_docs/docs/pem/7.16/images/nagios_alert_notification.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/nagios_server_configuration.png b/product_docs/docs/pem/7.16/images/nagios_server_configuration.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pe_direct_output.png b/product_docs/docs/pem/7.16/images/pe_direct_output.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pe_param_value.png b/product_docs/docs/pem/7.16/images/pe_param_value.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pe_report.png b/product_docs/docs/pem/7.16/images/pe_report.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pe_select_rules.png b/product_docs/docs/pem/7.16/images/pe_select_rules.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pe_select_servers.png b/product_docs/docs/pem/7.16/images/pe_select_servers.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pe_welcome.png b/product_docs/docs/pem/7.16/images/pe_welcome.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_agent_configurations_properties.png b/product_docs/docs/pem/7.16/images/pem_agent_configurations_properties.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_agent_job_notification_properties.png b/product_docs/docs/pem/7.16/images/pem_agent_job_notification_properties.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_agent_properties.png b/product_docs/docs/pem/7.16/images/pem_agent_properties.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_agent_welcome_dialog.png b/product_docs/docs/pem/7.16/images/pem_agent_welcome_dialog.png old mode 100644 new mode 100755 index afd4543cd13..2826417ef5a --- a/product_docs/docs/pem/7.16/images/pem_agent_welcome_dialog.png +++ b/product_docs/docs/pem/7.16/images/pem_agent_welcome_dialog.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:77b5a5e3f3178229671721c80b2b9a8720f181322294a15b1831810ec1680dd7 -size 168049 +oid sha256:8b4cdd11804ed54d1b7dcca82991879965383c2412b771867e8a912fd90b3b62 +size 70116 diff --git a/product_docs/docs/pem/7.16/images/pem_agent_windows_installation_complete.png b/product_docs/docs/pem/7.16/images/pem_agent_windows_installation_complete.png old mode 100644 new mode 100755 index 9ab505484ea..f082229cff3 --- a/product_docs/docs/pem/7.16/images/pem_agent_windows_installation_complete.png +++ b/product_docs/docs/pem/7.16/images/pem_agent_windows_installation_complete.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:2a35ca3cc9b9bebcc22f6b69128fc7bd675176fa7de83776d415ea5a4f44fb13 -size 192252 +oid sha256:1ad93776a1ab584c779b578a2177d3846015a47ecbeaea1683e13aec9af7965e +size 73322 diff --git a/product_docs/docs/pem/7.16/images/pem_alert_templates_general.png b/product_docs/docs/pem/7.16/images/pem_alert_templates_general.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_alert_templates_paramtab.png b/product_docs/docs/pem/7.16/images/pem_alert_templates_paramtab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_alert_templates_pdtab.png b/product_docs/docs/pem/7.16/images/pem_alert_templates_pdtab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_alert_templates_pre-def.png b/product_docs/docs/pem/7.16/images/pem_alert_templates_pre-def.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_alert_templates_sqltab.png b/product_docs/docs/pem/7.16/images/pem_alert_templates_sqltab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_alert_templates_tab.png b/product_docs/docs/pem/7.16/images/pem_alert_templates_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_create_new_chart_conf_chart.png b/product_docs/docs/pem/7.16/images/pem_create_new_chart_conf_chart.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_create_new_chart_select_metrics.png b/product_docs/docs/pem/7.16/images/pem_create_new_chart_select_metrics.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_create_new_chart_set_options.png b/product_docs/docs/pem/7.16/images/pem_create_new_chart_set_options.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_custom_dashboard_add_chart.png b/product_docs/docs/pem/7.16/images/pem_custom_dashboard_add_chart.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_custom_dashboard_add_section_name.png b/product_docs/docs/pem/7.16/images/pem_custom_dashboard_add_section_name.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_custom_dashboard_chart_details.png b/product_docs/docs/pem/7.16/images/pem_custom_dashboard_chart_details.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_custom_dashboard_configure_dashboard.png b/product_docs/docs/pem/7.16/images/pem_custom_dashboard_configure_dashboard.png old mode 100755 new mode 100644 index 8e8aeda9504..842a6bfe699 --- a/product_docs/docs/pem/7.16/images/pem_custom_dashboard_configure_dashboard.png +++ b/product_docs/docs/pem/7.16/images/pem_custom_dashboard_configure_dashboard.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:117f8866389a6e15232eb967b7e58795b7609628346d59de7c2624d9488a3f95 -size 87346 +oid sha256:2cd89614850ca0c2f8a62ac82131b1696571d8e62731656a1d9989066d644c06 +size 87029 diff --git a/product_docs/docs/pem/7.16/images/pem_dashboards_menu.png b/product_docs/docs/pem/7.16/images/pem_dashboards_menu.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_file_menu.png b/product_docs/docs/pem/7.16/images/pem_file_menu.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_help_menu.png b/product_docs/docs/pem/7.16/images/pem_help_menu.png old mode 100755 new mode 100644 index bada137dbb7..7a1c9eaf4dd --- a/product_docs/docs/pem/7.16/images/pem_help_menu.png +++ b/product_docs/docs/pem/7.16/images/pem_help_menu.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:2ce8f1be4f4606b419d33d4fe3576549c1d84d94f0b066c2340ce7d5cd3a1ccf -size 103415 +oid sha256:bdcded73e28b05f79311394d10f83f47c5548e9a2f012e1e5855ad2cba3d784a +size 70230 diff --git a/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_report.png b/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_report.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_report_finish.png b/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_report_finish.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_report_options.png b/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_report_options.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_select_analyzers.png b/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_select_analyzers.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_select_servers.png b/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_select_servers.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_welcome.png b/product_docs/docs/pem/7.16/images/pem_log_analysis_expert_welcome.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_logon.png b/product_docs/docs/pem/7.16/images/pem_logon.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts.png b/product_docs/docs/pem/7.16/images/pem_manage_charts.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts_completed.png b/product_docs/docs/pem/7.16/images/pem_manage_charts_completed.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts_custom_chart.png b/product_docs/docs/pem/7.16/images/pem_manage_charts_custom_chart.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_metrics.png b/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_metrics.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_options.png b/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_options.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_permissions.png b/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_permissions.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_template.png b/product_docs/docs/pem/7.16/images/pem_manage_charts_imported_template.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_charts_set_permissions.png b/product_docs/docs/pem/7.16/images/pem_manage_charts_set_permissions.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_manage_probes_tab.png b/product_docs/docs/pem/7.16/images/pem_manage_probes_tab.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_management_menu.png b/product_docs/docs/pem/7.16/images/pem_management_menu.png index 3b46a2bbac3..0c7ef5e431b 100644 --- a/product_docs/docs/pem/7.16/images/pem_management_menu.png +++ b/product_docs/docs/pem/7.16/images/pem_management_menu.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:beac0238581544429603c9ad481edb983facb5e9d8bb1ee72d13f3758c7b1306 -size 140484 +oid sha256:b05a6960efb85305b5cb37a23c152e1d1cb75e7a20f6288fea1103e77540e880 +size 144266 diff --git a/product_docs/docs/pem/7.16/images/pem_object_menu.png b/product_docs/docs/pem/7.16/images/pem_object_menu.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_server_config.png b/product_docs/docs/pem/7.16/images/pem_server_config.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/pem_server_existing_pg_installation_complete.png b/product_docs/docs/pem/7.16/images/pem_server_existing_pg_installation_complete.png old mode 100644 new mode 100755 index 1d8be91b97c..b6a648f6745 --- a/product_docs/docs/pem/7.16/images/pem_server_existing_pg_installation_complete.png +++ b/product_docs/docs/pem/7.16/images/pem_server_existing_pg_installation_complete.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:cc2dc5a2e1b4bcf0c4df423860578d52e43f2d29a162737fd3690ee5ffe88ff7 -size 200366 +oid sha256:7be53075196225a6c31e7f64796bcd22695bc315aa2edccee910a88efdae53f9 +size 121594 diff --git a/product_docs/docs/pem/7.16/images/pem_server_existing_pg_welcome_wizard.png b/product_docs/docs/pem/7.16/images/pem_server_existing_pg_welcome_wizard.png old mode 100644 new mode 100755 index 089e04d2012..2fff6107a44 --- a/product_docs/docs/pem/7.16/images/pem_server_existing_pg_welcome_wizard.png +++ b/product_docs/docs/pem/7.16/images/pem_server_existing_pg_welcome_wizard.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:72c94874da0e1ccfb5749872a412c21bbb958720e56877947802727756a19015 -size 168220 +oid sha256:9abee7f3b4667d5b05546c752f4843cfb4cb7caa8fdbc015daf9aed09c4b7a65 +size 96550 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_db_pem_created.png b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_db_pem_created.png old mode 100644 new mode 100755 index 8457b47457a..de6e51ec2d8 --- a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_db_pem_created.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_db_pem_created.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:89ca24c8a48cf006e338b546b5aa9125d03e26d4e4c76c3831496894e149e82c -size 118535 +oid sha256:f1a3ed29b0577ef9425af8742be385a208720a91b81a3828a33d156caf1dc2b5 +size 114825 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_complete.png b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_complete.png old mode 100644 new mode 100755 index 1d8be91b97c..46f1cb7b80d --- a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_complete.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_complete.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:cc2dc5a2e1b4bcf0c4df423860578d52e43f2d29a162737fd3690ee5ffe88ff7 -size 200366 +oid sha256:94ef5290590badbc3ccd0621eab76d1a4d201b1b7dafe9ea9cb45ff95f1a96e1 +size 129748 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_in_progress.png b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_in_progress.png old mode 100644 new mode 100755 index d94e9eecdb1..110dce43720 --- a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_in_progress.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_installation_in_progress.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:ae4a16ffbb9a9835965056cea6f167a12375e58e32f7cef84f0e6c4f8bfc4c69 -size 91907 +oid sha256:e04fc2b91742dcfb0f651e3b72c63b713adf90ba7ee50562d82754145dac5851 +size 85605 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_pgsql_credentials.png b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_pgsql_credentials.png old mode 100644 new mode 100755 index 5ac7c146ea3..98bd0523c62 --- a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_pgsql_credentials.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_pgsql_credentials.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:85887eeaae77b363ce7e3f5ef3fdd77c077f2345ff858bcfaefda357d61d52af -size 97934 +oid sha256:16e06cb358402e102ab24ed46eb6ec102c0899939a310ae58ec48cbe7e936718 +size 96241 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_prerequisites_checks.png b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_prerequisites_checks.png old mode 100644 new mode 100755 index f486d6a0bc6..0cbe509659c --- a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_prerequisites_checks.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_prerequisites_checks.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:8974fd28724974ccb887d6a7a2733e7bf1013c1709fc8c7e736d22310db2160f -size 138580 +oid sha256:d0f3acd60c536e5a59637a5215421fb6a430b720e17991013543f99e69ed2484 +size 99810 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_welcome_wizard.png b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_welcome_wizard.png old mode 100644 new mode 100755 index 089e04d2012..d9eb0f70516 --- a/product_docs/docs/pem/7.16/images/pem_server_on_same_host_welcome_wizard.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_same_host_welcome_wizard.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:72c94874da0e1ccfb5749872a412c21bbb958720e56877947802727756a19015 -size 168220 +oid sha256:3fc6f86efd7d8a67138a7daad797d6525c35b90c95d5bfcefc767840273f7bf3 +size 96995 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_PEM_httpd_installation_wizard.png b/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_PEM_httpd_installation_wizard.png old mode 100644 new mode 100755 index 28ee5e23966..9f70d230c3c --- a/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_PEM_httpd_installation_wizard.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_PEM_httpd_installation_wizard.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:1797aa3dbeda2932f0d24169690c80fe7b2b80f4268d75d56ec8edd3caf896a1 -size 152364 +oid sha256:bd0144e128fd94a66764a5c4c2c67b1542c76f12d369a2600fc7b12e460ba29c +size 107465 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_installation_complete.png b/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_installation_complete.png old mode 100644 new mode 100755 index 1d8be91b97c..dc9db63226d --- a/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_installation_complete.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_installation_complete.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:cc2dc5a2e1b4bcf0c4df423860578d52e43f2d29a162737fd3690ee5ffe88ff7 -size 200366 +oid sha256:852f5d7c3472aa7c1cc3f6bbd7b0828bf3122e2371c0fc57706375108a2b1a75 +size 129935 diff --git a/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_welcome_wizard.png b/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_welcome_wizard.png old mode 100644 new mode 100755 index 089e04d2012..2fff6107a44 --- a/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_welcome_wizard.png +++ b/product_docs/docs/pem/7.16/images/pem_server_on_separate_host_welcome_wizard.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:72c94874da0e1ccfb5749872a412c21bbb958720e56877947802727756a19015 -size 168220 +oid sha256:9abee7f3b4667d5b05546c752f4843cfb4cb7caa8fdbc015daf9aed09c4b7a65 +size 96550 diff --git a/product_docs/docs/pem/7.16/images/pem_tool_menu.png b/product_docs/docs/pem/7.16/images/pem_tool_menu.png index f6b311f91e5..dbfe4cc7f92 100644 --- a/product_docs/docs/pem/7.16/images/pem_tool_menu.png +++ b/product_docs/docs/pem/7.16/images/pem_tool_menu.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:49b28650e989a6682837149bfc84ac201e278a024899ea7d282fe67ad0ad1539 -size 224123 +oid sha256:cbde404878ae79a3303b0444f29db2c678948ab3ff54df5476d6c221ca0061c5 +size 112717 diff --git a/product_docs/docs/pem/7.16/images/pem_upgrade_agent_finish.png b/product_docs/docs/pem/7.16/images/pem_upgrade_agent_finish.png old mode 100644 new mode 100755 index 9ab505484ea..244dea22c72 --- a/product_docs/docs/pem/7.16/images/pem_upgrade_agent_finish.png +++ b/product_docs/docs/pem/7.16/images/pem_upgrade_agent_finish.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:2a35ca3cc9b9bebcc22f6b69128fc7bd675176fa7de83776d415ea5a4f44fb13 -size 192252 +oid sha256:ea202d9aa9ab35533b8ce4e4a2ccd3ee39e903634b6ae4e979b0b7b805f27ea7 +size 128032 diff --git a/product_docs/docs/pem/7.16/images/pem_upgrade_agent_welcome.png b/product_docs/docs/pem/7.16/images/pem_upgrade_agent_welcome.png old mode 100644 new mode 100755 index afd4543cd13..a24a802a6ea --- a/product_docs/docs/pem/7.16/images/pem_upgrade_agent_welcome.png +++ b/product_docs/docs/pem/7.16/images/pem_upgrade_agent_welcome.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:77b5a5e3f3178229671721c80b2b9a8720f181322294a15b1831810ec1680dd7 -size 168049 +oid sha256:361830d8d9dd3476c63f3b0c22ecedda4c108d2ecd2b05e58cad334139b5152a +size 100487 diff --git a/product_docs/docs/pem/7.16/images/pem_upgrade_server_finish.png b/product_docs/docs/pem/7.16/images/pem_upgrade_server_finish.png index 930f791aa4c..06613e08ee9 100644 --- a/product_docs/docs/pem/7.16/images/pem_upgrade_server_finish.png +++ b/product_docs/docs/pem/7.16/images/pem_upgrade_server_finish.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:585c86de37e8270a46ec943f2f10e137c1a4bfb314bbacbc6f83bf348e34363c -size 201508 +oid sha256:83b93297cba4075954f925034f70b1c2f175296da39a561e0c84f69acf8afabb +size 133203 diff --git a/product_docs/docs/pem/7.16/images/pem_upgrade_server_welcome.png b/product_docs/docs/pem/7.16/images/pem_upgrade_server_welcome.png index 0cb2cc561ca..19eb4b0ea07 100644 --- a/product_docs/docs/pem/7.16/images/pem_upgrade_server_welcome.png +++ b/product_docs/docs/pem/7.16/images/pem_upgrade_server_welcome.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:179e05f47ac62dbfb368fcc7d98b2e203222c7f7bd13bdb21b42c53612549311 -size 166999 +oid sha256:2d8d5f9d9ec6ea75b212c2cf5f9392e2c5b5b6eb6e4cc92b45616a65633084b9 +size 100998 diff --git a/product_docs/docs/pem/7.16/images/personalize_chart.png b/product_docs/docs/pem/7.16/images/personalize_chart.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/preferences_bart_servers_nodes.png b/product_docs/docs/pem/7.16/images/preferences_bart_servers_nodes.png index 9ba8f85e087..d73429a4ac4 100644 --- a/product_docs/docs/pem/7.16/images/preferences_bart_servers_nodes.png +++ b/product_docs/docs/pem/7.16/images/preferences_bart_servers_nodes.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:8760f28878cbac9703cf72721bb290596aacd3809c5cfe8f481a3c971c570dda -size 83099 +oid sha256:7ec6e6e2d8b3f22450ff61b5a3a40dc3b13f9f48de1600947dede64e08e9a590 +size 71052 diff --git a/product_docs/docs/pem/7.16/images/preferences_browser_display.png b/product_docs/docs/pem/7.16/images/preferences_browser_display.png index 7a408f288fb..4a2cee306fa 100644 --- a/product_docs/docs/pem/7.16/images/preferences_browser_display.png +++ b/product_docs/docs/pem/7.16/images/preferences_browser_display.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:33eb2bf003567cffadc6a8c11c5b8f8bc6dd13e5834ead6ebf179280d51d0af6 -size 181829 +oid sha256:31543c5273dfa21951a89e6b3a7352ec218940153be89d3e4c11bddd69c93b90 +size 157447 diff --git a/product_docs/docs/pem/7.16/images/preferences_browser_keyboard_shortcuts.png b/product_docs/docs/pem/7.16/images/preferences_browser_keyboard_shortcuts.png index 0015a85008b..ef38af8ea2e 100644 --- a/product_docs/docs/pem/7.16/images/preferences_browser_keyboard_shortcuts.png +++ b/product_docs/docs/pem/7.16/images/preferences_browser_keyboard_shortcuts.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:74e9b7c98725ba30389178d782ed221fcfa6e3493f80be97dce636723e7834dd -size 180622 +oid sha256:4f0f03df148d14c33b3dd5357cd325d1fb70b4d33168af36025b4c4bcd411c46 +size 154445 diff --git a/product_docs/docs/pem/7.16/images/preferences_browser_nodes.png b/product_docs/docs/pem/7.16/images/preferences_browser_nodes.png index 046806aec29..bc75e7da3ac 100644 --- a/product_docs/docs/pem/7.16/images/preferences_browser_nodes.png +++ b/product_docs/docs/pem/7.16/images/preferences_browser_nodes.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:4151e6fd83f6a1ce43c5aa2786b49e309cd0b240292f1df872efb7bdc2d96844 -size 125728 +oid sha256:76525a9b2e303df473f93dfb0d2abe41e83bdfb84558ef272646e1a3dcd974bd +size 118636 diff --git a/product_docs/docs/pem/7.16/images/preferences_browser_properties.png b/product_docs/docs/pem/7.16/images/preferences_browser_properties.png index 232f0606bf1..48fd1a5dfb2 100644 --- a/product_docs/docs/pem/7.16/images/preferences_browser_properties.png +++ b/product_docs/docs/pem/7.16/images/preferences_browser_properties.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:5fef55bedb9181e878cd576092e78c1b22edf464692c28002291227081ecb659 -size 100046 +oid sha256:caa17994deaac31bdd5f4d94d9d28cb79d4ea775b125eff418ea35b89c0d41ef +size 91936 diff --git a/product_docs/docs/pem/7.16/images/preferences_dashboard_display.png b/product_docs/docs/pem/7.16/images/preferences_dashboard_display.png index 7eba881d9c1..a10eb7fc664 100644 --- a/product_docs/docs/pem/7.16/images/preferences_dashboard_display.png +++ b/product_docs/docs/pem/7.16/images/preferences_dashboard_display.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:8baedc365fd2e55eda279174b18b1c29a126876d3f183089038a938840829d13 -size 143189 +oid sha256:83c3eb65f391221aa2b91e80f98c01085e998ed8636766c1a43fedbe9700bed9 +size 119898 diff --git a/product_docs/docs/pem/7.16/images/preferences_dashboard_graphs.png b/product_docs/docs/pem/7.16/images/preferences_dashboard_graphs.png index 6ea1ffb6a25..e86a067ea19 100644 --- a/product_docs/docs/pem/7.16/images/preferences_dashboard_graphs.png +++ b/product_docs/docs/pem/7.16/images/preferences_dashboard_graphs.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:0f2a1ccff8abc3c0d89745c02bea7b7bdf2003972e9827bf7e8fce857cddc646 -size 151777 +oid sha256:8b968367d95c83fa11d64cc8275f9639b9d75d03f38dc9315eda5ce9a0a3cbb4 +size 123530 diff --git a/product_docs/docs/pem/7.16/images/preferences_debugger_display.png b/product_docs/docs/pem/7.16/images/preferences_debugger_display.png index c416692593d..20acf8bb0eb 100644 --- a/product_docs/docs/pem/7.16/images/preferences_debugger_display.png +++ b/product_docs/docs/pem/7.16/images/preferences_debugger_display.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:956915366e0b1e0c86a33940d8522359792d4d58d85dcadf13a38970514500f6 -size 150246 +oid sha256:fed3111991e4eb9f2cde07812b27124c65790c16c5f1d820df3afadcd24b9dc2 +size 82213 diff --git a/product_docs/docs/pem/7.16/images/preferences_debugger_keyboard_shortcuts.png b/product_docs/docs/pem/7.16/images/preferences_debugger_keyboard_shortcuts.png index 87c6f9b15ba..890a1fc4e3d 100644 --- a/product_docs/docs/pem/7.16/images/preferences_debugger_keyboard_shortcuts.png +++ b/product_docs/docs/pem/7.16/images/preferences_debugger_keyboard_shortcuts.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:d908dd23ca3784574599f5dbc7597f1c850fe160635523a1fc61725361652a48 -size 169155 +oid sha256:7e5b975ffdadb629e356a737341760140a6e85a398004e2063c5c8dce16e37f0 +size 115075 diff --git a/product_docs/docs/pem/7.16/images/preferences_misc_themes.png b/product_docs/docs/pem/7.16/images/preferences_misc_themes.png index 455b6d9ba53..845cdc202e3 100644 --- a/product_docs/docs/pem/7.16/images/preferences_misc_themes.png +++ b/product_docs/docs/pem/7.16/images/preferences_misc_themes.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:62b44890fbf371403bd216f5f1b9aa34216da803bfc3327f131ff31acc432115 -size 116047 +oid sha256:d46c29d5854fc03f20c21d0237a113158bd89dd5f0f243ee7e2627abe0ac19d8 +size 103623 diff --git a/product_docs/docs/pem/7.16/images/preferences_misc_user_language.png b/product_docs/docs/pem/7.16/images/preferences_misc_user_language.png index 3136d9cb539..2c97e17f137 100644 --- a/product_docs/docs/pem/7.16/images/preferences_misc_user_language.png +++ b/product_docs/docs/pem/7.16/images/preferences_misc_user_language.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:c2c015ff7077240bdbb25d19a8294aa9ba5abec42a32c1dfa987d82b97b035ae -size 81365 +oid sha256:aaf187f8b8f310b1dc05fd02553e0bece4b472a666a18b8e0853dbf7dae8d6bd +size 73444 diff --git a/product_docs/docs/pem/7.16/images/preferences_paths_binary.png b/product_docs/docs/pem/7.16/images/preferences_paths_binary.png index 2469482f5ec..c7b1d826698 100644 --- a/product_docs/docs/pem/7.16/images/preferences_paths_binary.png +++ b/product_docs/docs/pem/7.16/images/preferences_paths_binary.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:89f0cf543229a5d2a40f8b2a35122ced862ac699479dca1d708c0ebc479be7ed -size 165305 +oid sha256:85ef07f3526ff0ca3a7eb1c98e94d2e30373712bc58bf97405ec72fb7b28f884 +size 130047 diff --git a/product_docs/docs/pem/7.16/images/preferences_paths_help.png b/product_docs/docs/pem/7.16/images/preferences_paths_help.png index b52b4e9602f..73d2d4cdeda 100644 --- a/product_docs/docs/pem/7.16/images/preferences_paths_help.png +++ b/product_docs/docs/pem/7.16/images/preferences_paths_help.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:51fb78c3185ad71455b146f95e7f89f69435c6a9a4ded27226b4161111dc9acf -size 149437 +oid sha256:fb8762a9a8ae408f998d8bcc12fbe63ad604099bf24fbbbb334b1660b0778236 +size 121415 diff --git a/product_docs/docs/pem/7.16/images/preferences_performance_diagnostic_display.png b/product_docs/docs/pem/7.16/images/preferences_performance_diagnostic_display.png index e56ae5ddf61..cc670de89c3 100644 --- a/product_docs/docs/pem/7.16/images/preferences_performance_diagnostic_display.png +++ b/product_docs/docs/pem/7.16/images/preferences_performance_diagnostic_display.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:9d0bfb13f8da59242860848496fcb53c3ac9b68a34b1047e4b7c9b51e127a6d5 -size 95543 +oid sha256:c8d087272d7b4379f680b00491791ad788e42484a2cfb7c7585fc8f3d11057d6 +size 79795 diff --git a/product_docs/docs/pem/7.16/images/preferences_schema_diff.png b/product_docs/docs/pem/7.16/images/preferences_schema_diff.png index a3aa784bf89..be6f943bb7d 100644 --- a/product_docs/docs/pem/7.16/images/preferences_schema_diff.png +++ b/product_docs/docs/pem/7.16/images/preferences_schema_diff.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:2f4abb68034e041c35962b85d12809df88e445a67184161d8415d7a187233229 -size 157266 +oid sha256:d392d889f356572b0825d1743946e4739282cba982f44fcb95ce5e921e29e0ae +size 83127 diff --git a/product_docs/docs/pem/7.16/images/preferences_sql_auto_completion.png b/product_docs/docs/pem/7.16/images/preferences_sql_auto_completion.png index af9fe95e7dd..c78593b2b5f 100644 --- a/product_docs/docs/pem/7.16/images/preferences_sql_auto_completion.png +++ b/product_docs/docs/pem/7.16/images/preferences_sql_auto_completion.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:da3db48ed4b4d5f611ecba6f2ecd4c34911097e2da1f17532241a5d575d91c8c -size 107325 +oid sha256:457291b7450e9c9d650485bc5d79b5fa657ee26b120ecbaee6df2a33c5412325 +size 86731 diff --git a/product_docs/docs/pem/7.16/images/preferences_sql_csv_output.png b/product_docs/docs/pem/7.16/images/preferences_sql_csv_output.png index d236ef5054b..f9764e3ff18 100644 --- a/product_docs/docs/pem/7.16/images/preferences_sql_csv_output.png +++ b/product_docs/docs/pem/7.16/images/preferences_sql_csv_output.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:8374271ad4ccd8818821f3ab0a2605182b5be10ba6228ab9cfd07b0e136bcb30 -size 128279 +oid sha256:4a28c4609f5384c52077352e2ae2496feee4abffadebbd38e935b0cc143279d8 +size 111514 diff --git a/product_docs/docs/pem/7.16/images/preferences_sql_display.png b/product_docs/docs/pem/7.16/images/preferences_sql_display.png index 40fd5d93f50..b58892e9126 100644 --- a/product_docs/docs/pem/7.16/images/preferences_sql_display.png +++ b/product_docs/docs/pem/7.16/images/preferences_sql_display.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:e1eaf490132defd8e6e89053264af34dfdaf19d0d69c2108f97c5690a8a110a4 -size 174697 +oid sha256:474ddb8f4954f77f6e97fcb5ab195dc43e90ece9ce5e969fa87b12aa16ec9da1 +size 146448 diff --git a/product_docs/docs/pem/7.16/images/preferences_sql_editor.png b/product_docs/docs/pem/7.16/images/preferences_sql_editor.png index 2601cd31834..1e4e0828de9 100644 --- a/product_docs/docs/pem/7.16/images/preferences_sql_editor.png +++ b/product_docs/docs/pem/7.16/images/preferences_sql_editor.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:9db1ec2663adf5c48af70b25ba66d96719bd38a6744c3d13099981ded4dba795 -size 232097 +oid sha256:0c4389dc67a221da3ff6df42acea32610ce350646ff8a6d32edb9ea2047288b1 +size 180387 diff --git a/product_docs/docs/pem/7.16/images/query_autocomplete.png b/product_docs/docs/pem/7.16/images/query_autocomplete.png index dae58e10d26..a1134163144 100644 --- a/product_docs/docs/pem/7.16/images/query_autocomplete.png +++ b/product_docs/docs/pem/7.16/images/query_autocomplete.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:4ff058cc376046ad1a93c62a243b111a2c1437a8f5406d194f703dc65838cc8c -size 78208 +oid sha256:7d49b94bd1fa8c1032317ae8afccbb64c61c3cb958ad1b7f11e4d5ac80ea53f1 +size 170647 diff --git a/product_docs/docs/pem/7.16/images/query_execute_section.png b/product_docs/docs/pem/7.16/images/query_execute_section.png index 873661b49a7..167950f5ae1 100644 --- a/product_docs/docs/pem/7.16/images/query_execute_section.png +++ b/product_docs/docs/pem/7.16/images/query_execute_section.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:8ebf16f2f330d85131a1d761a7cb33d799a91b991a359614a48ac993dbb1b6f5 -size 132114 +oid sha256:9c750b23a62992052cb54abfc3b40551c11725f8cb0596906160e06f2c544b30 +size 177965 diff --git a/product_docs/docs/pem/7.16/images/query_explain_analyze_statistics.png b/product_docs/docs/pem/7.16/images/query_explain_analyze_statistics.png index 0e2ea419423..efdd0dc3004 100644 --- a/product_docs/docs/pem/7.16/images/query_explain_analyze_statistics.png +++ b/product_docs/docs/pem/7.16/images/query_explain_analyze_statistics.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:5b10c8ea8841c8ba1fc35f7539dc5a05924fc4754182c061f4e8e149ad65d2fd -size 265839 +oid sha256:78d427c47b82582d9ea98e49d5076249b749d9b376418f3654e1d57944113844 +size 306419 diff --git a/product_docs/docs/pem/7.16/images/query_explain_analyze_table.png b/product_docs/docs/pem/7.16/images/query_explain_analyze_table.png index e65ceb51698..0f252348a26 100644 --- a/product_docs/docs/pem/7.16/images/query_explain_analyze_table.png +++ b/product_docs/docs/pem/7.16/images/query_explain_analyze_table.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:d78fa172694789b5e055105913545099c29bb12d73581b50eb551cf987761459 -size 279631 +oid sha256:c750ddb2d34b2c66463f2a75fb653bf1c32a9240e200b2ae9a30e7bd543eea06 +size 333182 diff --git a/product_docs/docs/pem/7.16/images/query_output_data.png b/product_docs/docs/pem/7.16/images/query_output_data.png index 4f5978d6b5f..be9c58a2405 100644 --- a/product_docs/docs/pem/7.16/images/query_output_data.png +++ b/product_docs/docs/pem/7.16/images/query_output_data.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:991689f5d267b5665e1cd94f2f76af4e1550fa32c46ef0c7e8e4beb1b6889198 -size 132475 +oid sha256:50bea1b298151f344ba99c17e089af860a367acc142da731ec55883eeaaeda22 +size 166373 diff --git a/product_docs/docs/pem/7.16/images/query_output_error.png b/product_docs/docs/pem/7.16/images/query_output_error.png index 6b1a481d8a4..753008b5141 100644 --- a/product_docs/docs/pem/7.16/images/query_output_error.png +++ b/product_docs/docs/pem/7.16/images/query_output_error.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:cc8c2d430501dc8beea730c3d4ea515f24c5224a24f89e7fe936ae0490c3823c -size 86112 +oid sha256:446fbaa32efaaa38bf346d5e4222a1c5865ca8f69c42d0820523d6eef27b2134 +size 126975 diff --git a/product_docs/docs/pem/7.16/images/query_output_explain_details.png b/product_docs/docs/pem/7.16/images/query_output_explain_details.png index cccd10a3b2b..745ed4bc6d2 100644 --- a/product_docs/docs/pem/7.16/images/query_output_explain_details.png +++ b/product_docs/docs/pem/7.16/images/query_output_explain_details.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:57ddaf635262b6af00d57f5925c878afb5e5f60688a4f7eff3ae1d0cd2188326 -size 155410 +oid sha256:e0cad71678df468801a70a3ab8f053f93cfbc1e7b21883a0176b834f7a78c7d6 +size 286662 diff --git a/product_docs/docs/pem/7.16/images/query_output_history.png b/product_docs/docs/pem/7.16/images/query_output_history.png index f2b1e6dd1cc..2369b2cd7d9 100644 --- a/product_docs/docs/pem/7.16/images/query_output_history.png +++ b/product_docs/docs/pem/7.16/images/query_output_history.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:2512ca5a67cdf3c85a472f4487e64df9c7ebf9323825233f34c11b8a1e6fa55c -size 222921 +oid sha256:e18207a8288524d56d0db1260b9209a6e9f440e53ae6eaf3b4a400194a884125 +size 287470 diff --git a/product_docs/docs/pem/7.16/images/query_output_messages.png b/product_docs/docs/pem/7.16/images/query_output_messages.png index e6123b15f2e..a6ec86626e2 100644 --- a/product_docs/docs/pem/7.16/images/query_output_messages.png +++ b/product_docs/docs/pem/7.16/images/query_output_messages.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:f3748914c01ba6fab0f4411787de69f58add1dc948e1d82f089f2778e2cd2186 -size 205783 +oid sha256:1f54c32d7de408ffaa5c87910f3930652dd279e18d4f401b57aa94648b8c1431 +size 100135 diff --git a/product_docs/docs/pem/7.16/images/query_sql_editor.png b/product_docs/docs/pem/7.16/images/query_sql_editor.png index 2259b4644b2..d76a458dbd9 100644 --- a/product_docs/docs/pem/7.16/images/query_sql_editor.png +++ b/product_docs/docs/pem/7.16/images/query_sql_editor.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:ffcddc606a5ef7ab6f2eeec405cbbe0a9ee76c0514aebf323fc94da12d4b00e6 -size 54579 +oid sha256:2b36230deca8dc727f8906ca58f0378961bad148670c42314135944c12367924 +size 70799 diff --git a/product_docs/docs/pem/7.16/images/query_tool.png b/product_docs/docs/pem/7.16/images/query_tool.png index bb351cdf423..07cada05cce 100644 --- a/product_docs/docs/pem/7.16/images/query_tool.png +++ b/product_docs/docs/pem/7.16/images/query_tool.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:d8cc3868cb4f395661deb60520979b452f8d9c8ed548f24c5d7c38c20f3b9a3f -size 158824 +oid sha256:43a7ba62d10b0c298a8e4f054f76571ae1c836f10b8584bd1499aa06a91efbeb +size 145387 diff --git a/product_docs/docs/pem/7.16/images/query_tool_connection_status.png b/product_docs/docs/pem/7.16/images/query_tool_connection_status.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/query_tool_editable_columns.png b/product_docs/docs/pem/7.16/images/query_tool_editable_columns.png index 3545e898dce..f644a326ca2 100644 --- a/product_docs/docs/pem/7.16/images/query_tool_editable_columns.png +++ b/product_docs/docs/pem/7.16/images/query_tool_editable_columns.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:954840261456cbb5288f55f47481f1656340b80202d1433bf0aa17df93617b61 -size 104849 +oid sha256:4da2071b26ce64ead3e4b04ae441d57cd1872dfa06506f2eb1166f16ce6232a8 +size 102517 diff --git a/product_docs/docs/pem/7.16/images/query_tool_message.png b/product_docs/docs/pem/7.16/images/query_tool_message.png index 344d84baf7b..1d3ccc76bd6 100644 --- a/product_docs/docs/pem/7.16/images/query_tool_message.png +++ b/product_docs/docs/pem/7.16/images/query_tool_message.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:03cd69621f5fdfd31a68f13d91a88e2352f6ce61da9bd4c8901baa23d9b0652f -size 59950 +oid sha256:346de3ed034860f54282ee793fbb7a5247c51dbda02fb23601a181bfc8c2b775 +size 99834 diff --git a/product_docs/docs/pem/7.16/images/query_toolbar.png b/product_docs/docs/pem/7.16/images/query_toolbar.png index 1f95458d233..4d6f8fc359b 100644 --- a/product_docs/docs/pem/7.16/images/query_toolbar.png +++ b/product_docs/docs/pem/7.16/images/query_toolbar.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:c350ad8bd13be86821e4eca18456d6de22e73c0d078ce4d9e1581b93ca5135d9 -size 25402 +oid sha256:beb62461b8cf8a312a05aa0253787aa6882409a3b036f45ed5712180a666a36b +size 30139 diff --git a/product_docs/docs/pem/7.16/images/query_toolbar_explain.png b/product_docs/docs/pem/7.16/images/query_toolbar_explain.png index 087bace5e25..640105f90cf 100644 --- a/product_docs/docs/pem/7.16/images/query_toolbar_explain.png +++ b/product_docs/docs/pem/7.16/images/query_toolbar_explain.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:1c6da165c454904f0c0ac60d2f31f2d5572c2d7d54103e7562ee28d8c8d247a2 -size 72007 +oid sha256:0a2e6a01ffe8f33bbb4e18b5a620b296de8670702fa0a17c4e7f621ceb0e688f +size 86335 diff --git a/product_docs/docs/pem/7.16/images/role_general.png b/product_docs/docs/pem/7.16/images/role_general.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/role_membership.png b/product_docs/docs/pem/7.16/images/role_membership.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/role_sql.png b/product_docs/docs/pem/7.16/images/role_sql.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/schema_diff_DDL_comparison.png b/product_docs/docs/pem/7.16/images/schema_diff_DDL_comparison.png old mode 100755 new mode 100644 index c0aee5d0716..617c6363f5f --- a/product_docs/docs/pem/7.16/images/schema_diff_DDL_comparison.png +++ b/product_docs/docs/pem/7.16/images/schema_diff_DDL_comparison.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:106583822b5c7da74ac3d162c5e0e77f8a5934cdd93f0c211db2c71b84dc59c4 -size 254644 +oid sha256:14c334a4540abe1591c0ac2c6d49c67aa4c890d1529cca552604ee2b5153535d +size 455486 diff --git a/product_docs/docs/pem/7.16/images/schema_diff_compare_button.png b/product_docs/docs/pem/7.16/images/schema_diff_compare_button.png old mode 100755 new mode 100644 index a8556001d26..391a5c04a97 --- a/product_docs/docs/pem/7.16/images/schema_diff_compare_button.png +++ b/product_docs/docs/pem/7.16/images/schema_diff_compare_button.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:b56a0885d840c64044e31053f0edd1d06799d001aa70863403b0b74911ecbad7 -size 66441 +oid sha256:559011ee99f717cedf3fe02a027dfcc9e6b4c14444836c03c15223f38a75e1fa +size 94760 diff --git a/product_docs/docs/pem/7.16/images/schema_diff_comparison_results.png b/product_docs/docs/pem/7.16/images/schema_diff_comparison_results.png old mode 100755 new mode 100644 index c590d6bb3ae..edb378f9798 --- a/product_docs/docs/pem/7.16/images/schema_diff_comparison_results.png +++ b/product_docs/docs/pem/7.16/images/schema_diff_comparison_results.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:f64f2de4db2c93c9bde78653bd0729550e00207400a125b7d512141c12cbd500 -size 150900 +oid sha256:5c71bfa73ffd792271cd4c8b11d60886414d68e3699a718a8214c586e89f2d40 +size 238585 diff --git a/product_docs/docs/pem/7.16/images/schema_diff_dialog.png b/product_docs/docs/pem/7.16/images/schema_diff_dialog.png old mode 100755 new mode 100644 index 9365dae2441..617c6363f5f --- a/product_docs/docs/pem/7.16/images/schema_diff_dialog.png +++ b/product_docs/docs/pem/7.16/images/schema_diff_dialog.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:2359faaf833c330fedfacb024b0ae29340f574a931f846c050268308c9a0a981 -size 255329 +oid sha256:14c334a4540abe1591c0ac2c6d49c67aa4c890d1529cca552604ee2b5153535d +size 455486 diff --git a/product_docs/docs/pem/7.16/images/schema_diff_filter_option.png b/product_docs/docs/pem/7.16/images/schema_diff_filter_option.png old mode 100755 new mode 100644 index 1ece30cefdf..b1b42cfda10 --- a/product_docs/docs/pem/7.16/images/schema_diff_filter_option.png +++ b/product_docs/docs/pem/7.16/images/schema_diff_filter_option.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:ddc51ee90a86101ccdefd7d61b021f88767da471e89e5ca98260571105ecd7cc -size 147446 +oid sha256:2c5ad9f01001223d834552aaf87ddc8cb5a78685e31b6f1f17b89d90da515ea7 +size 167049 diff --git a/product_docs/docs/pem/7.16/images/schema_diff_generate_script.png b/product_docs/docs/pem/7.16/images/schema_diff_generate_script.png old mode 100755 new mode 100644 index c3638420a90..617c6363f5f --- a/product_docs/docs/pem/7.16/images/schema_diff_generate_script.png +++ b/product_docs/docs/pem/7.16/images/schema_diff_generate_script.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:592d3afb7d2059ad4858b3031da5d2980a7c03c8377160d3ffc1900080699db2 -size 257990 +oid sha256:14c334a4540abe1591c0ac2c6d49c67aa4c890d1529cca552604ee2b5153535d +size 455486 diff --git a/product_docs/docs/pem/7.16/images/schema_diff_generate_script_query_editor.png b/product_docs/docs/pem/7.16/images/schema_diff_generate_script_query_editor.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/server_log_analysis_dashboard.png b/product_docs/docs/pem/7.16/images/server_log_analysis_dashboard.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/server_log_analysis_filter.png b/product_docs/docs/pem/7.16/images/server_log_analysis_filter.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/sp_create_new_trace.png b/product_docs/docs/pem/7.16/images/sp_create_new_trace.png old mode 100755 new mode 100644 index 8450a7bc561..fad6e17c63e --- a/product_docs/docs/pem/7.16/images/sp_create_new_trace.png +++ b/product_docs/docs/pem/7.16/images/sp_create_new_trace.png @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:3a936dd0c390a1412b10f00e65726d035c0b1fbc6636e6b9b8c3c9a96469198d -size 52160 +oid sha256:074793f92f4223e9413cf55d74862e892715dded387abab2f75adae38d006249 +size 70283 diff --git a/product_docs/docs/pem/7.16/images/sp_create_new_trace_executed.png b/product_docs/docs/pem/7.16/images/sp_create_new_trace_executed.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/sp_create_new_trace_periodic_job.png b/product_docs/docs/pem/7.16/images/sp_create_new_trace_periodic_job.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/sp_create_new_trace_schedule.png b/product_docs/docs/pem/7.16/images/sp_create_new_trace_schedule.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/sp_delete_trace.png b/product_docs/docs/pem/7.16/images/sp_delete_trace.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/sp_open_existing_trace.png b/product_docs/docs/pem/7.16/images/sp_open_existing_trace.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/sp_scheduled_traces.png b/product_docs/docs/pem/7.16/images/sp_scheduled_traces.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/system_configuration_report_pem_agents.png b/product_docs/docs/pem/7.16/images/system_configuration_report_pem_agents.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/system_configuration_report_pem_server_directory.png b/product_docs/docs/pem/7.16/images/system_configuration_report_pem_server_directory.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/system_configuration_report_pem_summary_and_summary.png b/product_docs/docs/pem/7.16/images/system_configuration_report_pem_summary_and_summary.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/table_general.png b/product_docs/docs/pem/7.16/images/table_general.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_apply_changes.png b/product_docs/docs/pem/7.16/images/tuning_wiz_apply_changes.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_changes_sum.png b/product_docs/docs/pem/7.16/images/tuning_wiz_changes_sum.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_configuration.png b/product_docs/docs/pem/7.16/images/tuning_wiz_configuration.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_confirm_chg.png b/product_docs/docs/pem/7.16/images/tuning_wiz_confirm_chg.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_generate_report.png b/product_docs/docs/pem/7.16/images/tuning_wiz_generate_report.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_report.png b/product_docs/docs/pem/7.16/images/tuning_wiz_report.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_server_sel.png b/product_docs/docs/pem/7.16/images/tuning_wiz_server_sel.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.16/images/tuning_wiz_welcome.png b/product_docs/docs/pem/7.16/images/tuning_wiz_welcome.png old mode 100755 new mode 100644 diff --git a/product_docs/docs/pem/7.6/index.mdx b/product_docs/docs/pem/7.6/index.mdx deleted file mode 100644 index 64f24ed8260..00000000000 --- a/product_docs/docs/pem/7.6/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "EDB Postgres Enterprise Manager" -productStub: true -directoryDefaults: - description: "EDB Postgres Enterprise Manager Version 7.6 Documentation and release notes. PostgreSQL GUI tool for monitoring and performance optimization." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-postgres-enterprise-manager/7.6" ---- - - diff --git a/product_docs/docs/pem/7.7/index.mdx b/product_docs/docs/pem/7.7/index.mdx deleted file mode 100644 index a02ec1a753f..00000000000 --- a/product_docs/docs/pem/7.7/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "EDB Postgres Enterprise Manager" -productStub: true -directoryDefaults: - description: "EDB Postgres Enterprise Manager Version 7.7 Documentation and release notes. PostgreSQL GUI tool for monitoring and performance optimization." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-postgres-enterprise-manager/7.7" ---- - - diff --git a/product_docs/docs/pem/7.8/index.mdx b/product_docs/docs/pem/7.8/index.mdx deleted file mode 100644 index e8f9ab16687..00000000000 --- a/product_docs/docs/pem/7.8/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "EDB Postgres Enterprise Manager" -productStub: true -directoryDefaults: - description: "EDB Postgres Enterprise Manager Version 7.8 Documentation and release notes. PostgreSQL GUI tool for monitoring and performance optimization." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-postgres-enterprise-manager/7.8" ---- - - diff --git a/product_docs/docs/pem/7.9/index.mdx b/product_docs/docs/pem/7.9/index.mdx deleted file mode 100644 index e96a6c790e1..00000000000 --- a/product_docs/docs/pem/7.9/index.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "EDB Postgres Enterprise Manager" -productStub: true -directoryDefaults: - description: "EDB Postgres Enterprise Manager Version 7.9 Documentation and release notes. PostgreSQL GUI tool for monitoring and performance optimization." - -legacyRedirectsGenerated: - # This list is generated by a script. If you need add entries, use the `legacyRedirects` key. - - "/edb-docs/p/edb-postgres-enterprise-manager/7.9" ---- - - diff --git a/product_docs/docs/pem/8.0/pem_sqlprofiler/01_installing_the_sql_profiler_plugin.mdx b/product_docs/docs/pem/8.0/pem_sqlprofiler/01_installing_the_sql_profiler_plugin.mdx index 37fad844ec1..2e06eb2d41c 100644 --- a/product_docs/docs/pem/8.0/pem_sqlprofiler/01_installing_the_sql_profiler_plugin.mdx +++ b/product_docs/docs/pem/8.0/pem_sqlprofiler/01_installing_the_sql_profiler_plugin.mdx @@ -105,9 +105,10 @@ Use the following steps to enable the plugin: ![Creating a new trace](../images/sp_create_new_trace.png) - To access SQL Profiler functionality, highlight the name of the database in the PEM `Browser` tree control; navigate through `Server` option under `Tools` menu to the `SQL Profiler` pull-aside menu. Menu options allow you to manage your SQL traces: + To access SQL Profiler functionality, highlight the name of the monitored Server/ database in the PEM `Browser` tree control; under `Tools` menu navigate through `Server` option to the `SQL Profiler` pull-aside menu. Menu options allow you to manage your SQL traces: - Select `Create trace`… to define a new trace. - Select `Open trace`… to open an existing trace. - Select `Delete trace(s)`… to delete one or more traces. - Select `View scheduled trace(s)`… to review a list of scheduled traces. +![Screen Shot 2021-05-06 at 4 58 23 PM](https://user-images.githubusercontent.com/5795880/117365029-b1687700-ae8c-11eb-850e-aa51c69abc54.png) diff --git a/static/_redirects b/static/_redirects index 7a10f54238f..0f7ec8a9217 100644 --- a/static/_redirects +++ b/static/_redirects @@ -3,6 +3,41 @@ # Docs 2.0 Redirects /docs/kubernetes/cloud_native_operator/* /docs/kubernetes/cloud_native_postgresql/:splat 302 +# BART +/docs/bart/2.4/* /docs/bart/latest/ 301 +/docs/bart/2.5.1/* /docs/bart/latest/ 301 +/docs/bart/2.5.2/* /docs/bart/latest/ 301 +/docs/bart/2.5.3/* /docs/bart/latest/ 301 +/docs/bart/2.5.4/* /docs/bart/latest/ 301 +/docs/bart/2.5.5/* /docs/bart/latest/ 301 +/docs/bart/2.5.7/* /docs/bart/latest/ 301 +/docs/bart/2.5.9/* /docs/bart/latest/ 301 +/docs/bart/2.6.1/* /docs/bart/latest/ 301 +/docs/bart/2.6.2/* /docs/bart/latest/ 301 + +# EPAS +/docs/epas/9.5/* /docs/epas/latest/ 301 + +# PEM +/docs/pem/7.6/* /docs/pem/latest/ 301 +/docs/pem/7.7/* /docs/pem/latest/ 301 +/docs/pem/7.8/* /docs/pem/latest/ 301 +/docs/pem/7.9/* /docs/pem/latest/ 301 + +# EFM +/docs/efm/3.6/* /docs/efm/latest/ 301 + +# MTK +/docs/migration_toolkit/53.0.1/* /docs/migration_toolkit/latest/ 301 + +# FDWs +/docs/hadoop_data_adapter/2.0/* /docs/hadoop_data_adapter/latest/ 301 +/docs/hadoop_data_adapter/2.0.5/* /docs/hadoop_data_adapter/latest/ 301 +/docs/jdbc_connector/42.2.12.1/* /docs/jdbc_connector/latest/ 301 +/docs/ocl_connector/13.1.4.1/* /docs/ocl_connector/latest/ 301 +/docs/odbc_connector/12.0.0.1/* /docs/odbc_connector/latest/ 301 +/docs/odbc_connector/12.2.0.1/* /docs/odbc_connector/latest/ 301 + # Super legacy redirects (Docs 0.5 -> 1.0) /docs/en/1.0/EDB_HA_SCALABILITY/* https://www.enterprisedb.com/edb-docs/d/edb-postgres-failover-manager/user-guides/high-availability-scalability-guide/3.2/:splat 301 /docs/en/1.0/EDB_Migration_Portal_v1.0/* https://www.enterprisedb.com/edb-docs/d/edb-postgres-migration-portal/user-guides/user-guide/1.0/:splat 301