github/databasus
1
1
Fork 0
mirror of https://github.com/databasus/databasus.git synced 2026-04-06 00:32:03 +02:00
Code Issues 3 Packages Projects Releases Wiki Activity

add info about WAL

Browse Source
This commit is contained in:
Rostislav Dugin
2026-03-21 15:45:31 +03:00
parent 835cf74bb6
commit ca1cc6dd74
13 changed files with 1328 additions and 364 deletions
Download Patch File Download Diff File Expand all files Collapse all files

83
.gitignore vendored
View File

@@ -1,41 +1,42 @@
# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
# dependencies
/node_modules
/.pnp
.pnp.*
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/versions
# testing
/coverage
# next.js
/.next/
/out/
# production
/build
# misc
.DS_Store
*.pem
# debug
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-debug.log*
# env files (can opt-in for committing if needed)
.env*
# vercel
.vercel
# typescript
*.tsbuildinfo
next-env.d.ts
# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
# dependencies
/node_modules
/.pnp
.pnp.*
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/versions
# testing
/coverage
# next.js
/.next/
/out/
# production
/build
# misc
.DS_Store
*.pem
# debug
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-debug.log*
# env files (can opt-in for committing if needed)
.env*
# vercel
.vercel
# typescript
*.tsbuildinfo
next-env.d.ts
.claude/

3
app/components/DocsSidebarComponent.tsx
View File

