db/pgbackrest
1
0
Fork 0
mirror of https://github.com/pgbackrest/pgbackrest.git synced 2025-10-30 23:37:45 +02:00
Code Issues Releases Activity

Add FAQ about exporting self-contained cluster.

Browse Source
This commit is contained in:
Stefan Fercot
2025-04-16 19:26:15 +02:00
committed by GitHub
parent c2f64bb03b
commit 9386920b79
2 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/xml/faq.xml
View File

@@ -130,6 +130,19 @@ process-max=1
<p>The various backup types require the same amount of time to restore. Restore retrieves files based on the backup manifest, which may reference files from a previous backup in the case of incremental or differential backups. While there could be differences in time spent <i>making</i> a given backup (depending on backup type), database size determines restore time (disk I/O, network I/O, etc. being equal).</p>
</section>
<!-- ======================================================================================================================= -->
<section id="self-contained-backup">
<title>How can I export a backup for use in a network-isolated environment?</title>
<p><backrest/> uses the repository not only to store backups and WAL archives but also to maintain essential metadata required for features such as compression, encryption, and file bundling. Because of this, simply copying a backup along with a subset of WAL files usually will not work unless very specific and restrictive conditions are met.</p>
<p>However, there is a workaround if your goal is to create a self-contained export of a database that you can transfer (e.g., via USB). You can make a backup with the <link url="https://pgbackrest.org/command.html#command-backup/category-command/option-archive-copy">--archive-copy</link> option enabled to ensure that the necessary WAL segments are stored along with the backup. Then, restore it using <link url="https://pgbackrest.org/command.html#command-restore/category-command/option-type">--type=none</link> --pg1-path=/your/target/path. This produces a restored PostgreSQL data directory with all required WAL files already placed in <code>pg_wal</code>, similar to what <file>pg_basebackup</file> would create.</p>
<p>You can then copy this directory to another system, and <postgres/> should be able to recover from it without needing access to the <backrest/> repository.</p>
<p>Please note that recovering this backup will not result in a timeline switch, which means that this cluster should not push WAL to the original repository that it was exported from. If the new cluster is in a network-isolated environment this should not be a problem.</p>
</section>
<!-- ======================================================================================================================= -->
<!-- <section id="different-server">
<title>How to restore a backup to a different server (for example, a production backup to a development server)?</title>

11
doc/xml/release/2025/2.55.0.xml
View File

@@ -309,6 +309,17 @@
<p>Clarify requirement for local/remote <backrest/> versions to match.</p>
</release-item>
<release-item>
<github-pull-request id="2605"/>
<release-item-contributor-list>
<release-item-contributor id="stefan.fercot"/>
<release-item-reviewer id="david.steele"/>
</release-item-contributor-list>
<p>Add FAQ about exporting self-contained cluster.</p>
</release-item>
<release-item>
<github-pull-request id="2538"/>