Github Issue

The text (default) info output should include everything (or nearly everything) that is in the JSON output nicely formatted for human consumption.

Github Issue

If crashes during a backup it may not be able to recover if the backup label is present. Copy and delete right after start_backup(). Stop backup will want to delete it so it might be necessary to copy it back or at least touch a file that can delete. Check after the backup is complete to make sure it's really gone.

Github Issue

Add a new command, archive-test, that will execute pg_switch_xlog and check that the xlog makes it to the archive.

Github Issue

Even with the thread refactor they are not reliable on all platforms. Processes would be more compatible across platforms and basic testing has shown there are no significant performance tradeoffs.

Github Issue

Create a setting that allows a time period to be set for retention. Right now only a certain number of backups can be set. If retention-full=2 and two backups are done back to back, then the time period of protection will be very short.

The new option retention-period will be expressed in hours, days, weeks, months, years and will work with current retention like this: The time period will be honored but middle backups will be pruned to match retention-full. For example, if retention-period=2 weeks full-rentention=2 and a third full backup was taken, the first one would be pruned if it were older than two weeks, else the middle one will be pruned. This gives two weeks of backup coverage but keeps the number of backups down.

As part of this feature, WAL should be expired as part of retention-period if nothing else is set. This will support installations that are using backrest only for archiving.

Github Issue

If is run without being fully-qualified locally it should also be done when running remotely. They might be in different paths but still on the search path. The remote-cmd option can still be used to set it explicitly.

This option would allow the user to restore the link but none of the data at the destination. This would be useful for linked configuration files which are good to backup but not appropriate to restore in every situation, e.g. a standby that has its own custom config. Another example would be a link to the log directory from within $PGDATA.

Github Issue

Formalize this process and allow upgrades to new database versions.

• Make sure that restore and expiration still work - perhaps new unit tests.
• Add db-id param to restore and archive-get to specify a database.

This should also make it easy to throw a stanza does not exist error.

Github Issue

Add running (true/false) to info based on the lock file.

Github Issue

Two improvements:

• Make sure recovery.conf has same ownership/mode as base path
• Make sure base path has original ownership/permissions.

Github Issue

Certain parameters like db-path and repo-path must be configured on both sides when the backup server is remote. It would be better if these parameters were pulled from the remote side so they aren't repeated.

Github Issue

It's possible to have bogus settings in the configuration file since it is only checked for certain values.

• Detect options that are placed in the wrong sections.
• Detect options that do not exist.

Suggested by Michael Renner Github Issue

Allow (or perhaps require) a repo-owner to allow to check permissions on the repository.

Github Issue

If time PITR is being done it should be possible to automatically pick the best backup to use.

Github Issue

Make async archiving work when pg_receivexlog is writing directly to the out spool directory on the backup server. Setting this up with a replication slot will make it more reliable.

BackRest will not directly call pg_receivexlog but it can work in concert for more reliable logging.

Github Issue

The archive_mode=always setting in 9.5 allows both the master and the standby to log to the same archive for redundancy. Currently will error if this mode is set because it is not supported.

Github Issue

Getting one archive file at a time can be tedious if the cluster is very far behind. An async get with some sort of prefetch would speed the process a lot.

Should be able to specify how may archive logs to prefetch.

Github Issue

Multi-processing would improved performance for these operations, especially archive-push. However, even very large systems have been working well with asynchronous archiving so this is not a big priority.

Github Issue

Checksums are calculated during the backup process, but the delta is still done during diff/incr backups. Add a new option checksum_delta (default n) that does the delta using checksums. Of course, if the timestamp or size has changed the checksum does not need to be calculated.

Suggested by Michael Renner Github Issue

This would prevent surprises for new users who expect to see more output and think the process has locked up if it is not logging.

Github Issue

If an archive log is missing in the middle of an archive stream will return a soft error (1), even though there is probably no chance of that archive log showing up.

If an archive log is missing then check to see if the next one is present - if so return a hard error. This is tricky because there is a question of how long to wait. With parallel async push it's very possible that the WALs could arrive out of order.

Here's a possible solution: on the database server knows the oldest WAL segment that is currently on the db server and not pushed. If this is reported to the backup server, then it can determine if a hole in the archive stream may be filled, or if it is a permanent condition.

