Open rkrzr opened 5 years ago
By the way it would be nice to have a way to automatically select the most recent full backup when performing a PITR.
For example if you do a full backup every week and want to perform a full PITR to a specific time you still need to provide a backup id AND the timestamp. This is not very convenient if you want to automate a PITR.
For example I have a lot of backups:
pg1 20190602T041001 - Sun Jun 2 05:09:26 2019 - Size: 141.2 GiB - WAL Size: 14.5 GiB
pg1 20190526T041002 - Sun May 26 05:25:07 2019 - Size: 140.5 GiB - WAL Size: 15.4 GiB
pg1 20190519T041002 - Sun May 19 05:09:35 2019 - Size: 139.5 GiB - WAL Size: 21.6 GiB
pg1 20190512T041001 - Sun May 12 05:10:01 2019 - Size: 138.5 GiB - WAL Size: 19.7 GiB
pg1 20190505T041002 - Sun May 5 05:24:30 2019 - Size: 137.7 GiB - WAL Size: 14.4 GiB
pg1 20190428T041002 - Sun Apr 28 05:08:02 2019 - Size: 136.8 GiB - WAL Size: 12.0 GiB
pg1 20190421T041001 - Sun Apr 21 05:22:20 2019 - Size: 136.0 GiB - WAL Size: 11.8 GiB
pg1 20190414T041002 - Sun Apr 14 05:07:23 2019 - Size: 135.1 GiB - WAL Size: 13.5 GiB
pg1 20190407T041001 - Sun Apr 7 05:19:35 2019 - Size: 173.8 GiB - WAL Size: 50.8 GiB
pg1 20190331T041002 - Sun Mar 31 05:18:10 2019 - Size: 172.4 GiB - WAL Size: 11.8 GiB
pg1 20190324T041002 - Sun Mar 24 05:31:08 2019 - Size: 170.8 GiB - WAL Size: 11.5 GiB
If I want to perform a PITR at 2019-06-03 10:00:00
barman should automatically select backup id 20190602T041001
. If the PITR is at 2019-06-01 10:00:00
the backup id 20190526T041002
should be selected, and so on.
@renard that looks like something very useful. I think that the backup_id
should probably be an optional argument for barman recover
Feature request
I ran into a small UX issue, which new users might fall over.
The problem was that I tried to restore to a
--target-time
that was before theend_time
of the chosen backup (but after thebegin_time
). The restore ran successfully, but when I then tried to start up Postgres, it would error out withFATAL: requested recovery stop point is before consistent recovery point
The docs do actually mention that you have to use the previous backup, if you want to restore to time before the
end_time
, but I still overlooked it somehow.I think it would be a nice feature to warn users when the
--target-time
is before theend_time
of the chosen backup.This check could perhaps be added to the CLI handler function here or in the
server.recover()
function here.