@@ -13,6 +13,9 @@ const navItems: NavItem[] = [
{
title: "Installation",
href: "/installation",
children: [
{ title: "Agent mode", href: "/installation/agent" },
],
},
{
title: "Storages",

168
app/databasus-vs-barman/page.tsx
View File

@@ -81,13 +81,15 @@ export default function DatabasusVsBarmanPage() {
<h1 id="databasus-vs-barman">Databasus vs Barman</h1>
<p className="text-lg text-gray-400">
Databasus and Barman are both PostgreSQL backup tools, but they
take fundamentally different approaches. Databasus provides an
intuitive web interface for logical backups with team
collaboration features, while Barman (Backup and Recovery
Manager) is a command-line tool focused on physical backups and
Point-in-Time Recovery (PITR) for enterprise disaster recovery
scenarios.
Databasus and Barman are both PostgreSQL backup tools that
support physical backups, WAL archiving and Point-in-Time
Recovery. Databasus provides an intuitive web interface with
both logical and physical backup capabilities, team
collaboration features and support for multiple database
engines. Barman (Backup and Recovery Manager) is a
command-line tool with advanced features like rsync-based
incremental backups, streaming replication integration and
Barman-to-Barman geo-redundancy.
</p>
<h2 id="quick-comparison">Quick comparison</h2>
@@ -109,10 +111,10 @@ export default function DatabasusVsBarmanPage() {
<tr>
<td>Target audience</td>
<td data-label="Databasus">
Individuals, teams, enterprises
Individuals, teams, DBAs, enterprises
</td>
<td data-label="Barman">
DBAs, enterprises requiring PITR
DBAs, enterprises
</td>
</tr>
<tr>
@@ -129,13 +131,13 @@ export default function DatabasusVsBarmanPage() {
</tr>
<tr>
<td>Backup type</td>
<td data-label="Databasus">Logical (pg_dump)</td>
<td data-label="Databasus">Logical + Physical</td>
<td data-label="Barman">Physical (file-level)</td>
</tr>
<tr>
<td>Recovery options</td>
<td data-label="Databasus">
❌ No PITR (restore to any hour or day)
✅ PITR + logical restore
</td>
<td data-label="Barman">
✅ WAL-based PITR (second-precise)
@@ -143,11 +145,23 @@ export default function DatabasusVsBarmanPage() {
</tr>
<tr>
<td>Incremental backups</td>
<td data-label="Databasus">
Full backups with compression
</td>
<td data-label="Databasus">✅ WAL-based</td>
<td data-label="Barman">rsync-based incremental</td>
</tr>
<tr>
<td>Remote backups</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="Barman">
❌ No (requires filesystem access)
</td>
</tr>
<tr>
<td>Agent backups</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="Barman">
✅ Yes
</td>
</tr>
<tr>
<td>Multi-server management</td>
<td data-label="Databasus">Per-database scheduling</td>
@@ -229,6 +243,11 @@ export default function DatabasusVsBarmanPage() {
with comprehensive security, multiple storage destinations and
notification channels.
</li>
<li>
<strong>DBAs and disaster recovery</strong>: Physical
backups, WAL archiving and PITR for mission-critical systems
with near-zero data loss requirements.
</li>
</ul>
<h3 id="audience-barman">Barman audience</h3>
@@ -242,19 +261,16 @@ export default function DatabasusVsBarmanPage() {
<li>
<strong>Enterprise DBAs</strong>: Professionals who need
centralized backup management for multiple PostgreSQL servers
from a single location.
from a dedicated backup server.
</li>
<li>
<strong>Disaster recovery specialists</strong>: Teams
requiring second-precise Point-in-Time Recovery for
mission-critical systems.
<strong>Teams needing rsync-based incremental</strong>:
File-level diffing reduces backup time and network usage for
large clusters.
</li>
<li>
<strong>
Organizations with strict RPO/RTO requirements
</strong>
: Where Recovery Point Objective demands minimal data loss and
WAL-based recovery is essential.
<strong>Geo-redundancy requirements</strong>: Barman-to-Barman
replication for geographical redundancy across data centers.
</li>
</ul>
@@ -265,26 +281,33 @@ export default function DatabasusVsBarmanPage() {
with distinct advantages:
</p>
<h3 id="backup-databasus">Databasus: Logical backups</h3>
<h3 id="backup-databasus">
Databasus: Logical + Physical backups
</h3>
<p>
Databasus uses <code>pg_dump</code> for logical backups,
creating SQL representations of your data (in parallel mode):
Databasus supports both logical and physical backup
strategies:
</p>
<ul>
<li>
<strong>Portable</strong>: Backups can be restored to
different PostgreSQL versions or even different servers.
<strong>Logical backups (remote mode)</strong>: Uses{" "}
<code>pg_dump</code> for portable backups that can be
restored to different PostgreSQL versions. No agent required.
</li>
<li>
<strong>Physical backups (agent mode)</strong>: File-level
copies via <code>pg_basebackup</code> with continuous WAL
archiving and Point-in-Time Recovery.
</li>
<li>
<strong>Efficient compression</strong>: Uses zstd (level 5)
compression, reducing backup sizes by 4-8x with only ~20%
runtime overhead.
compression for both logical and physical backups.
</li>
<li>
<strong>Read-only access</strong>: Only requires SELECT
permissions, minimizing security risks.
<strong>Read-only access</strong>: Logical backups only
require SELECT permissions, minimizing security risks.
</li>
</ul>
@@ -328,21 +351,25 @@ export default function DatabasusVsBarmanPage() {
<ul>
<li>
<strong>Restore to any hour or day</strong>: With hourly,
daily, weekly, monthly or cron backup schedules, you can
restore to any backup point you&apos;ve configured.
<strong>Point-in-Time Recovery</strong>: Restore to any
specific second using WAL replay via the agent.
</li>
<li>
<strong>Full cluster restore</strong>: Restore the entire
database cluster to a specific point in time from physical
backups.
</li>
<li>
<strong>Logical restore</strong>: Restore from scheduled
logical backups to any backup point.
</li>
<li>
<strong>One-click restore</strong>: Download and restore
backups directly from the web interface.
logical backups directly from the web interface.
</li>
<li>
<strong>Parallel restores</strong>: Utilize multiple CPU cores
to speed up restoration of large backups.
</li>
<li>
<strong>Cross-version compatibility</strong>: Restore backups
to different PostgreSQL versions when needed.
<strong>Cross-version compatibility</strong>: Logical
backups can be restored to different PostgreSQL versions.
</li>
</ul>
@@ -369,17 +396,15 @@ export default function DatabasusVsBarmanPage() {
<div className="rounded-lg border border-[#ffffff20] bg-[#1f2937] px-4 pt-4 my-6">
<p className="text-gray-300 m-0">
<strong className="text-amber-400">Note:</strong> For most
applications, restoring to the nearest hour or day (as
Databasus provides) is sufficient. Second-precise PITR is
typically only required for mission-critical financial or
transactional systems where every transaction must be
recoverable.{" "}
<strong className="text-amber-400">Note:</strong> Both
tools support PITR. Barman additionally offers standby
creation from backups and SSH-based remote recovery to other
servers, which can be valuable for high availability setups.{" "}
<a
href="/faq#why-no-pitr"
href="/faq#pitr"
className="text-blue-400 hover:text-blue-300"
>
Learn why Databasus doesn&apos;t support PITR →
Learn how Databasus supports PITR →
</a>
</p>
</div>
@@ -714,8 +739,9 @@ export default function DatabasusVsBarmanPage() {
etc.
</li>
<li>
Restoring to any hour or day meets your recovery
requirements
You want to manage backups for multiple databases from a
single dashboard with scheduling, notifications and team
features
</li>
<li>
You want quick setup with minimal PostgreSQL expertise
@@ -734,16 +760,19 @@ export default function DatabasusVsBarmanPage() {
</p>
<ul className="text-white mb-0">
<li>
You require second-precise Point-in-Time Recovery for
mission-critical self-hosted systems
You need rsync-based incremental backups (file-level
diffing) for reduced transfer time
</li>
<li>
You need centralized management of multiple self-hosted
PostgreSQL servers from a dedicated backup server
You need streaming replication integration for real-time
WAL archiving
</li>
<li>
WAL archiving and streaming replication integration is
essential
You need Barman-to-Barman geographical redundancy
</li>
<li>
You need standby creation from backups for high
availability setups
</li>
<li>
You&apos;re comfortable with command-line tools and
@@ -752,24 +781,19 @@ export default function DatabasusVsBarmanPage() {
<li>
Your organization has dedicated DBA expertise available
</li>
<li>You need Barman-to-Barman geographical redundancy</li>
<li>
You&apos;re building a database platform and need to backup
customer databases with PITR capabilities
</li>
</ul>
</div>
<p>
For most use cases, from individual projects to enterprise
deployments, Databasus provides the right balance of power and
usability — and works seamlessly with both self-hosted and
cloud-managed databases. Databasus is suitable for comprehensive
backup management, not just backups. Barman remains the
specialized choice for organizations with strict PITR
requirements on self-hosted infrastructure and dedicated DBA
teams, or for teams building database platforms that need to
provide PITR capabilities to their customers.
Both tools support physical backups, WAL archiving and
PITR. Databasus provides the right balance of power and
usability with its web interface, team features and support
for both logical and physical backups — working seamlessly
with both self-hosted and cloud-managed databases. Barman
remains the specialized choice for organizations that need
rsync-based incremental backups, streaming replication
integration, Barman-to-Barman geo-redundancy or standby
creation from backups.
</p>
</article>
</div>

155
app/databasus-vs-pgbackrest/page.tsx
View File

@@ -82,11 +82,14 @@ export default function DatabasusVsPgBackRestPage() {
<p className="text-lg text-gray-400">
Databasus and pgBackRest are both powerful PostgreSQL backup
tools, but they serve fundamentally different purposes and
audiences. While Databasus provides an intuitive web interface
for individuals, teams and enterprises of all sizes, pgBackRest
is a specialized command-line tool designed primarily for DBAs
managing very large databases (500GB+).
tools that support physical backups, WAL archiving and
Point-in-Time Recovery. Databasus provides an intuitive web
interface with both logical and physical backup capabilities for
individuals, teams and enterprises. pgBackRest is a specialized
command-line tool with advanced features like block-level
incremental backups, differential backups and delta restore —
designed primarily for DBAs managing very large databases
(1TB+).
</p>
<h2 id="quick-comparison">Quick comparison</h2>
@@ -108,7 +111,7 @@ export default function DatabasusVsPgBackRestPage() {
<tr>
<td>Target audience</td>
<td data-label="Databasus">
Individuals, teams, enterprises
Individuals, teams, DBAs, enterprises
</td>
<td data-label="pgBackRest">
DBAs, large enterprises (~1TB+ DBs)
@@ -133,14 +136,12 @@ export default function DatabasusVsPgBackRestPage() {
</tr>
<tr>
<td>Backup type</td>
<td data-label="Databasus">Logical (full backup)</td>
<td data-label="Databasus">Logical + Physical</td>
<td data-label="pgBackRest">Physical (file-level)</td>
</tr>
<tr>
<td>Recovery options</td>
<td data-label="Databasus">
❌ No PITR (restore to any hour or day)
</td>
<td data-label="Databasus">✅ PITR + logical restore</td>
<td data-label="pgBackRest">
✅ WAL-based PITR (second-precise)
</td>
@@ -154,11 +155,31 @@ export default function DatabasusVsPgBackRestPage() {
</tr>
<tr>
<td>Incremental backups</td>
<td data-label="Databasus">
Full backups with compression
</td>
<td data-label="Databasus">✅ WAL-based</td>
<td data-label="pgBackRest">Block-level incremental</td>
</tr>
<tr>
<td>Differential backups</td>
<td data-label="Databasus">❌ No</td>
<td data-label="pgBackRest">✅ Yes</td>
</tr>
<tr>
<td>Delta restore</td>
<td data-label="Databasus">❌ No</td>
<td data-label="pgBackRest">✅ Yes (changed files only)</td>
</tr>
<tr>
<td>Remote backups</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="pgBackRest">
❌ No (requires filesystem access)
</td>
</tr>
<tr>
<td>Agent backups</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="pgBackRest">✅ Yes</td>
</tr>
<tr>
<td>Team features</td>
<td data-label="Databasus">
@@ -225,6 +246,11 @@ export default function DatabasusVsPgBackRestPage() {
with comprehensive security, multiple storage destinations and
notification channels.
</li>
<li>
<strong>DBAs and disaster recovery</strong>: Physical backups,
WAL archiving and PITR for mission-critical systems with
near-zero data loss requirements.
</li>
</ul>
<h3 id="audience-pgbackrest">pgBackRest audience</h3>
@@ -246,8 +272,9 @@ export default function DatabasusVsPgBackRestPage() {
proficiency.
</li>
<li>
<strong>Mission-critical systems</strong>: Where
second-precise Point-in-Time Recovery is a strict requirement.
<strong>Very large scale</strong>: Where block-level
incremental backups, differential backups and delta restore
are essential for performance.
</li>
</ul>
@@ -258,30 +285,33 @@ export default function DatabasusVsPgBackRestPage() {
with distinct advantages:
</p>
<h3 id="backup-databasus">Databasus: Logical backups</h3>
<h3 id="backup-databasus">
Databasus: Logical + Physical backups
</h3>
<p>
Databasus uses <code>pg_dump</code> for logical backups,
creating SQL representations of your data (in parallel mode):
Databasus supports both logical and physical backup strategies:
</p>
<ul>
<li>
<strong>Portable</strong>: Backups can be restored to
different PostgreSQL versions or even different servers.
<strong>Logical backups (remote mode)</strong>: Uses{" "}
<code>pg_dump</code> for portable backups that can be restored
to different PostgreSQL versions. Selective restore of
specific tables or schemas. No agent required.
</li>
<li>
<strong>Selective restore</strong>: Restore specific tables or
schemas without restoring the entire database.
<strong>Physical backups (agent mode)</strong>: File-level
copies via <code>pg_basebackup</code> with continuous WAL
archiving and Point-in-Time Recovery.
</li>
<li>
<strong>Efficient compression</strong>: Uses zstd (level 5)
compression, reducing backup sizes by 4-8x with only ~20%
runtime overhead.
for both backup types, reducing sizes by 4-8x.
</li>
<li>
<strong>Read-only access</strong>: Only requires SELECT
permissions, minimizing security risks.
<strong>Read-only access</strong>: Logical backups only
require SELECT permissions, minimizing security risks.
</li>
</ul>
@@ -323,21 +353,25 @@ export default function DatabasusVsPgBackRestPage() {
<ul>
<li>
<strong>Restore to any hour or day</strong>: With hourly,
daily, weekly, monthly or cron backup schedules, you can
restore to any backup point you&apos;ve configured.
<strong>Point-in-Time Recovery</strong>: Restore to any
specific second using WAL replay via the agent.
</li>
<li>
<strong>Full cluster restore</strong>: Restore the entire
database cluster to a specific point in time from physical
backups.
</li>
<li>
<strong>Logical restore</strong>: Restore from scheduled
logical backups to any backup point.
</li>
<li>
<strong>One-click restore</strong>: Download and restore
backups directly from the web interface.
logical backups directly from the web interface.
</li>
<li>
<strong>Parallel restores</strong>: Utilize multiple CPU cores
to speed up restoration of large backups.
</li>
<li>
<strong>Cross-version compatibility</strong>: Restore backups
to different PostgreSQL versions when needed.
<strong>Cross-version compatibility</strong>: Logical backups
can be restored to different PostgreSQL versions.
</li>
</ul>
@@ -364,17 +398,16 @@ export default function DatabasusVsPgBackRestPage() {
<div className="rounded-lg border border-[#ffffff20] bg-[#1f2937] px-4 pt-4 my-6">
<p className="text-gray-300 m-0">
<strong className="text-amber-400">Note:</strong> For most
applications, restoring to the nearest hour or day (as
Databasus provides) is sufficient. Second-precise PITR is
typically only required for mission-critical financial or
transactional systems where every transaction must be
recoverable.{" "}
<strong className="text-amber-400">Note:</strong> Both tools
support PITR. pgBackRest additionally offers delta restore
(only fetching changed files), differential backups and
standby creation from backups — features optimized for very
large databases.{" "}
<a
href="/faq#why-no-pitr"
href="/faq#pitr"
className="text-blue-400 hover:text-blue-300"
>
Learn why Databasus doesn&apos;t support PITR →
Learn how Databasus supports PITR →
</a>
</p>
</div>
@@ -660,8 +693,9 @@ export default function DatabasusVsPgBackRestPage() {
etc.
</li>
<li>
Restoring to any hour or day meets your recovery
requirements
You want to manage backups for multiple databases from a
single dashboard with scheduling, notifications and team
features
</li>
<li>
You want quick setup with minimal PostgreSQL expertise
@@ -683,11 +717,15 @@ export default function DatabasusVsPgBackRestPage() {
(~1TB+)
</li>
<li>
You require second-precise Point-in-Time Recovery for
mission-critical systems
You need block-level incremental backups for reduced storage
at very large scale
</li>
<li>
Block-level incremental backups are essential for your scale
You need differential backups or delta restore (only changed
files)
</li>
<li>
You need standby creation from backups for high availability
</li>
<li>
You&apos;re comfortable with command-line tools and
@@ -696,24 +734,21 @@ export default function DatabasusVsPgBackRestPage() {
<li>
Your organization has dedicated DBA expertise available
</li>
<li>
You use self-hosted PostgreSQL databases (not cloud-managed)
</li>
</ul>
</div>
<p>
For most use cases, from individual projects to production
databases and to enterprise deployments, Databasus provides the
right balance of power and usability — and works seamlessly with
both self-hosted and cloud-managed databases. Databasus is
suitable for comprehensive backup management, not just backups.
Both tools support physical backups, WAL archiving and PITR.
Databasus provides the right balance of power and usability with
its web interface, team features and support for both logical
and physical backups — working seamlessly with both self-hosted
and cloud-managed databases.
<br />
<br />
pgBackRest remains the specialized choice for DBAs managing very
large self-hosted databases where its advanced features become
necessary, or for teams building database platforms that need to
provide PITR capabilities to their customers.
large self-hosted databases where block-level incremental
backups, differential backups and delta restore become essential
at scale.
</p>
</article>
</div>

33
app/databasus-vs-pgbackweb/page.tsx
View File

@@ -160,6 +160,26 @@ export default function DatabasusVsPgBackWebPage() {
</td>
<td data-label="PgBackWeb">Manual Docker setup</td>
</tr>
<tr>
<td>Physical backups</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="PgBackWeb">❌ Not available</td>
</tr>
<tr>
<td>Incremental backups</td>
<td data-label="Databasus">✅ WAL-based</td>
<td data-label="PgBackWeb">❌ Not available</td>
</tr>
<tr>
<td>WAL archiving</td>
<td data-label="Databasus">✅ Continuous streaming</td>
<td data-label="PgBackWeb">❌ Not available</td>
</tr>
<tr>
<td>Point-in-Time Recovery</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="PgBackWeb">❌ Not available</td>
</tr>
</tbody>
</table>
@@ -183,6 +203,15 @@ export default function DatabasusVsPgBackWebPage() {
</li>
</ul>
<p>
Beyond logical backups, Databasus also supports physical
backups with continuous WAL archiving and Point-in-Time
Recovery through its agent mode. This enables incremental
backups, disaster recovery with near-zero data loss and
restore to any second between backups — features that
PgBackWeb does not offer at all.
</p>
<h2 id="storage-options">Storage options</h2>
<p>
@@ -503,6 +532,10 @@ export default function DatabasusVsPgBackWebPage() {
<li>Quick installation with one-line script or Docker</li>
<li>Intuitive modern UI with minimal learning curve</li>
<li>Permissive Apache 2.0 license for commercial use</li>
<li>
Physical backups, incremental backups, WAL archiving and
PITR for disaster recovery
</li>
</ul>
</div>

160
app/databasus-vs-wal-g/page.tsx
View File

@@ -81,13 +81,14 @@ export default function DatabasusVsWalGPage() {
<p className="text-lg text-gray-400">
Databasus and WAL-G are both capable backup tools that support
PostgreSQL, but they take fundamentally different approaches.
Databasus focuses on comprehensive backup management with an
intuitive web interface, while WAL-G is a command-line tool that
supports multiple database systems including PostgreSQL, MySQL,
MS SQL, MongoDB and others. If you need a user-friendly solution
for managing backups across multiple databases, Databasus offers
a more streamlined experience.
PostgreSQL with physical backups, WAL archiving and
Point-in-Time Recovery. Databasus focuses on comprehensive
backup management with an intuitive web interface and both
logical and physical backup capabilities. WAL-G is a
command-line tool that uses a custom streaming protocol for
slightly better performance, supports delta backups (changed
pages only) and covers more database engines including MS SQL,
FoundationDB and Greenplum.
</p>
<h2 id="quick-comparison">Quick comparison</h2>
@@ -125,7 +126,7 @@ export default function DatabasusVsWalGPage() {
</tr>
<tr>
<td>Backup type</td>
<td data-label="Databasus">Logical (pg_dump)</td>
<td data-label="Databasus">Logical + Physical</td>
<td data-label="WAL-G">Physical (WAL archiving)</td>
</tr>
<tr>
@@ -136,7 +137,7 @@ export default function DatabasusVsWalGPage() {
<tr>
<td>Recovery options</td>
<td data-label="Databasus">
❌ No PITR (restore to any hour or day)
✅ PITR + logical restore
</td>
<td data-label="WAL-G">
✅ WAL-based PITR (second-precise)
@@ -144,13 +145,25 @@ export default function DatabasusVsWalGPage() {
</tr>
<tr>
<td>Incremental backups</td>
<td data-label="Databasus">
Full backups with compression
</td>
<td data-label="Databasus">✅ WAL-based</td>
<td data-label="WAL-G">
Delta backups (changed pages only)
</td>
</tr>
<tr>
<td>Remote backups</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="WAL-G">
❌ No (local agent only)
</td>
</tr>
<tr>
<td>Agent backups</td>
<td data-label="Databasus">✅ Yes</td>
<td data-label="WAL-G">
✅ Yes
</td>
</tr>
<tr>
<td>Team features</td>
<td data-label="Databasus">
@@ -311,6 +324,16 @@ export default function DatabasusVsWalGPage() {
running PostgreSQL, MySQL, MariaDB or MongoDB benefit from
centralized backup management.
</li>
<li>
<strong>DBAs and disaster recovery</strong>: Physical
backups, WAL archiving and PITR for mission-critical systems
with near-zero data loss requirements.
</li>
<li>
<strong>DevOps engineers</strong>: Agent mode integrates
into existing infrastructure, while the web UI and API
provide visibility and control without custom scripting.
</li>
</ul>
<h3 id="audience-wal-g">WAL-G audience</h3>
@@ -335,9 +358,9 @@ export default function DatabasusVsWalGPage() {
integrate well.
</li>
<li>
<strong>Users needing PITR</strong>: Those requiring
second-precise Point-in-Time Recovery for mission-critical
systems.
<strong>Extended database support</strong>: Teams needing
backup for MS SQL, FoundationDB or Greenplum alongside
PostgreSQL.
</li>
</ul>
@@ -348,26 +371,33 @@ export default function DatabasusVsWalGPage() {
with distinct advantages:
</p>
<h3 id="backup-databasus">Databasus: Logical backups</h3>
<h3 id="backup-databasus">
Databasus: Logical + Physical backups
</h3>
<p>
Databasus uses <code>pg_dump</code> for logical backups,
creating SQL representations of your data:
Databasus supports both logical and physical backup
strategies:
</p>
<ul>
<li>
<strong>Portable</strong>: Backups can be restored to
different PostgreSQL versions or even different servers.
<strong>Logical backups (remote mode)</strong>: Uses{" "}
<code>pg_dump</code> for portable backups that can be
restored to different PostgreSQL versions. No agent required.
</li>
<li>
<strong>Physical backups (agent mode)</strong>: File-level
copies via <code>pg_basebackup</code> with continuous WAL
archiving and Point-in-Time Recovery.
</li>
<li>
<strong>Efficient compression</strong>: Uses zstd (level 5)
compression, reducing backup sizes by 4-8x with only ~20%
runtime overhead.
for both backup types, reducing sizes by 4-8x.
</li>
<li>
<strong>Read-only access</strong>: Only requires SELECT
permissions, minimizing security risks.
<strong>Read-only access</strong>: Logical backups only
require SELECT permissions, minimizing security risks.
</li>
</ul>
@@ -410,21 +440,25 @@ export default function DatabasusVsWalGPage() {
<ul>
<li>
<strong>Restore to any hour or day</strong>: With hourly,
daily, weekly, monthly or cron backup schedules, you can
restore to any backup point you&apos;ve configured.
<strong>Point-in-Time Recovery</strong>: Restore to any
specific second using WAL replay via the agent.
</li>
<li>
<strong>Full cluster restore</strong>: Restore the entire
database cluster to a specific point in time from physical
backups.
</li>
<li>
<strong>Logical restore</strong>: Restore from scheduled
logical backups to any backup point.
</li>
<li>
<strong>One-click restore</strong>: Download and restore
backups directly from the web interface.
logical backups directly from the web interface.
</li>
<li>
<strong>Parallel restores</strong>: Utilize multiple CPU cores
to speed up restoration of large backups.
</li>
<li>
<strong>Cross-version compatibility</strong>: Restore backups
to different PostgreSQL versions when needed.
<strong>Cross-version compatibility</strong>: Logical
backups can be restored to different PostgreSQL versions.
</li>
</ul>
@@ -451,17 +485,15 @@ export default function DatabasusVsWalGPage() {
<div className="rounded-lg border border-[#ffffff20] bg-[#1f2937] px-4 pt-4 my-6">
<p className="text-gray-300 m-0">
<strong className="text-amber-400">Note:</strong> For most
applications, restoring to the nearest hour or day (as
Databasus provides) is sufficient. Second-precise PITR is
typically only required for mission-critical financial or
transactional systems where every transaction must be
recoverable.{" "}
<strong className="text-amber-400">Note:</strong> Both
tools support PITR. WAL-G additionally offers delta restore
(fetching only changed pages) and uses a custom streaming
protocol for slightly better performance at scale.{" "}
<a
href="/faq#why-no-pitr"
href="/faq#pitr"
className="text-blue-400 hover:text-blue-300"
>
Learn why Databasus doesn&apos;t support PITR →
Learn how Databasus supports PITR →
</a>
</p>
</div>
@@ -804,8 +836,9 @@ export default function DatabasusVsWalGPage() {
You want built-in scheduling without external cron setup
</li>
<li>
Restoring to any hour or day meets your recovery
requirements
You want to manage backups for multiple databases from a
single dashboard with scheduling, notifications and team
features
</li>
<li>You want quick setup with minimal database expertise</li>
<li>Built-in backup encryption is important to you</li>
@@ -822,48 +855,39 @@ export default function DatabasusVsWalGPage() {
</p>
<ul className="text-white mb-0">
<li>
You manage multiple self-hosted database systems
(PostgreSQL, MySQL, MongoDB, etc.) and want a unified tool
You need delta backups (changed pages only) for reduced
storage and transfer time
</li>
<li>
You require second-precise Point-in-Time Recovery for
mission-critical self-hosted systems
</li>
<li>
Delta backups are important for reducing storage and
transfer time
You need support for MS SQL, FoundationDB or Greenplum
</li>
<li>
You prefer command-line tools and infrastructure-as-code
workflows
</li>
<li>
You&apos;re comfortable setting up cron jobs and custom
notification scripts
You want multiple compression algorithms (LZ4, LZMA,
Brotli, zstd) with fine-tuned control
</li>
<li>
Your team has DevOps expertise for CLI-based tool management
</li>
<li>
You&apos;re building a database platform and need to backup
customer databases with PITR capabilities
</li>
</ul>
</div>
<p>
For comprehensive backup management, Databasus offers a more
streamlined experience with its unified interface and built-in
features — and works seamlessly with both self-hosted and
cloud-managed databases. Databasus is suitable for comprehensive
backup management of production databases, not just backups.
Both tools support physical backups, WAL archiving and PITR.
Databasus provides comprehensive backup management with its
web interface, team features and support for both logical and
physical backups — working seamlessly with both self-hosted
and cloud-managed databases.
<br />
<br />
WAL-G remains an excellent choice for organizations with
self-hosted databases who prefer CLI-based workflows and need
advanced features like delta backups and precise PITR, or for
teams building database platforms that need to provide PITR
capabilities to their customers.
WAL-G remains an excellent choice for teams that prefer
CLI-based workflows and need its unique advantages: delta
backups (changed pages only), a custom streaming protocol for
slightly better performance and support for additional
database engines beyond PostgreSQL.
</p>
</article>
</div>

134
app/faq/page.tsx
View File

@@ -49,10 +49,10 @@ export default function FAQPage() {
mainEntity: [
{
"@type": "Question",
name: "Why does Databasus not use raw SQL dump format for PostgreSQL?",
name: "Why does Databasus not use raw SQL dump format for logical PostgreSQL backups?",
acceptedAnswer: {
"@type": "Answer",
text: "Databasus uses the custom format with zstd compression because it provides the most efficient backup and restore speed after extensive testing. The custom format with zstd compression level 5 offers the optimal balance between backup creation speed, restore speed and file size.",
text: "For logical backups, Databasus uses pg_dump's custom format with zstd compression because it provides the most efficient backup and restore speed after extensive testing. The custom format with zstd compression level 5 offers the optimal balance between backup creation speed, restore speed and file size.",
},
},
{
@@ -65,10 +65,10 @@ export default function FAQPage() {
},
{
"@type": "Question",
name: "Why doesn't Databasus support PITR (Point-in-Time Recovery)?",
name: "How does Databasus support PITR (Point-in-Time Recovery)?",
acceptedAnswer: {
"@type": "Answer",
text: "Databasus intentionally focuses on logical backups rather than PITR for several practical reasons: PITR tools typically need to be installed on the same server as your database; incremental backups cannot be restored without direct access to the database storage drive; managed cloud databases don't allow restoring external PITR backups; cloud providers already offer native PITR capabilities; and for 99% of projects, hourly or daily logical backups provide adequate recovery points without the operational complexity of WAL archiving.",
text: "Databasus supports PITR through the Databasus agent — a lightweight Go binary that runs alongside your PostgreSQL database. The agent continuously streams compressed WAL segments to Databasus and performs periodic physical backups via pg_basebackup. To restore, run the agent's restore command with a target timestamp — it downloads the full backup and WAL segments from Databasus, configures PostgreSQL recovery mode, and replays WAL to the exact target time. Suitable for disaster recovery with near-zero data loss, databases in closed networks and large databases where physical backups are faster than logical dumps.",
},
},
{
@@ -118,11 +118,13 @@ export default function FAQPage() {
</p>
<h2 id="why-no-raw-sql-dump">
Why does Databasus not use raw SQL dump format for PostgreSQL?
Why does Databasus not use raw SQL dump format for logical
PostgreSQL backups?
</h2>
<p>
Databasus uses the <code>pg_dump</code>&apos;s{" "}
For logical backups, Databasus uses{" "}
<code>pg_dump</code>&apos;s{" "}
<strong>custom format</strong> with{" "}
<strong>zstd compression at level 5</strong> instead of the
plain SQL format because it provides the most efficient balance
@@ -170,53 +172,95 @@ export default function FAQPage() {
directory.
</p>
<h2 id="why-no-pitr">
Why doesn&apos;t Databasus support PITR (Point-in-Time
Recovery)?
<h2 id="pitr">
How does Databasus support PITR (Point-in-Time Recovery)?
</h2>
<p>
Databasus intentionally focuses on logical backups rather than
PITR for several practical reasons:
Databasus supports PITR through the{" "}
<strong>Databasus agent</strong> — a lightweight Go binary that
runs alongside your PostgreSQL database. The agent connects
outbound to your Databasus instance, so the database never
needs to be exposed publicly.
</p>
<ol>
<li>
<strong>Complex setup requirements</strong> — PITR tools
typically need to be installed on the same server as your
database, requiring direct filesystem access and careful
configuration
</li>
<li>
<strong>Restoration limitations</strong> — incremental backups
cannot be restored without direct access to the database
storage drive
</li>
<li>
<strong>Cloud incompatibility</strong> — managed cloud
databases (AWS RDS, Google Cloud SQL, Azure) don&apos;t allow
restoring external PITR backups, making them useless for
cloud-hosted PostgreSQL
</li>
<li>
<strong>Built-in cloud PITR</strong> — cloud providers already
offer native PITR capabilities and even they typically default
to hourly or daily granularity
</li>
<li>
<strong>Practical sufficiency</strong> — for 99% of projects,
hourly or daily logical backups provide adequate recovery
points without the operational complexity of WAL archiving
</li>
</ol>
<p>
So instead of second-by-second restoration complexity, Databasus
prioritizes an intuitive UX for individuals and teams, making it
the most reliable tool for managing multiple databases and day
to day use.
<strong>How backups work:</strong>
</p>
<ul>
<li>
The agent runs two concurrent processes:{" "}
<strong>WAL streaming</strong> and{" "}
<strong>periodic physical backups</strong>
</li>
<li>
WAL segments are compressed with zstd and continuously
uploaded to Databasus with gap detection to ensure chain
integrity
</li>
<li>
Physical backups are created via{" "}
<code>pg_basebackup</code>, streamed as compressed TAR
directly to Databasus — no intermediate files on disk
</li>
<li>
Full backups are triggered on schedule or automatically when
the WAL chain is broken
</li>
</ul>
<p>
<strong>How restoration works:</strong>
</p>
<ul>
<li>
Run{" "}
<code>
databasus-agent restore --target-dir &lt;pgdata&gt;
--target-time &lt;timestamp&gt;
</code>
</li>
<li>
The agent downloads the full backup and all required WAL
segments from Databasus
</li>
<li>
It extracts the basebackup, configures PostgreSQL recovery
mode (<code>recovery.signal</code>,{" "}
<code>restore_command</code>,{" "}
<code>recovery_target_time</code>)
</li>
<li>
Start PostgreSQL — it replays WAL to the target time,
promotes to primary and resumes normal operations
</li>
</ul>
<p>
<strong>Suitable for:</strong>
</p>
<ul>
<li>
Disaster recovery with near-zero data loss — restore to any
second between backups
</li>
<li>
Self-hosted and on-premise databases where hourly or daily
logical backups are not granular enough
</li>
<li>
Databases in closed networks — the agent connects outbound
to Databasus, so no inbound access is needed
</li>
<li>
Large databases where physical backups are faster than
logical dumps
</li>
</ul>
<h2 id="ai-usage">How is AI used in Databasus development?</h2>
<p>

688
app/installation/agent/page.tsx Normal file
View File

@@ -0,0 +1,688 @@
import type { Metadata } from "next";
import { CopyButton } from "../../components/CopyButton";
import DocsNavbarComponent from "../../components/DocsNavbarComponent";
import DocsSidebarComponent from "../../components/DocsSidebarComponent";
import DocTableOfContentComponent from "../../components/DocTableOfContentComponent";
export const metadata: Metadata = {
title: "Agent Installation - Databasus Documentation",
description:
"Install the Databasus agent for physical backups, incremental backups, WAL archiving and Point-in-Time Recovery (PITR) of PostgreSQL databases.",
keywords: [
"Databasus agent",
"PostgreSQL physical backup",
"WAL archiving",
"PITR",
"Point-in-Time Recovery",
"pg_basebackup",
"incremental backup",
"disaster recovery",
"PostgreSQL agent",
"database backup agent",
],
openGraph: {
title: "Agent Installation - Databasus Documentation",
description:
"Install the Databasus agent for physical backups, incremental backups, WAL archiving and Point-in-Time Recovery (PITR) of PostgreSQL databases.",
type: "article",
url: "https://databasus.com/installation/agent",
},
twitter: {
card: "summary",
title: "Agent Installation - Databasus Documentation",
description:
"Install the Databasus agent for physical backups, incremental backups, WAL archiving and Point-in-Time Recovery (PITR) of PostgreSQL databases.",
},
alternates: {
canonical: "https://databasus.com/installation/agent",
},
robots: "index, follow",
};
export default function AgentInstallationPage() {
const downloadCommand = `curl -L -o databasus-agent "<DATABASUS_HOST>/api/v1/system/agent?arch=<ARCH>" && chmod +x databasus-agent`;
const postgresqlConf = `wal_level = replica
archive_mode = on
archive_command = 'cp %p <WAL_QUEUE_DIR>/%f.tmp && mv <WAL_QUEUE_DIR>/%f.tmp <WAL_QUEUE_DIR>/%f'`;
const postgresqlConfDocker = `wal_level = replica
archive_mode = on
archive_command = 'cp %p /wal-queue/%f.tmp && mv /wal-queue/%f.tmp /wal-queue/%f'`;
const pgHbaEntry = `host replication all 127.0.0.1/32 md5`;
const grantReplication = `ALTER ROLE <YOUR_PG_USER> WITH REPLICATION;`;
const createWalDir = `mkdir -p /opt/databasus/wal-queue`;
const walDirPermissions = `chown postgres:postgres /opt/databasus/wal-queue
chmod 755 /opt/databasus/wal-queue`;
const dockerVolumeExample = `# In your docker run command:
docker run ... -v /opt/databasus/wal-queue:/wal-queue ...
# Or in docker-compose.yml:
volumes:
- /opt/databasus/wal-queue:/wal-queue`;
const dockerWalDirPermissions = `# Inside the container (or via docker exec):
chown postgres:postgres /wal-queue`;
const startCommandHost = `./databasus-agent start \\
--databasus-host=<DATABASUS_HOST> \\
--db-id=<DB_ID> \\
--token=<YOUR_AGENT_TOKEN> \\
--pg-host=localhost \\
--pg-port=5432 \\
--pg-user=<YOUR_PG_USER> \\
--pg-password=<YOUR_PG_PASSWORD> \\
--pg-type=host \\
--pg-wal-dir=/opt/databasus/wal-queue`;
const startCommandFolder = `./databasus-agent start \\
--databasus-host=<DATABASUS_HOST> \\
--db-id=<DB_ID> \\
--token=<YOUR_AGENT_TOKEN> \\
--pg-host=localhost \\
--pg-port=5432 \\
--pg-user=<YOUR_PG_USER> \\
--pg-password=<YOUR_PG_PASSWORD> \\
--pg-type=host \\
--pg-host-bin-dir=<PATH_TO_PG_BIN_DIR> \\
--pg-wal-dir=/opt/databasus/wal-queue`;
const startCommandDocker = `./databasus-agent start \\
--databasus-host=<DATABASUS_HOST> \\
--db-id=<DB_ID> \\
--token=<YOUR_AGENT_TOKEN> \\
--pg-host=localhost \\
--pg-port=5432 \\
--pg-user=<YOUR_PG_USER> \\
--pg-password=<YOUR_PG_PASSWORD> \\
--pg-type=docker \\
--pg-docker-container-name=<CONTAINER_NAME> \\
--pg-wal-dir=/opt/databasus/wal-queue`;
const restoreCommand = `./databasus-agent restore \\
--databasus-host=<DATABASUS_HOST> \\
--db-id=<DB_ID> \\
--token=<YOUR_AGENT_TOKEN> \\
--backup-id=<BACKUP_ID> \\
--target-dir=<PGDATA_DIR>`;
const restoreCommandDocker = `./databasus-agent restore \\
--databasus-host=<DATABASUS_HOST> \\
--db-id=<DB_ID> \\
--token=<YOUR_AGENT_TOKEN> \\
--backup-id=<BACKUP_ID> \\
--pg-type=docker \\
--target-dir=<HOST_PGDATA_PATH>`;
const restoreCommandPitr = `./databasus-agent restore \\
--databasus-host=<DATABASUS_HOST> \\
--db-id=<DB_ID> \\
--token=<YOUR_AGENT_TOKEN> \\
--backup-id=<BACKUP_ID> \\
--target-dir=<PGDATA_DIR> \\
--target-time=<RFC3339_TIMESTAMP>`;
const archiveCommandCleanup = `# In <PGDATA_DIR>/postgresql.auto.conf, remove or comment out:
# archive_mode = on
# archive_command = '...'`;
return (
<>
{/* JSON-LD Structured Data */}
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify({
"@context": "https://schema.org",
"@type": "TechArticle",
headline: "Agent Installation - Databasus Documentation",
description:
"Install the Databasus agent for physical backups, incremental backups, WAL archiving and Point-in-Time Recovery (PITR) of PostgreSQL databases.",
author: {
"@type": "Organization",
name: "Databasus",
},
publisher: {
"@type": "Organization",
name: "Databasus",
logo: {
"@type": "ImageObject",
url: "https://databasus.com/logo.svg",
},
},
}),
}}
/>
<DocsNavbarComponent />
<div className="flex min-h-screen bg-[#0F1115]">
{/* Sidebar */}
<DocsSidebarComponent />
{/* Main Content */}
<main className="flex-1 min-w-0 px-4 py-6 sm:px-6 sm:py-8 lg:px-12">
<div className="mx-auto max-w-4xl">
<article className="prose prose-blue max-w-none">
<h1 id="agent-installation">Agent mode</h1>
<p className="text-lg text-gray-400">
The Databasus agent enables physical backups, incremental
backups, WAL archiving and Point-in-Time Recovery (PITR) for
PostgreSQL databases.
</p>
{/* When to use */}
<h2 id="when-to-use">When to use the agent</h2>
<p>
For most databases,{" "}
<strong>remote backups are the simplest option</strong>.
Databasus connects directly to the database over the network,
performs logical backups using pg_dump, and requires no
additional software on the database server. Remote backups work
with cloud-managed databases (RDS, Cloud SQL, Supabase) and
self-hosted instances alike.
</p>
<p>
The agent is designed for scenarios where remote backups are
not sufficient:
</p>
<ul>
<li>
<strong>Disaster recovery with PITR</strong> — restore to any
second between backups with near-zero data loss
</li>
<li>
<strong>Physical backups</strong> — file-level copy of the
entire database cluster, faster backup and restore for large
datasets
</li>
<li>
<strong>Databases not exposed publicly</strong> — the agent
connects outbound to Databasus, so the database never needs a
public endpoint
</li>
<li>
<strong>Incremental backups</strong> — continuous WAL segment
archiving combined with periodic base backups
</li>
</ul>
{/* In-app guided setup */}
<h2 id="in-app-setup">In-app guided setup</h2>
<p>
Databasus provides interactive installation and restore
instructions directly in the UI. When you open the agent
settings for a database, all commands are pre-filled with your
specific values: architecture, database ID, agent token,
Databasus host, and PostgreSQL deployment type. You can copy
each command and run it on your server.
</p>
<p>
The documentation below covers the same steps for reference and
for users who prefer to follow a guide outside the UI.
</p>
{/* Requirements */}
<h2 id="requirements">Requirements</h2>
<ul>
<li>
<strong>PostgreSQL 15 or newer</strong>
</li>
<li>
<strong>Linux</strong> (amd64 or arm64)
</li>
<li>
<strong>Network access</strong> from the agent to your
Databasus instance (outbound only — the database does not need
to be reachable from Databasus)
</li>
</ul>
{/* Installation */}
<h2 id="installation">Installation</h2>
<h3 id="step-1-download">Step 1 — Download the agent</h3>
<p>
Download the agent binary on the server where PostgreSQL runs.
Replace <code>&lt;DATABASUS_HOST&gt;</code> with your Databasus
instance URL and <code>&lt;ARCH&gt;</code> with{" "}
<code>amd64</code> or <code>arm64</code>.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{downloadCommand}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={downloadCommand} />
</div>
</div>
<h3 id="step-2-postgresql-conf">
Step 2 — Configure postgresql.conf
</h3>
<p>
Add or update these settings in your{" "}
<code>postgresql.conf</code>, then{" "}
<strong>restart PostgreSQL</strong>.
</p>
<p>
<strong>For host installations</strong> (replace{" "}
<code>&lt;WAL_QUEUE_DIR&gt;</code> with the actual path, e.g.{" "}
<code>/opt/databasus/wal-queue</code>):
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{postgresqlConf}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={postgresqlConf} />
</div>
</div>
<p>
<strong>For Docker installations</strong>, the{" "}
<code>archive_command</code> path (<code>/wal-queue</code>) is
the path <strong>inside the container</strong>. It must match
the volume mount target — see Step 5.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{postgresqlConfDocker}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={postgresqlConfDocker} />
</div>
</div>
<h3 id="step-3-pg-hba">Step 3 — Configure pg_hba.conf</h3>
<p>
Add this line to <code>pg_hba.conf</code>. This is required for{" "}
<code>pg_basebackup</code> to take full backups — not for
streaming replication. Adjust the address and auth method as
needed, then reload PostgreSQL.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{pgHbaEntry}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={pgHbaEntry} />
</div>
</div>
<h3 id="step-4-replication">
Step 4 — Grant replication privilege
</h3>
<p>
This is a PostgreSQL requirement for running{" "}
<code>pg_basebackup</code> — it does not set up a replica.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{grantReplication}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={grantReplication} />
</div>
</div>
<h3 id="step-5-wal-queue">
Step 5 — Create WAL queue directory
</h3>
<p>
PostgreSQL places WAL archive files here for the agent to
upload.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{createWalDir}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={createWalDir} />
</div>
</div>
<p>
Ensure the directory is writable by PostgreSQL and readable by
the agent:
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{walDirPermissions}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={walDirPermissions} />
</div>
</div>
<p>
<strong>For Docker installations</strong>, the WAL queue
directory must be a volume mount shared between the PostgreSQL
container and the host. The agent reads WAL files from the host
path, while PostgreSQL writes to the container path via{" "}
<code>archive_command</code>.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{dockerVolumeExample}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={dockerVolumeExample} />
</div>
</div>
<p>
Ensure the directory inside the container is owned by the{" "}
<code>postgres</code> user:
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{dockerWalDirPermissions}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={dockerWalDirPermissions} />
</div>
</div>
<h3 id="step-6-start">Step 6 — Start the agent</h3>
<p>
Replace placeholders in <code>&lt;ANGLE_BRACKETS&gt;</code> with
your actual values.
</p>
<p>
<strong>System-wide PostgreSQL</strong> (pg_basebackup available
in PATH):
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{startCommandHost}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={startCommandHost} />
</div>
</div>
<p>
<strong>PostgreSQL in a specific folder</strong> (e.g.{" "}
<code>/usr/lib/postgresql/17/bin</code>):
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{startCommandFolder}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={startCommandFolder} />
</div>
</div>
<p>
<strong>Docker</strong> (use the PostgreSQL port{" "}
<strong>inside the container</strong>, usually 5432, not the
host-mapped port):
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{startCommandDocker}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={startCommandDocker} />
</div>
</div>
<h3 id="after-installation">After installation</h3>
<ul>
<li>
The agent runs in the background after{" "}
<code>start</code>
</li>
<li>
Check status: <code>./databasus-agent status</code>
</li>
<li>
View logs: <code>databasus.log</code> in the working directory
</li>
<li>
Stop the agent: <code>./databasus-agent stop</code>
</li>
</ul>
{/* Restore */}
<h2 id="restore">Restore from agent backup</h2>
<p>
Restore a physical or incremental backup to a target directory.
For Point-in-Time Recovery, add the{" "}
<code>--target-time</code> flag to restore to a specific moment.
</p>
<h3 id="restore-step-1">Step 1 — Download the agent</h3>
<p>
Download the agent binary on the server where you want to
restore (same command as installation Step 1).
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{downloadCommand}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={downloadCommand} />
</div>
</div>
<h3 id="restore-step-2">Step 2 — Stop PostgreSQL</h3>
<p>
PostgreSQL must be stopped before restoring. The target directory
must be empty.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>pg_ctl -D &lt;PGDATA_DIR&gt; stop</code>
</pre>
</div>
<p>For Docker:</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>docker stop &lt;CONTAINER_NAME&gt;</code>
</pre>
</div>
<h3 id="restore-step-3">Step 3 — Run restore</h3>
<p>
Replace <code>&lt;YOUR_AGENT_TOKEN&gt;</code> with your agent
token and <code>&lt;PGDATA_DIR&gt;</code> with the path to an
empty PostgreSQL data directory.
</p>
<p>
<strong>Host installation:</strong>
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{restoreCommand}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={restoreCommand} />
</div>
</div>
<p>
<strong>Docker installation</strong> (
<code>&lt;HOST_PGDATA_PATH&gt;</code> is the path on the host
that will be mounted as the container&apos;s pgdata volume):
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{restoreCommandDocker}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={restoreCommandDocker} />
</div>
</div>
<p>
For <strong>Point-in-Time Recovery</strong> (PITR), add{" "}
<code>--target-time</code> with an RFC 3339 timestamp (e.g.{" "}
<code>2025-01-15T14:30:00Z</code>):
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{restoreCommandPitr}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={restoreCommandPitr} />
</div>
</div>
<h3 id="restore-step-4">
Step 4 — Handle archive_command
</h3>
<p>
The restored backup includes the original{" "}
<code>archive_command</code> configuration. PostgreSQL will fail
to archive WAL files after recovery unless you either:
</p>
<ul>
<li>
<strong>Re-attach the agent</strong> — mount the WAL queue
directory and start the Databasus agent on the restored
instance, same as the original setup.
</li>
<li>
<strong>Disable archiving</strong> — if you don&apos;t need
continuous backups yet, comment out or reset the archive
settings in <code>postgresql.auto.conf</code>:
</li>
</ul>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>{archiveCommandCleanup}</code>
</pre>
<div className="absolute right-2 top-2">
<CopyButton text={archiveCommandCleanup} />
</div>
</div>
<h3 id="restore-step-5">Step 5 — Start PostgreSQL</h3>
<p>
Start PostgreSQL to begin WAL recovery. It will automatically
replay WAL segments.
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>pg_ctl -D &lt;PGDATA_DIR&gt; start</code>
</pre>
</div>
<p>For Docker:</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>docker start &lt;CONTAINER_NAME&gt;</code>
</pre>
</div>
<h3 id="restore-step-6">Step 6 — Clean up</h3>
<p>
After recovery completes, remove the WAL restore directory:
</p>
<div className="relative my-6">
<pre className="overflow-x-auto rounded-lg bg-gray-900 p-4 text-sm text-gray-100">
<code>rm -rf &lt;PGDATA_DIR&gt;/databasus-wal-restore/</code>
</pre>
</div>
{/* How it works */}
<h2 id="how-it-works">How it works</h2>
<p>
The Databasus agent is a lightweight Go binary that runs two
concurrent processes:
</p>
<ul>
<li>
<strong>WAL streaming</strong> — picks up WAL segment files
from the queue directory approximately every 10 seconds and
uploads them to Databasus
</li>
<li>
<strong>Periodic base backups</strong> — runs{" "}
<code>pg_basebackup</code> on the configured schedule to
create full physical backups of the database cluster
</li>
</ul>
<p>
During restoration, the agent downloads the base backup and all
relevant WAL segments, then configures{" "}
<code>recovery.signal</code> and <code>restore_command</code> in{" "}
<code>postgresql.auto.conf</code>. When PostgreSQL starts, it
replays the WAL segments to reach the target recovery point.
</p>
<p>
The agent always initiates the connection to Databasus
(outbound). The database server does not need to accept incoming
connections from Databasus, making it suitable for private
networks and firewalled environments.
</p>
</article>
</div>
</main>
{/* Table of Contents */}
<DocTableOfContentComponent />
</div>
</>
);
}

31
app/installation/page.tsx
View File

@@ -460,6 +460,37 @@ sudo curl -sSL https://raw.githubusercontent.com/databasus/databasus/refs/heads/
server&apos;s IP address before starting the services.
</p>
<h2 id="agent-mode">
Agent mode (physical backups &amp; PITR)
</h2>
<p>
The installation above sets up the Databasus server, which
handles remote (logical) backups out of the box. For most
databases, remote backups are the simplest option — no
additional software is required on the database server.
</p>
<p>
For physical backups, incremental backups and Point-in-Time
Recovery (PITR), Databasus uses a lightweight agent that runs
alongside your PostgreSQL server. The agent is designed for
advanced scenarios: disaster recovery with near-zero data loss,
databases that cannot be exposed publicly, or large datasets
where file-level backups are faster than logical dumps.
</p>
<p>
See the{" "}
<a
href="/installation/agent"
className="text-blue-400 hover:text-blue-300"
>
Agent installation guide
</a>{" "}
for setup instructions.
</p>
<h2 id="getting-started">Getting started</h2>
<p>After installation:</p>

115
app/page.tsx
View File

@@ -188,7 +188,7 @@ export default function Index() {
name: "How is Databasus different from PgBackRest, Barman or pg_dump?",
acceptedAnswer: {
"@type": "Answer",
text: "Databasus provides a modern, user-friendly web interface instead of complex configuration files and command-line tools. While PgBackRest and Barman require extensive configuration and command-line expertise, Databasus offers intuitive point-and-click setup. Unlike raw pg_dump scripts, it includes built-in scheduling, compression, multiple storage destinations, health monitoring and real-time notifications — all managed through a simple web UI.",
text: "Databasus prefers simplicity — it provides a modern web interface to manage backups for many databases at once, with built-in scheduling, compression, multiple storage destinations, health monitoring and real-time notifications. At the same time, Databasus also works in agent mode for disaster recovery with WAL archiving and Point-in-Time Recovery. The agent connects from closed networks to the Databasus instance and streams backups, so databases that are not publicly exposed can still be backed up and managed from a single dashboard.",
},
},
{
@@ -207,6 +207,14 @@ export default function Index() {
text: "Yes! You can restore backups directly from storage (like S3, Google Drive, etc.) without Databasus itself. There is no vendor lock-in, even on this open source tool. With just your secret.key file, you can decrypt and restore any backup manually using standard database tools. This means if your Databasus instance is unavailable or you lose access to it, your backups remain fully recoverable.",
},
},
{
"@type": "Question",
name: "What backup types does Databasus support?",
acceptedAnswer: {
"@type": "Answer",
text: "Databasus supports logical, physical, WAL archiving and Point-in-Time Recovery (PITR). In remote mode, Databasus connects to the database over the network and performs logical backups — no agent needed. In agent mode, a lightweight Go agent runs alongside the database and connects to the Databasus instance, enabling physical backups with continuous WAL archiving and PITR for disaster recovery. Because the agent connects to Databasus, you can manage incremental backups for many databases from a single dashboard.",
},
},
],
}),
}}
@@ -800,7 +808,7 @@ export default function Index() {
</div>
</div>
{/* Card 11: Suitable for clouds */}
{/* Card 11: Backup types and modes */}
<div className="col-span-1 md:col-span-2 lg:col-span-2 p-5 md:p-6 flex flex-col md:flex-row gap-4 md:gap-6">
<div className="flex items-center justify-center w-6 h-6 rounded text-sm font-semibold border border-[#ffffff20] shrink-0">
11
@@ -808,16 +816,16 @@ export default function Index() {
<div>
<h3 className="text-lg md:text-xl 2xl:text-2xl font-bold mb-4 md:mb-5">
Suitable both for self-hosted and cloud databases
Logical, physical and incremental backups with PITR
</h3>
<p className="text-gray-400 text-sm md:text-base">
Databasus works seamlessly with cloud-hosted databases
including AWS RDS, Google Cloud SQL, Azure Database. This is
why Databasus does not support incremental backups: clouds
already have them, but usually you cannot restore external
PITR backup back to the cloud. Hourly and daily granularity
are enough for 99% of even large enterprise projects
Databasus supports logical, physical and incremental backups
with Point-in-Time Recovery. This makes Databasus suitable for
disaster recovery with WAL archiving and PITR, and works
equally well with self-hosted and cloud databases — use remote
mode for cloud-managed or publicly accessible DBs, and agent
mode for closed networks and host-installed databases
</p>
</div>
</div>
@@ -1322,16 +1330,21 @@ export default function Index() {
question="How is Databasus different from PgBackRest, Barman or pg_dump? Where can I read comparisons?"
answer={
<>
Unlike other tools, Databasus provides a way to manage many
databases for teams in a modern, user-friendly web interface
(instead of complex configuration files and command-line
tools). While PgBackRest and Barman just backups single
database, require extensive configuration and command-line
expertise — Databasus offers way to setup full backup
management for many databases. Unlike raw pg_dump scripts, it
includes built-in scheduling, compression, multiple storage
destinations, health monitoring and real-time notifications —
all managed through a simple web UI.
Databasus prefers simplicity — it provides a modern web
interface to manage backups for many databases at once,
instead of complex configuration files and command-line tools.
Unlike raw pg_dump scripts, it includes built-in scheduling,
compression, multiple storage destinations, health monitoring
and real-time notifications — all managed through a simple web
UI.
<br />
<br />
At the same time, Databasus also works in agent mode — similar
to WAL-G or pgBackRest — for disaster recovery with WAL
archiving and Point-in-Time Recovery. The agent connects from
closed networks to the Databasus instance, so databases that
are not publicly exposed can still be backed up and managed
from a single dashboard.
<br />
<br />
We have detailed comparison pages for popular backup tools:{" "}
@@ -1415,7 +1428,7 @@ export default function Index() {
<FaqItem
number="10"
question="Is Databasus an alternative to pg_dump?"
answer="Yes, Databasus is a modern alternative to pg_dump. Under the hood, Databasus extends pg_dump features, adds user-friendly web interface, automated scheduling, multiple storage destinations, real-time notifications, health monitoring and backup encryption. Think of Databasus as pg_dump with superpowers — you get all the reliability of pg_dump plus optimizations and enterprise features without writing shell scripts."
answer="For logical backups, yes — Databasus is a modern replacement for pg_dump. It extends pg_dump with a user-friendly web interface, automated scheduling, multiple storage destinations, real-time notifications, health monitoring and backup encryption. Think of it as pg_dump with superpowers — all the reliability plus enterprise features without writing shell scripts. Beyond logical backups, Databasus also supports agent mode where physical backups with WAL archiving are used for disaster recovery scenarios, providing incremental backups and Point-in-Time Recovery."
/>
<FaqItem
number="11"
@@ -1424,47 +1437,33 @@ export default function Index() {
/>
<FaqItem
number="12"
question="Why doesn't Databasus support PITR (Point-in-Time Recovery)?"
question="What backup types does Databasus support?"
answer={
<>
Databasus intentionally focuses on logical backups rather than
PITR for several practical reasons:
<ol className="list-decimal list-inside mt-3 space-y-2">
<li>
<strong>Complex setup requirements</strong> — PITR tools
typically need to be installed on the same server as your
database, requiring direct filesystem access and careful
configuration. You can backup only single database
(Databasus allows many)
</li>
<li>
<strong>Restoration limitations</strong> — incremental
backups cannot be restored without direct access to the
database storage drive
</li>
<li>
<strong>Cloud incompatibility</strong> — managed cloud
databases (AWS RDS, Google Cloud SQL, Azure, Supabase)
don&apos;t allow restoring external PITR backups, making
them useless for cloud-hosted PostgreSQL
</li>
<li>
<strong>Built-in cloud PITR</strong> — cloud providers
already offer native PITR capabilities, and even they
typically default to hourly or daily granularity
</li>
<li>
<strong>Practical sufficiency</strong> — for 99% of
projects, hourly or daily logical backups provide adequate
recovery points without the operational complexity of WAL
archiving
</li>
</ol>
Databasus supports logical, physical, WAL archiving and
Point-in-Time Recovery (PITR) — so it suits both those who
want simple remote backups and those who need a solid disaster
recovery tool.
<br />
So instead of second-by-second restoration complexity,
Databasus prioritizes an intuitive UX for individuals and
teams, making it the most reliable tool for managing multiple
databases and day to day use
<br />
<strong>Remote mode</strong> — Databasus connects to the
database over the network and performs logical backups (like
pg_dump). No agent or additional software required. Ideal for
cloud-managed and publicly accessible databases.
<br />
<br />
<strong>Agent mode</strong> — a lightweight agent runs
alongside the database and connects to the Databasus instance.
This enables physical backups with continuous WAL archiving
and PITR — designed for disaster recovery and near-zero data
loss. The agent streams backups directly to Databasus, so the
database never needs to be exposed publicly.
<br />
<br />
Because the agent connects to the Databasus instance, you can
manage incremental backups for many databases from a single
dashboard — unlike standalone tools like WAL-G or pgBackRest
where each database is managed separately.
</>
}
/>

82
app/pgdump-alternative/page.tsx
View File

@@ -80,12 +80,14 @@ export default function PgDumpAlternativePage() {
<h1 id="pgdump-alternative">pg_dump Alternative</h1>
<p className="text-lg text-gray-400">
Databasus is a PostgreSQL backup tool built on top of{" "}
For logical backups, Databasus is built on top of{" "}
<code>pg_dump</code>. Rather than replacing <code>pg_dump</code>
, Databasus extends its capabilities with backups management, a
web interface, automated scheduling, cloud storage integration,
notifications, team collaboration features and built-in
encryption.
encryption. Beyond logical backups, Databasus also supports
physical backups, incremental backups with WAL archiving and
Point-in-Time Recovery.
</p>
<h2 id="quick-comparison">Quick comparison</h2>
@@ -172,6 +174,26 @@ export default function PgDumpAlternativePage() {
<td data-label="pg_dump">❌ None</td>
<td data-label="Databasus">✅ Built-in health checks</td>
</tr>
<tr>
<td>Physical backups</td>
<td data-label="pg_dump">❌ No</td>
<td data-label="Databasus">✅ Yes</td>
</tr>
<tr>
<td>Incremental backups</td>
<td data-label="pg_dump">❌ No</td>
<td data-label="Databasus">✅ WAL-based</td>
</tr>
<tr>
<td>Point-in-Time Recovery</td>
<td data-label="pg_dump">❌ No</td>
<td data-label="Databasus">✅ Yes</td>
</tr>
<tr>
<td>Remote backups</td>
<td data-label="pg_dump">✅ Yes (CLI)</td>
<td data-label="Databasus">✅ Yes</td>
</tr>
</tbody>
</table>
@@ -298,6 +320,44 @@ export default function PgDumpAlternativePage() {
</li>
</ul>
<h2 id="beyond-pgdump">
Beyond pg_dump: Physical backups and PITR
</h2>
<p>
While Databasus builds on <code>pg_dump</code> for logical
backups, it also goes beyond what <code>pg_dump</code> can
offer:
</p>
<ul>
<li>
<strong>Physical backups</strong>: File-level copies of the
entire database cluster via <code>pg_basebackup</code>,
streamed through the Databasus agent. Faster backup and
restore for large databases.
</li>
<li>
<strong>Incremental backups with WAL archiving</strong>:
Continuous WAL segment streaming to Databasus, enabling
Point-in-Time Recovery — restore to any second between
backups.
</li>
<li>
<strong>Disaster recovery</strong>: Designed for near-zero
data loss requirements with physical base backups and
continuous WAL archiving.
</li>
</ul>
<p>
These features are available through the Databasus agent — a
lightweight binary that runs alongside the database and connects
to the Databasus instance. The database never needs to be
exposed publicly, making it suitable for closed networks and
self-hosted databases.
</p>
<h2 id="backup-automation">Backup automation</h2>
<p>
@@ -533,8 +593,8 @@ fi`}</code>
</li>
<li>
<strong>Unique backup encryption</strong>: Each backup file is
encrypted with a unique key derived from master key, backup
ID and random salt.
encrypted with a unique key derived from master key, backup ID
and random salt.
</li>
<li>
<strong>Read-only database access</strong>: Enforces SELECT
@@ -686,15 +746,19 @@ fi`}</code>
</li>
<li>You prefer a visual interface over command-line tools</li>
<li>You want automatic retention policies and cleanup</li>
<li>
You need physical backups, incremental backups or
Point-in-Time Recovery for disaster recovery
</li>
</ul>
</div>
<p>
Databasus doesn&apos;t replace <code>pg_dump</code> — it wraps
it with the features needed for production backup management.
You&apos;re still getting <code>pg_dump</code>&apos;s reliable,
portable logical backups, with automation, security and team
features built on top.
Databasus builds on <code>pg_dump</code> for logical backups and
extends it with automation, security and team features. Beyond
that, Databasus also supports physical backups, incremental
backups with WAL archiving and Point-in-Time Recovery —
capabilities that <code>pg_dump</code> simply cannot provide.
</p>
</article>
</div>

6
app/sitemap.ts
View File

@@ -19,6 +19,12 @@ export default function sitemap(): MetadataRoute.Sitemap {
changeFrequency: "weekly",
priority: 0.9,
},
{
url: `${baseUrl}/installation/agent`,
lastModified: currentDate,
changeFrequency: "monthly",
priority: 0.8,
},
{
url: `${baseUrl}/access-management`,
lastModified: currentDate,

34
public/llms.txt
View File

@@ -26,6 +26,9 @@
- Retention policies: time period, count, GFS (Grandfather-Father-Son) and size limits
- Suitable for single developers, DevOps teams, organizations, startups, system administrators and IT departments
- Supports multiple databases: PostgreSQL, MySQL, MariaDB and MongoDB
- Backup types: logical, physical and incremental with WAL archiving
- Point-in-Time Recovery (PITR) for disaster recovery with near-zero data loss
- Connection modes: remote (over network, no agent needed) and agent (for closed networks and physical/incremental backups)
## Supported Databases
@@ -34,6 +37,17 @@
- MariaDB
- MongoDB
## Backup Types
- **Logical**: Native dump of the database in its engine-specific binary format. Compressed and streamed directly to storage with no intermediate files. Works via remote connection — no agent needed. A modern replacement for pg_dump with scheduling, encryption and UI
- **Physical**: File-level copy of the entire database cluster. Faster backup and restore for large datasets compared to logical dumps. Requires agent
- **Incremental**: Physical base backup combined with continuous WAL segment archiving. Enables Point-in-Time Recovery (PITR) — restore to any second between backups. Designed for disaster recovery and near-zero data loss requirements. Requires agent
## Connection Types
- **Remote**: Databasus connects directly to the database over the network. No agent or additional software required. Works with cloud-managed databases (AWS RDS, Google Cloud SQL, Azure Database) and any publicly accessible or network-reachable database. Ideal for simple scheduled backups
- **Agent**: A lightweight Databasus agent runs alongside the database and connects to the Databasus instance. The database never needs to be exposed publicly. Enables physical and incremental backups with WAL archiving and PITR. Suitable for closed networks, host-installed databases, Docker containers and scenarios requiring incremental backups or disaster recovery. Because the agent connects to Databasus, you can manage incremental backups for many databases from a single dashboard
## Documentation
### Installation
@@ -58,7 +72,7 @@ Content: Detailed privacy policy explaining how Databasus respects user privacy
### FAQ - Frequently Asked Questions
URL: /faq
Content: Frequently asked questions about Databasus. Includes questions about backup formats, installation directory, PITR support and AI usage in development.
Content: Frequently asked questions about Databasus. Includes questions about backup formats, installation directory, backup types, PITR, disaster recovery, connection modes and AI usage in development.
#### How to backup localhost databases
URL: /faq/localhost
@@ -188,6 +202,10 @@ Databasus is suitable for:
## Backup Features
- **Logical Backups**: Native database dumps via remote connection, no agent needed
- **Physical Backups**: File-level copy of the database cluster for faster backup and restore of large datasets (requires agent)
- **Incremental Backups with WAL Archiving**: Continuous WAL segment archiving with Point-in-Time Recovery (requires agent)
- **Point-in-Time Recovery (PITR)**: Restore to any second between backups for disaster recovery and near-zero data loss
- **Compression**: Balanced compression with 4-8x size reduction
- **Scheduling**: Flexible scheduling with exact time specification
- **Health Checks**: Configurable database monitoring
@@ -209,7 +227,7 @@ Databasus supports flexible retention policies to automatically manage backup st
## FAQ
### How is Databasus different from PgBackRest, Barman or pg_dump?
Databasus is a tool to manage backups of multiple databases. It not only dump DB like other tools, but also provides a modern, user-friendly web interface instead of complex configuration files and command-line tools. While PgBackRest and Barman require extensive configuration and command-line expertise suitable for single DB only. Databasus offers intuitive point-and-click setup. Unlike raw pg_dump scripts, it includes built-in scheduling, compression, multiple storage destinations, health monitoring and real-time notifications - all managed through a simple web UI. It's the UX-friendly alternative for developers and DevOps teams who want powerful backup capabilities without the complexity.
Databasus prefers simplicity — it provides a modern web interface to manage backups for many databases at once, with built-in scheduling, compression, multiple storage destinations, health monitoring and real-time notifications. Unlike PgBackRest and Barman which require extensive configuration and command-line expertise for a single database, Databasus offers intuitive point-and-click setup for multiple databases. At the same time, Databasus also works in agent mode — similar to WAL-G or pgBackRest — for disaster recovery with WAL archiving and Point-in-Time Recovery. The agent connects from closed networks to the Databasus instance, so databases that are not publicly exposed can still be backed up and managed from a single dashboard.
### Which databases does Databasus support?
Databasus supports PostgreSQL, MySQL, MariaDB and MongoDB. However, Databasus was originally created specifically for PostgreSQL and maintains its primary focus on it — providing 100% excellent support and maximum efficiency for PostgreSQL backups. While MySQL, MariaDB and MongoDB are fully supported, PostgreSQL remains the core priority with the most optimized features and ongoing development.
@@ -223,14 +241,8 @@ We have detailed comparison pages for popular backup tools:
- Databasus vs pgBackWeb: /databasus-vs-pgbackweb
Each comparison explains the key differences, pros and cons and helps you choose the right tool for your needs.
### Why doesn't Databasus support PITR (Point-in-Time Recovery)?
Databasus intentionally focuses on logical backups rather than PITR for several practical reasons:
1. Complex setup requirements — PITR tools typically need to be installed on the same server as your database, requiring direct filesystem access and careful configuration
2. Restoration limitations — incremental backups cannot be restored without direct access to the database storage drive
3. Cloud incompatibility — managed cloud databases (AWS RDS, Google Cloud SQL, Azure) don't allow restoring external PITR backups, making them useless for cloud-hosted PostgreSQL
4. Built-in cloud PITR — cloud providers already offer native PITR capabilities, and even they typically default to hourly or daily granularity
5. Practical sufficiency — for 99% of projects, hourly or daily logical backups provide adequate recovery points without the operational complexity of WAL archiving
So instead of second-by-second restoration complexity, Databasus prioritizes an intuitive UX for individuals and teams, making it the most reliable tool for day to day use
### What backup types does Databasus support?
Databasus supports logical, physical, WAL archiving and Point-in-Time Recovery (PITR). In remote mode, Databasus connects to the database over the network and performs logical backups — no agent needed. This is ideal for cloud-managed databases and simple scheduled backups. In agent mode, a lightweight agent runs alongside the database and connects to the Databasus instance, enabling physical backups with continuous WAL archiving and PITR — designed for disaster recovery and near-zero data loss. Because the agent connects to Databasus, you can manage incremental backups for many databases from a single dashboard — unlike standalone tools like WAL-G or pgBackRest where each database is managed separately. Databasus suits both those who want simple remote backups and those who need a solid disaster recovery tool.
### Backup Schedules
Hourly, daily, weekly, monthly or cron cycles with exact run time specification (e.g., 04:00). Weekly schedules support specific weekdays, monthly schedules support specific calendar days.
@@ -278,5 +290,5 @@ You can join our large community of developers, DBAs and DevOps engineers at htt
## Keywords
PostgreSQL, MySQL, MariaDB, MongoDB, backup, monitoring, database, scheduled backups, Docker, self-hosted, open source, S3, Google Drive, Slack notifications, Discord, DevOps, database monitoring, pg_dump, database restore, Cloudflare R2, Microsoft Teams, health checks, compression, automation, encryption, AES-256-GCM, backup encryption, enterprise security, read-only database access, data protection, secure backups, sensitive data encryption, security audit, least privilege, Kubernetes, Helm, K8s, StatefulSet, ingress
PostgreSQL, MySQL, MariaDB, MongoDB, backup, monitoring, database, scheduled backups, Docker, self-hosted, open source, S3, Google Drive, Slack notifications, Discord, DevOps, database monitoring, pg_dump, database restore, Cloudflare R2, Microsoft Teams, health checks, compression, automation, encryption, AES-256-GCM, backup encryption, enterprise security, read-only database access, data protection, secure backups, sensitive data encryption, security audit, least privilege, Kubernetes, Helm, K8s, StatefulSet, ingress, WAL, WAL archiving, PITR, Point-in-Time Recovery, physical backup, incremental backup, logical backup, disaster recovery, agent mode, remote backup