Github Issue

The async archiver exits as soon as there are no files left to transfer. A configurable sleep would be good because it would reduce the number of SSH connections made to the remote.

Github Issue

Preserve exact WAL timestamps to make measurement of WAL rates more accurate in monitoring. Timestamp should be taken from the file before copying so delay in archiving can also be measured.

Github Issue

Allow user to indicate that a backup is locked and should be preserved until unlocked. This could be handy for the last backup of a previous PG version or just to save data that is known to be important for any reason.

Github Issue

This would allow to detect when paths inside the repo have been renamed.

Suggested by Michael Renner Github Issue

This would allow easier configuration for CM software.

Github Issue

Add a throttling feature to limit the amount of disk i/o and or network bandwidth being used by the backup.

Make this a per thread limitation to start. That simplifies the problem quite a bit and most users who are throttling will probably be single threaded.

Github Issue

Allow user-defined hook scripts to be run before and after backups.

Github Issue

It is possible to notify users earlier if archiving is not working during a backup. Check in the main backup loop to see if archiving is proceeding - if not then fail after a configurable amount of time.

Github Issue

Add new options db-sudo-user and backup-sudo-user to allow the backrest command to be run through sudo for security. This is especially important on the db side.

Github Issue

Although the file system backup needs to run as , it can be advantageous to have the start/stop backup run as a less privileged database user with the REPLICATION role. This will need to be tested to see if it works.

Ideally the file system backup could be run as a user in the group rather than itself but does not grant group permissions so sadly it is not possible to backup as a user other than the database owner at the file-system level. This limitation will need to be addressed in core .

Github Issue

There are some use cases where would be valuable to use relative paths. However to avoid confusion it might be best to implement it like so:

• relative paths would need to being with ./
• --config would always be allowed to be relative
• In the config file a new option 'relative-path' would enable relative paths for all other path options.

Github Issue

>= 9.3 has the option to enable checksums on data files. should be able to test these checksums and report if it finds any issues. This could also be a stand-alone function.

For extra credit, test the checksums in WAL.

Github Issue

Add the ability to log into a database - especially a centralized database. Include all backup metadata plus the logs.

This would make for easy querying and monitoring.

Github Issue

Backup encryption is a good thing ans might be required before users would be comfortable pushing to services such as S3.

Github Issue

Consider alternative storage methods like S3. Ideally there would be an option to store a certain number of backups (at least the last one) locally for fast restores, while using S3 for long-term storage.

Github Issue

This may require some exceptions in the code, but they should be done on a case by case basis rather than excluding the entire policy.

Github Issue

This makes the remote command line static so it works better in secured environments that use ForceCommand or sudo (or both).

Github Issue

Some ssh options like ForceCommand can modify the command line passed to the remote. Also pass the command line in the protocol layer to ensure no destructive changes were made.

Github Issue

If a file is recopied in incr/diff because of timestamp changes, there may still be cases where the file was actually not modified. Since we are doing checksums anyway, it's possible to check it against the previous file and create a reference when the checksums match.

Github Issue

File objects are created in a bunch of places but it's all basically the same code. Move this to a common function that looks like protocolGet().

Github Issue

This is to make sure those types of restores are consistent.

Github Issue

Low-level regression tests to be sure locking works as expected locally and remotely. This should include tests on NFS since this is a popular scenario.

Github Issue

Low-level regression tests to be sure locking works as expected locally and remotely. This should include tests on NFS since this is a popular scenario.

Github Issue

Currently is is possible to have multiple test points but they must all have the same delay time. Make it so each test point can have its own delay.

A perfect test case would be adding keep alive testing to restore. The RESTORE_START test should have delay 1 while the KEEP_ALIVE test should have delay 0.

Github Issue

The debug params all end up on a single line so if one value changes it's tough to tell which one changed. Separate them out onto separate lines to aid debugging (even though this will add a lot of lines to the file.)

Some options can be passed multiple times on the command line (or the config file) and this should be written into the reference guide automatically rather than being manually written per option.

Github Issue

Backrest can be secured by using the backrest use on the database server and configuring sudo and ssh.

This method should be included in the documentation.

Suggested by Michael Renner Github Issue

Discuss how is different from other backup solutions using this consul comparison as a model.