April 17, 2016: Crunchy Data is proud to announce pgBackRest 1.0, Reliable 
PostgreSQL Backup & Restore.

The first stable of release of pgBackRest introduces a new, more capable 
repository format, simpler configuration, and comprehensive support for backup 
and restore of symlinked directories and files.

There are a number of important changes in pgBackRest 1.0 so be sure to read 
the release notes very carefully before upgrading.

Links
-----

* Website: http://www.pgbackrest.org/
* Download: https://github.com/pgbackrest/pgbackrest/releases
* Release Notes: 
https://github.com/pgbackrest/pgbackrest/blob/master/CHANGELOG.md
* Documentation: http://www.pgbackrest.org/
* User Guide: http://www.pgbackrest.org/user-guide.html
* Support: http://www.pgbackrest.org/#support

Features
--------

* Multithreaded Backup & Restore

Compression is usually the bottleneck during backup operations but, even with 
now ubiquitous multi-core servers, most database backup solutions are still 
single-threaded. pgBackRest solves the compression bottleneck with 
multithreading.

Utilizing multiple cores for compression makes it possible to achieve 1TB/hr 
raw throughput even on a 1Gb/s link. More cores and a larger pipe lead to even 
higher throughput.

* Local or Remote Operation

A custom protocol allows pgBackRest to backup, restore, and archive locally or 
remotely via SSH with minimal configuration. An interface to query PostgreSQL 
is also provided via the protocol layer so that remote access to PostgreSQL is 
never required, which enhances security.

* Full, Incremental, & Differential Backups

Full, differential, and incremental backups are supported. pgBackRest is not 
susceptible to the time resolution issues of rsync, making differential and 
incremental backups completely safe.

* Backup Rotation & Archive Expiration

Retention polices can be set for full and differential backups to create 
coverage for any timeframe. WAL archive can be maintained for all backups or 
strictly for the most recent backups. In the latter case WAL required to make 
older backups consistent will be maintained in the archive.

* Backup Integrity

Checksums are calculated for every file in the backup and rechecked during a 
restore. After a backup finishes copying files, it waits until every WAL 
segment required to make the backup consistent reaches the repository.

Backups in the repository are stored in the same format as a standard 
PostgreSQL cluster (including tablespaces). If compression is disabled and hard 
links are enabled it is possible to snapshot a backup in the repository and 
bring up a PostgreSQL cluster directly on the snapshot. This is advantageous 
for terabyte-scale databases that are time consuming to restore in the 
traditional way.

All operations utilize file and directory level fsync to ensure durability.

* Backup Resume

An aborted backup can be resumed from the point where it was stopped. Files 
that were already copied are compared with the checksums in the manifest to 
ensure integrity. Since this operation can take place entirely on the backup 
server, it reduces load on the database server and saves time since checksum 
calculation is faster than compressing and retransmitting data.

* Streaming Compression & Checksums

Compression and checksum calculations are performed in stream while files are 
being copied to the repository, whether the repository is located locally or 
remotely.

If the repository is on a backup server, compression is performed on the 
database server and files are transmitted in a compressed format and simply 
stored on the backup server. When compression is disabled a lower level of 
compression is utilized to make efficient use of available bandwidth while 
keeping CPU cost to a minimum.

* Delta Restore

The manifest contains checksums for every file in the backup so that during a 
restore it is possible to use these checksums to speed processing enormously. 
On a delta restore any files not present in the backup are first removed and 
then checksums are taken for the remaining files. Files that match the backup 
are left in place and the rest of the files are restored as usual. Since this 
process is multithreaded, it can lead to a dramatic reduction in restore times.

* Advanced Archiving

Dedicated commands are included for both pushing WAL to the archive and 
retrieving WAL from the archive.

The push command automatically detects WAL segments that are pushed multiple 
times and de-duplicates when the segment is identical, otherwise an error is 
raised. The push and get commands both ensure that the database and repository 
match by comparing PostgreSQL versions and system identifiers. This precludes 
the possibility of misconfiguring the WAL archive location.

Asynchronous archiving allows compression and transfer to be offloaded to 
another process which maintains a continuous connection to the remote server, 
improving throughput significantly. This can be a critical feature for 
databases with extremely high write volume.

* Tablespace & Link Support

Tablespaces are fully supported and on restore tablespaces can be remapped to 
any location. It is also possible to remap all tablespaces to one location with 
a single command which is useful for development restores.

File and directory links are supported for any file or directory in the 
PostgreSQL cluster. When restoring it is possible to restore all links to their 
original locations, remap some or all links, or restore some or all links as 
normal files or directories within the cluster directory.

* Compatibility with PostgreSQL >= 8.3

pgBackRest includes support for versions down to 8.3, since older versions of 
PostgreSQL are still regularly utilized.

About
-----

pgBackRest aims to be a simple, reliable backup and restore system that can 
seamlessly scale up to the largest databases and workloads. Instead of relying 
on traditional backup tools like tar and rsync, pgBackRest implements all 
backup features internally and uses a custom protocol for communicating with 
remote systems. Removing reliance on tar and rsync allows for better solutions 
to database-specific backup challenges. The custom remote protocol allows for 
more flexibility and limits the types of connections that are required to 
perform a backup which increases security.

Crunchy Data supports the ongoing and active development of pgBackRest as an 
entirely open source project, released under the BSD-compatible MIT license.

--
David Steele
Senior Architect
Crunchy Data, Inc.

-- 
Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-announce

Reply via email to