diff --git a/CHANGELOG.md b/CHANGELOG.md index 64e03f867..b895aa25f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,6 +5,8 @@ __No Release Date Set__ * Enhanced text output of `info` command to include timestamps, sizes, and the reference list for all backups. _Contributed by Cynthia Shang_. +* Allow selective restore of databases from a cluster backup. This feature can result in major space and time savings when only specific databases are restored. Unrestored databases will not be accessible but must be manually dropped before they will be removed from the shared catalogue. + ## v1.00: New Repository Format and Configuration Scheme, Link Support __Released April 14, 2016__ diff --git a/doc/xml/backlog.xml b/doc/xml/backlog.xml index c52f9fa41..23665bf34 100644 --- a/doc/xml/backlog.xml +++ b/doc/xml/backlog.xml @@ -430,6 +430,12 @@
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.
+The Backup section introduces additional
Generally it is best to retain as many backups as possible to provide a greater window for Point-in-Time Recovery, but practical concerns such as disk space must also be considered. Retention options remove older backups once they are no longer needed.
@@ -714,7 +714,7 @@The Restore section introduces additional
There may be cases where it is desirable to selectively restore specific databases from a cluster backup. This could be done for performance reasons or to move selected databases to a machine that does not have enough space to restore the entire cluster backup.
+ +To demonstrate this feature two databases are created: test1 and test2. A fresh backup is run so
Each test database will be seeded with tables and data to demonstrate that recovery works with selective restore.
+ +One of the main reasons to use selective restore is to save space. The size of the test1 database is shown here so it can be compared with the disk utilization after a selective restore.
+ +Stop the cluster and restore only the test2 database. Built-in databases (
Once recovery is complete the test2 database will contain all previously created tables and data.
+ +The test1 database, despite successful recovery, is not accessible. This is because the entire database was restored as sparse, zeroed files.
Since the test1 database is restored with sparse, zeroed files it will only require as much space as the amount of WAL that is written during recovery. While the amount of WAL generated during a backup and applied during recovery can be significant it will generally be a small fraction of the total database size, especially for large databases where this feature is most likely to be useful.
+ +It is clear that the test1 database uses far less disk space during the selective restore than it would have if the entire database had been restored.
+ +At this point the only action that can be taken on the invalid test1 database is
Now that the invalid test1 database has been dropped only the test2 and built-in databases remain.
+ +