-
Notifications
You must be signed in to change notification settings - Fork 191
/
NEWS
1729 lines (1239 loc) · 67.8 KB
/
NEWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Barman News - History of user-visible changes
Version 3.11.1 - 22 August 2024
- Bug fixes:
- Fix failures in `barman-cloud-backup-delete`. This command was failing when
applying retention policies due to a bug introduced by the previous release.
Version 3.11.0 - 22 August 2024
- Add support for Postgres 17+ incremental backups. This major feature is
composed of several small changes:
- Add `--incremental` command-line option to `barman backup` command. This is
used to specify the parent backup when taking an incremental backup. The
parent can be either a full backup or another incremental backup.
- Add `latest-full` shortcut backup ID. Along with `latest`, this can be used
as a shortcut to select the parent backup for an incremental backup. While
`latest` takes the latest backup independently if it is full or incremental,
`latest-full` takes the latest full backup.
- `barman keep` command can only be applied to full backups when
`backup_method = postgres`. If a full backup has incremental backups that
depend on it, all of the incrementals are also kept by Barman.
- When deleting a backup all the incremental backups depending on it, if any,
are also removed.
- Retention policies do not take incremental backups into consideration. As
incremental backups cannot be recovered without having the complete chain of
backups available up to the full backup, only full backups account for
retention policies.
- `barman recover` needs to combine the full backup with the chain of incremental
backups when recovering. The new CLI option `--local-staging-path`, and the
corresponding `local_staging_path` configuration option, are used to specify
the path in the Barman host where the backups will be combined when recovering
an incremental backup.
- Changes to `barman show-backup` output:
- Add the “Estimated cluster size” field. It's useful to have an estimation
of the data directory size of a cluster when restoring a backup. It’s
particularly useful when recovering compressed backups or incremental
backups, situations where the size of the backup doesn’t reflect the size of the
data directory in Postgres. In JSON format, this is stored as
`cluster_size`.
- Add the “WAL summarizer” field. This field shows if `summarize_wal` was
enabled in Postgres at the time the backup was taken. In JSON format, this
is stored as `server_information.summarize_wal`. This field is omitted for
Postgres 16 and older.
- Add “Data checksums” field. This shows if `data_checkums` was enabled in
Postgres at the time the backup was taken. In JSON format, this is stored as
`server_information.data_checksums`.
- Add the “Backup method” field. This shows the backup method used for this
backup. In JSON format, this is stored as
`base_backup_information.backup_method`.
- Rename the field “Disk Usage” as “Backup Size”. The latter provides a more
comprehensive name which represents the size of the backup in the Barman
host. The JSON field under `base_backup_information` was also renamed from
`disk_usage` to `backup_size`.
- Add the “WAL size” field. This shows the size of the WALs required by the
backup. In JSON format, this is stored as
`base_backup_information.wal_size`.
- Refactor the field “Incremental size”. It is now named “Resources saving”
and it now shows an estimation of resources saved when taking incremental
backups with `rsync` or `pg_basebackup`. It compares the backup size with
the estimated cluster size to estimate the amount of disk and network
resources that were saved by taking an incremental backup. In JSON format,
the field was renamed from `incremental_size` to `resource_savings` under `base_backup_information`.
- Add the `system_id` field to the JSON document. This field contains the
system identifier of Postgres. It was present in console format, but was
missing in JSON format.
- Add fields related with Postgres incremental backups:
- “Backup type”: indicates if the Postgres backup is full or incremental. In
JSON format, this is stored as `backup_type` under `base_backup_information`.
- “Root backup”: the ID of the full backup that is the root of a chain of
one or more incremental backups. In JSON format, this is stored as
`catalog_information.root_backup_id`.
- “Parent backup”: the ID of the full or incremental backup from which this
incremental backup was taken. In JSON format, this is stored as
`catalog_information.parent_backup_id`.
- “Children Backup(s)”: the IDs of the incremental backups that were taken
with this backup as the parent. In JSON format, this is stored as
`catalog_information.children_backup_ids`.
- “Backup chain size”: the number of backups in the chain from this
incremental backup up to the root backup. In JSON format, this is
stored as `catalog_information.chain_size`.
- Changes to `barman list-backup` output:
- It now includes the backup type in the JSON output, which can be either
`rsync` for backups taken with rsync, `full` or `incremental` for backups
taken with `pg_basebackup`, or `snapshot` for cloud snapshots. When printing
to the console the backup type is represented by the corresponding labels
`R`, `F`, `I` or `S`.
- Remove tablespaces information from the output. That was bloating the
output. Tablespaces information can still be found in the output of
`barman show-backup`.
- Always set a timestamp with a time zone when configuring
`recovery_target_time` through `barman recover`. Previously, if no time zone
was explicitly set through `--target-time`, Barman would configure
`recovery_target_time` without a time zone in Postgres. Without a time zone,
Postgres would assume whatever is configured through `timezone` GUC in
Postgres. From now on Barman will issue a warning and configure
`recovery_target_time` with the time zone of the Barman host if no time zone
is set by the user through `--target-time` option.
- When recovering a backup with the “no get wal” approach and `--target-lsn` is set,
copy only the WAL files required to reach the configured target. Previously
Barman would copy all the WAL files from its archive to Postgres.
- When recovering a backup with the “no get wal” approach and `--target-immediate`
is set, copy only the WAL files required to reach the consistent point.
Previously Barman would copy all the WAL files from its archive to Postgres.
- `barman-wal-restore` now moves WALs from the spool directory to `pg_wal`
instead of copying them. This can improve performance if the spool directory
and the `pg_wal` directory are in the same partition.
- `barman check-backup` now shows the reason why a backup was marked as `FAILED`
in the output and logs. Previously for a user to know why the backup was
marked as `FAILED`, they would need to run `barman show-backup` command.
- Add configuration option `aws_await_snapshots_timeout` and the corresponding
`--aws-await-snapshots-timeout` command-line option on `barman-cloud-backup`.
This specifies the timeout in seconds to wait for snapshot backups to reach
the completed state.
- Add a keep-alive mechanism to rsync-based backups. Previously the Postgres
session created by Barman to run `pg_backup_start()` and `pg_backup_stop()` would
stay idle for as long as the base backup copy would take. That could lead to a
firewall or router dropping the connection because it was idle for a long
time. The keep-alive mechanism sends heartbeat queries to Postgres
through that connection, thus reducing the likelihood of a connection
getting dropped. The interval between heartbeats can be controlled through the new
configuration option `keepalive_interval` and the corresponding CLI
option `--keepalive-interval` of the `barman backup` command.
- Bug fixes:
- When recovering a backup with the “no get wal” approach and `--target-time`
set, copy all WAL files. Previously Barman would attempt to “guess” the WAL
files required by Postgres to reach the configured target time. However,
the mechanism was not robust enough as it was based on the stats of the WAL
file in the Barman host (more specifically the creation time). For example:
if there were archiving or streaming lag between Postgres and Barman, that
could be enough for recovery to fail because Barman would miss to copy all
the required WAL files due to the weak check based on file stats.
- Pin `python-snappy` to `0.6.1` when running Barman through Python 3.6 or
older. Newer versions of `python-snappy` require `cramjam` version `2.7.0` or
newer, and these are only available for Python 3.7 or newer.
- `barman receive-wal` now exits with code `1` instead of `0` in the following
cases:
- Being unable to run with `--reset` flag because `pg_receivewal` is
running.
- Being unable to start `pg_receivewal` process because it is already
running.
- Fix and improve information about Python in `barman diagnose` output:
- The command now makes sure to use the same Python interpreter under which
Barman is installed when outputting the Python version through
`python_ver` JSON key. Previously, if an environment had multiple Python
installations and/or virtual environments, the output could eventually be
misleading, as it could be fetched from a different Python interpreter.
- Added a `python_executable` key to the JSON output. That contains the path
to the exact Python interpreter being used by Barman.
Version 3.10.1 - 12 June 2024
- Bug fixes:
- Make `argcomplete` optional to avoid installation issues on some
platforms.
- Load `barman.auto.conf` only when the file exists.
- Emit a warning when the `cfg_changes.queue` file is malformed.
- Correct in documentation the postgresql version where
`pg_checkpoint` is available.
- Add `--no-partial` option to `barman-cloud-wal-restore`.
Version 3.10.0 - 24 January 2024
- Limit the average bandwidth used by `barman-cloud-backup` when backing
up to either AWS S3 or Azure Blob Storage according to the value set by
a new CLI option `--max-bandwidth`.
- Add the new configuration option `lock_directory_cleanup`
That enables cron to automatically clean up the barman_lock_directory
from unused lock files.
- Add support for a new type of configuration called `model`.
The model acts as a set of overrides for configuration options
for a given Barman server.
- Add a new barman command `barman config-update` that allows the creation
and the update of configurations using JSON
- Bug fixes:
- Fix a bug that caused `--min-chunk-size` to be ignored when using
barman-cloud-backup as hook script in Barman.
Version 3.9.0 - 3 October 2023
- Allow `barman switch-wal --force` to be run against PG>=14 if the
user has the `pg_checkpoint` role (thanks to toydarian for this patch).
- Log the current check at `info` level when a check timeout occurs.
- The minimum size of an upload chunk when using `barman-cloud-backup`
with either S3 or Azure Blob Storage can now be specified using the
`--min-chunk-size` option.
- `backup_compression = none` is supported when using `pg_basebackup`.
- For PostgreSQL 15 and later: the allowed `backup_compression_level`
values for `zstd` and `lz4` have been updated to match those allowed by
`pg_basebackup`.
- For PostgreSQL versions earlier than 15: `backup_compression_level = 0`
can now be used with `backup_compression = gzip`.
- Bug fixes:
- Fix `barman recover` on platforms where Multiprocessing uses spawn by
default when starting new processes.
Version 3.8.0 - 31 August 2023
- Clarify package installation. barman is packaged with default python version
for each operating system.
- The `minimum-redundancy` option is added to `barman-cloud-backup-delete`.
It allows to set the minimum number of backups that should always be available.
- Add a new `primary_checkpoint_timeout` configuration option. Allows define
the amount of seconds that Barman will wait at the end of a backup if no
new WAL files are produced, before forcing a checkpoint on the primary server.
- Bug fixes:
- Fix race condition in barman retention policies application. Backup
deletions will now raise a warning if another deletion is in progress
for the requested backup.
- Fix `barman-cloud-backup-show` man page installation.
Version 3.7.0 - 25 July 2023
- Support is added for snapshot backups on AWS using EBS volumes.
- The `--profile` option in the `barman-cloud-*` scripts is renamed
`--aws-profile`. The old name is deprecated and will be removed in
a future release.
- Backup manifests can now be generated automatically on completion
of a backup made with `backup_method = rsync`. This is enabled by
setting the `autogenerate_manifest` configuration variable and can
be overridden using the `--manifest` and `--no-manifest` CLI options.
- Bug fixes:
- The `barman-cloud-*` scripts now correctly use continuation
tokens to page through objects in AWS S3-compatible object
stores. This fixes a bug where `barman-cloud-backup-delete`
would only delete the oldest 1000 eligible WALs after backup
deletion.
- Minor documentation fixes.
Version 3.6.0 - 15 June 2023
- PostgreSQL version 10 is no longer supported.
- Support is added for snapshot backups on Microsoft Azure using
Managed Disks.
- The `--snapshot-recovery-zone` option is renamed `--gcp-zone` for
consistency with other provider-specific options. The old name
is deprecated and will be removed in a future release.
- The `snapshot_zone` option and `--snapshot-zone` argument are
renamed `gcp_zone` and `--gcp-zone` respectively. The old names
are deprecated and will be removed in a future release.
- The `snapshot_gcp_project` option and `--snapshot-gcp-project`
argument are renamed to `gcp_project` and `--gcp-project`. The
old names are deprecated and will be removed in a future release.
- Bug fixes:
- Barman will no longer attempt to execute the `replication-status`
command for a passive node.
- The `backup_label` is deleted from cloud storage when a
snapshot backup is deleted with `barman-cloud-backup-delete`.
- Man pages for the `generate-manifest` and `verify-backup`
commands are added.
- Minor documentation fixes.
Version 3.5.0 - 29 March 2023
- Python 2.7 is no longer supported. The earliest Python version
supported is now 3.6.
- The `barman`, `barman-cli` and `barman-cli-cloud` packages for
EL7 now require python 3.6 instead of python 2.7. For other
supported platforms, Barman packages already require python
versions 3.6 or later so packaging is unaffected.
- Support for PostgreSQL 10 will be discontinued in future Barman
releases; 3.5.x is the last version of Barman with support for
PostgreSQL 10.
- Backups and WALs uploaded to Google Cloud Storage can now be
encrypted using a specific KMS key by using the `--kms-key-name`
option with `barman-cloud-backup` or `barman-cloud-wal-archive`.
- Backups and WALs uploaded to AWS S3 can now be encrypted using a
specific KMS key by using the `--sse-kms-key-id` option with
`barman-cloud-backup` or `barman-cloud-wal-archive` along with
`--encryption=aws:kms`.
- Two new configuration options are provided which make it possible
to limit the rate at which parallel workers are started during
backups with `backup_method = rsync` and recoveries.
`parallel_jobs_start_batch_size` can be set to limit the amount of
parallel workers which will be started in a single batch, and
`parallel_jobs_start_batch_period` can be set to define the time
in seconds over which a single batch of workers will be started.
These can be overridden using the arguments `--jobs-start-batch-size`
and `--jobs-start-batch-period` with the `barman backup` and
`barman recover` commands.
- A new option `--recovery-conf-filename` is added to `barman recover`.
This can be used to change the file to which Barman should write the
PostgreSQL recovery options from the default `postgresql.auto.conf`
to an alternative location.
- Bug fixes:
- Fix a bug which prevented `barman-cloud-backup-show` from
displaying the backup metadata for backups made with
`barman backup` and uploaded by `barman-cloud-backup` as a
post-backup hook script.
- Fix a bug where the PostgreSQL connection used to validate backup
compression settings was left open until termination of the
Barman command.
- Fix an issue which caused rsync-concurrent backups to fail when
running for a duration greater than `idle_session_timeout`.
- Fix a bug where the backup name was not saved in the backup
metadata if the `--wait` flag was used with `barman backup`.
- Thanks to mojtabash78, mhkarimi1383, epolkerman, barthisrael and
hzetters for their contributions.
Version 3.4.0 - 26 January 2023
- This is the last release of Barman which will support Python 2 and
new features will henceforth require Python 3.6 or later.
- A new `backup_method` named `snapshot` is added. This will create
backups by taking snapshots of cloud storage volumes. Currently
only Google Cloud Platform is supported however support for AWS
and Azure will follow in future Barman releases. Note that this
feature requires a minimum Python version of 3.7. Please see the
Barman manual for more information.
- Support for snapshot backups is also added to `barman-cloud-backup`,
with minimal support for restoring a snapshot backup added to
`barman-cloud-restore`.
- A new command `barman-cloud-backup-show` is added which displays
backup metadata stored in cloud object storage and is analogous to
`barman show-backup`. This is provided so that snapshot metadata
can be easily retrieved at restore time however it is also a
convenient way of inspecting metadata for any backup made with
`barman-cloud-backup`.
- The instructions for installing Barman from RPMs in the docs are
updated.
- The formatting of NFS requirements in the docs is fixed.
- Supported PostgreSQL versions are updated in the docs (this is a
documentation fix only - the minimum supported major version is
still 10).
Version 3.3.0 - 14 December 2022
- A backup can now be given a name at backup time using the new
`--name` option supported by the `barman backup` and
`barman-cloud-backup` commands. The backup name can then be used
in place of the backup ID when running commands to interact with
backups. Additionally, the commands to list and show backups have
been been updated to include the backup name in the plain text and
JSON output formats.
- Stricter checking of PostgreSQL version to verify that Barman is
running against a supported version of PostgreSQL.
- Bug fixes:
- Fix inconsistencies between the barman cloud command docs and
the help output for those commands.
- Use a new PostgreSQL connection when switching WALs on the
primary during the backup of a standby to avoid undefined
behaviour such as `SSL error` messages and failed connections.
- Reduce log volume by changing the default log level of stdout
for commands executed in child processes to `DEBUG` (with the
exception of `pg_basebackup` which is deliberately logged at
`INFO` level due to it being a long-running process where it is
frequently useful to see the output during the execution of the
command).
Version 3.2.0 - 20 October 2022
- `barman-cloud-backup-delete` now accepts a `--batch-size` option
which determines the maximum number of objects deleted in a single
request.
- All `barman-cloud-*` commands now accept a `--read-timeout` option
which, when used with the `aws-s3` cloud provider, determines the
read timeout used by the boto3 library when making requests to S3.
- Bug fixes:
- Fix the failure of `barman recover` in cases where
`backup_compression` is set in the Barman configuration but the
PostgreSQL server is unavailable.
Version 3.1.0 - 14 September 2022
- Backups taken with `backup_method = postgres` can now be compressed
using lz4 and zstd compression by setting `backup_compression = lz4`
or `backup_compression = zstd` respectively. These options are only
supported with PostgreSQL 15 (beta) or later.
- A new option `backup_compression_workers` is available which sets
the number of threads used for parallel compression. This is
currently only available with `backup_method = postgres` and
`backup_compression = zstd`.
- A new option `primary_conninfo` can be set to avoid the need for
backups of standbys to wait for a WAL switch to occur on the primary
when finalizing the backup. Barman will use the connection string
in `primary_conninfo` to perform WAL switches on the primary when
stopping the backup.
- Support for certain Rsync versions patched for CVE-2022-29154 which
require a trailing newline in the `--files-from` argument.
- Allow `barman receive-wal` maintenance options (`--stop`, `--reset`,
`--drop-slot` and `--create-slot`) to run against inactive servers.
- Add `--port` option to `barman-wal-archive` and `barman-wal-restore`
commands so that a custom SSH port can be used without requiring any
SSH configuration.
- Various documentation improvements.
- Python 3.5 is no longer supported.
- Bug fixes:
- Ensure PostgreSQL connections are closed cleanly during the
execution of `barman cron`.
- `barman generate-manifest` now treats pre-existing
backup_manifest files as an error condition.
- backup_manifest files are renamed by appending the backup ID
during recovery operations to prevent future backups including
an old backup_manifest file.
- Fix epoch timestamps in json output which were not
timezone-aware.
- The output of `pg_basebackup` is now written to the Barman
log file while the backup is in progress.
- We thank barthisrael, elhananjair, kraynopp, lucianobotti, and mxey
for their contributions to this release.
Version 3.0.1 - 27 June 2022
- Bug fixes:
- Fix package signing issue in PyPI (same sources as 3.0.0)
Version 3.0.0 - 23 June 2022
- BREAKING CHANGE: PostgreSQL versions 9.6 and earlier are no longer
supported. If you are using one of these versions you will need to
use an earlier version of Barman.
- BREAKING CHANGE: The default backup mode for Rsync backups is now
concurrent rather than exclusive. Exclusive backups have been
deprecated since PostgreSQL 9.6 and have been removed in PostgreSQL
15. If you are running Barman against PostgreSQL versions earlier
than 15 and want to use exclusive backups you will now need to set
`exclusive_backup` in `backup_options`.
- BREAKING CHANGE: The backup metadata stored in the `backup.info` file
for each backup has an extra field. This means that earlier versions
of Barman will not work in the presence of any backups taken with
3.0.0. Additionally, users of pg-backup-api will need to upgrade it
to version 0.2.0 so that pg-backup-api can work with the updated
metadata.
- Backups taken with `backup_method = postgres` can now be compressed
by pg_basebackup by setting the `backup_compression` config option.
Additional options are provided to control the compression level,
the backup format and whether the pg_basebackup client or the
PostgreSQL server applies the compression. NOTE: Recovery of these
backups requires Barman to stage the compressed files on the recovery
server in a location specified by the `recovery_staging_path` option.
- Add support for PostgreSQL 15. Exclusive backups are not supported
by PostgreSQL 15 therefore Barman configurations for PostgreSQL 15
servers are not allowed to specify `exclusive_backup` in
`backup_options`.
- Various documentation improvements.
- Use custom_compression_magic, if set, when identifying compressed
WAL files. This allows Barman to correctly identify uncompressed
WALs (such as `*.partial` files in the `streaming` directory) and
return them instead of attempting to decompress them.
- Bug fixes:
- Fix an ordering bug which caused Barman to log the message
"Backup failed issuing start backup command." while handling a
failure in the stop backup command.
- Fix a bug which prevented recovery using `--target-tli` when
timelines greater than 9 were present, due to hexadecimal values
from WAL segment names being parsed as base 10 integers.
- Fix an import error which occurs when using barman cloud with
certain python2 installations due to issues with the enum34
dependency.
- Fix a bug where Barman would not read more than three bytes from
a compressed WAL when attempting to identify the magic bytes. This
means that any custom compressed WALs using magic longer than three
bytes are now decompressed correctly.
- Fix a bug which caused the `--immediate-checkpoint` flag to be
ignored during backups with `backup_method = rsync`.
Version 2.19 - 9 March 2022
- Change `barman diagnose` output date format to ISO8601.
- Add Google Cloud Storage (GCS) support to barman cloud.
- Support `current` and `latest` recovery targets for the `--target-tli`
option of `barman recover`.
- Add documentation for installation on SLES.
- Bug fixes:
- `barman-wal-archive --test` now returns a non-zero exit code when
an error occurs.
- Fix `barman-cloud-check-wal-archive` behaviour when `-t` option is
used so that it exits after connectivity test.
- `barman recover` now continues when `--no-get-wal` is used and
`"get-wal"` is not set in `recovery_options`.
- Fix `barman show-servers --format=json ${server}` output for
inactive server.
- Check for presence of `barman_home` in configuration file.
- Passive barman servers will no longer store two copies of the
tablespace data when syncing backups taken with
`backup_method = postgres`.
- We thank richyen for his contributions to this release.
Version 2.18 - 21 January 2022
- Add snappy compression algorithm support in barman cloud (requires the
optional python-snappy dependency).
- Allow Azure client concurrency parameters to be set when uploading
WALs with barman-cloud-wal-archive.
- Add `--tags` option in barman cloud so that backup files and archived
WALs can be tagged in cloud storage (aws and azure).
- Update the barman cloud exit status codes so that there is a dedicated
code (2) for connectivity errors.
- Add the commands `barman verify-backup` and `barman generate-manifest`
to check if a backup is valid.
- Add support for Azure Managed Identity auth in barman cloud which can
be enabled with the `--credential` option.
- Bug fixes:
- Change `barman-cloud-check-wal-archive` behavior when bucket does
not exist.
- Ensure `list-files` output is always sorted regardless of the
underlying filesystem.
- Man pages for barman-cloud-backup-keep, barman-cloud-backup-delete
and barman-cloud-check-wal-archive added to Python packaging.
- We thank richyen and stratakis for their contributions to this
release.
Version 2.17 - 1 December 2021
- Bug fixes:
- Resolves a performance regression introduced in version 2.14 which
increased copy times for `barman backup` or `barman recover` commands
when using the `--jobs` flag.
- Ignore rsync partial transfer errors for `sender` processes so that
such errors do not cause the backup to fail (thanks to barthisrael).
Version 2.16 - 17 November 2021
- Add the commands `barman-check-wal-archive` and `barman-cloud-check-wal-archive`
to validate if a proposed archive location is safe to use for a new PostgreSQL
server.
- Allow Barman to identify WAL that's already compressed using a custom
compression scheme to avoid compressing it again.
- Add `last_backup_minimum_size` and `last_wal_maximum_age` options to
`barman check`.
- Bug fixes:
- Use argparse for command line parsing instead of the unmaintained
argh module.
- Make timezones consistent for `begin_time` and `end_time`.
- We thank chtitux, George Hansper, stratakis, Thoro, and vrms for their
contributions to this release.
Version 2.15 - 12 October 2021
- Add plural forms for the `list-backup`, `list-server` and
`show-server` commands which are now `list-backups`, `list-servers`
and `show-servers`. The singular forms are retained for backward
compatibility.
- Add the `last-failed` backup shortcut which references the newest
failed backup in the catalog so that you can do:
- `barman delete <SERVER> last-failed`
- Bug fixes:
- Tablespaces will no longer be omitted from backups of EPAS
versions 9.6 and 10 due to an issue detecting the correct version
string on older versions of EPAS.
Version 2.14 - 22 September 2021
- Add the `barman-cloud-backup-delete` command which allows backups in
cloud storage to be deleted by specifying either a backup ID or a
retention policy.
- Allow backups to be retained beyond any retention policies in force by
introducing the ability to tag existing backups as archival backups
using `barman keep` and `barman-cloud-backup-keep`.
- Allow the use of SAS authentication tokens created at the restricted
blob container level (instead of the wider storage account level) for
Azure blob storage
- Significantly speed up `barman restore` into an empty directory for
backups that contain hundreds of thousands of files.
- Bug fixes:
- The backup privileges check will no longer fail if the user lacks
"userepl" permissions and will return better error messages if any
required permissions are missing (#318 and #319).
Version 2.13 - 26 July 2021
- Add Azure blob storage support to barman-cloud
- Support tablespace remapping in barman-cloud-restore via
`--tablespace name:location`
- Allow barman-cloud-backup and barman-cloud-wal-archive to run as
Barman hook scripts, to allow data to be relayed to cloud storage
from the Barman server
- Bug fixes:
- Stop backups failing due to idle_in_transaction_session_timeout
(https://github.com/EnterpriseDB/barman/issues/333)
- Fix a race condition between backup and archive-wal in updating
xlog.db entries (#328)
- Handle PGDATA being a symlink in barman-cloud-backup, which led to
"seeking backwards is not allowed" errors on restore (#351)
- Recreate pg_wal on restore if the original was a symlink (#327)
- Recreate pg_tblspc symlinks for tablespaces on restore (#343)
- Make barman-cloud-backup-list skip backups it cannot read, e.g.,
because they are in Glacier storage (#332)
- Add `-d database` option to barman-cloud-backup to specify which
database to connect to initially (#307)
- Fix "Backup failed uploading data" errors from barman-cloud-backup
on Python 3.8 and above, caused by attempting to pickle the boto3
client (#361)
- Correctly enable server-side encryption in S3 for buckets that do
not have encryption enabled by default.
In Barman 2.12, barman-cloud-backup's `--encryption` option did
not correctly enable encryption for the contents of the backup if
the backup was stored in an S3 bucket that did not have encryption
enabled. If this is the case for you, please consider deleting
your old backups and taking new backups with Barman 2.13.
If your S3 buckets already have encryption enabled by default
(which we recommend), this does not affect you.
Version 2.12.1 - 30 June 2021
- Bug fixes:
- Allow specifying target-tli with other target-* recovery options
- Fix incorrect NAME in barman-cloud-backup-list manpage
- Don't raise an error if SIGALRM is ignored
- Fetch wal_keep_size, not wal_keep_segments, from Postgres 13
Version 2.12 - 5 Nov 2020
- Introduce a new backup_method option called local-rsync which
targets those cases where Barman is installed on the same server
where PostgreSQL is and directly uses rsync to take base backups,
bypassing the SSH layer.
- Bug fixes:
- Avoid corrupting boto connection in worker processes
- Avoid connection attempts to PostgreSQL during tests
Version 2.11 - 9 Jul 2020
- Introduction of the barman-cli-cloud package that contains all cloud
related utilities.
- Add barman-cloud-wal-restore to restore a WAL file previously
archived with barman-cloud-wal-archive from an object store
- Add barman-cloud-restore to restore a backup previously taken with
barman-cloud-backup from an object store
- Add barman-cloud-backup-list to list backups taken with
barman-cloud-backup in an object store
- Add support for arbitrary archive size for barman-cloud-backup
- Add support for --endpoint-url option to cloud utilities
- Remove strict superuser requirement for PG 10+ (by Kaarel Moppel)
- Add --log-level runtime option for barman to override default log
level for a specific command
- Support for PostgreSQL 13
- Bug fixes:
- Suppress messages and warning with SSH connections in barman-cli
(GH-257)
- Fix a race condition when retrieving uploaded parts in
barman-cloud-backup (GH-259)
- Close the PostgreSQL connection after a backup (GH-258)
- Check for uninitialized replication slots in receive-wal --reset
(GH-260)
- Ensure that begin_wal is valorised before acting on it (GH-262)
- Fix bug in XLOG/WAL arithmetic with custom segment size (GH-287)
- Fix rsync compatibility error with recent rsync
- Fix PostgreSQLClient version parsing
- Fix PostgreSQL exception handling with non ASCII messages
- Ensure each postgres connection has an empty search_path
- Avoid connecting to PostgreSQL while reading a backup.info file
If you are using already barman-cloud-wal-archive or barman-cloud-backup
installed via RPM/Apt package and you are upgrading your system, you
must install the barman-cli-cloud package. All cloud related tools are
now part of the barman-cli-cloud package, including
barman-cloud-wal-archive and barman-cloud-backup that were previously
shipped with barman-cli. The reason is complex dependency management of
the boto3 library, which is a requirement for the cloud utilities.
Version 2.10 - 5 Dec 2019
- Pull .partial WAL files with get-wal and barman-wal-restore,
allowing restore_command in a recovery scenario to fetch a partial
WAL file's content from the Barman server. This feature simplifies
and enhances RPO=0 recovery operations.
- Store the PostgreSQL system identifier in the server directory and
inside the backup information file. Improve check command to verify
the consistency of the system identifier with active connections
(standard and replication) and data on disk.
- A new script called barman-cloud-wal-archive has been added to the
barman-cli package to directly ship WAL files from PostgreSQL (using
archive_command) to cloud object storage services that are
compatible with AWS S3. It supports encryption and compression.
- A new script called barman-cloud-backup has been added to the
barman-cli package to directly ship base backups from a local
PostgreSQL server to cloud object storage services that are
compatible with AWS S3. It supports encryption, parallel upload,
compression.
- Automated creation of replication slots through the server/global
option create_slot. When set to auto, Barman creates the replication
slot, in case streaming_archiver is enabled and slot_name is
defined. The default value is manual for back-compatibility.
- Add '-w/--wait' option to backup command, making Barman wait for all
required WAL files to be archived before considering the backup
completed. Add also the --wait-timeout option (default 0, no
timeout).
- Redact passwords from Barman output, in particular from
barman diagnose (InfoSec)
- Improve robustness of receive-wal --reset command, by verifying that
the last partial file is aligned with the current location or, if
present, with replication slot's.
- Documentation improvements
- Bug fixes:
- Wrong string matching operation when excluding tablespaces
inside PGDATA (GH-245)
- Minor fixes in WAL delete hook scripts (GH-240)
- Fix PostgreSQL connection aliveness check (GH-239)
Version 2.9 - 1 Aug 2019
- Transparently support PostgreSQL 12, by supporting the new way of
managing recovery and standby settings through GUC options and
signal files (recovery.signal and standby.signal)
- Add --bwlimit command line option to set bandwidth limitation for
backup and recover commands
- Ignore WAL archive failure for check command in case the latest
backup is WAITING_FOR_WALS
- Add --target-lsn option to set recovery target Log Sequence Number
for recover command with PostgreSQL 10 or higher
- Add --spool-dir option to barman-wal-restore so that users can
change the spool directory location from the default, avoiding
conflicts in case of multiple PostgreSQL instances on the same
server (thanks to Drazen Kacar).
- Rename barman_xlog directory to barman_wal
- JSON output writer to export command output as JSON objects and
facilitate integration with external tools and systems (thanks to
Marcin Onufry Hlybin). Experimental in this release.
Bug fixes:
- replication-status doesn’t show streamers with no slot (GH-222)
- When checking that a connection is alive (“SELECT 1” query),
preserve the status of the PostgreSQL connection (GH-149). This
fixes those cases of connections that were terminated due to
idle-in-transaction timeout, causing concurrent backups to fail.
Version 2.8 - 17 May 2019
- Add support for reuse_backup in geo-redundancy for incremental
backup copy in passive nodes
- Improve performance of rsync based copy by using strptime instead of
the more generic dateutil.parser (#210)
- Add ‘--test’ option to barman-wal-archive and barman-wal-restore to
verify the connection with the Barman server
- Complain if backup_options is not explicitly set, as the future
default value will change from exclusive_backup to concurrent_backup
when PostgreSQL 9.5 will be declared EOL by the PGDG
- Display additional settings in the show-server and diagnose
commands: archive_timeout, data_checksums, hot_standby,
max_wal_senders, max_replication_slots and wal_compression.
- Merge the barman-cli project in Barman
- Bug fixes:
- Fix encoding error in get-wal on Python 3 (Jeff Janes, #221)
- Fix exclude_and_protect_filter (Jeff Janes, #217)
- Remove spurious message when resetting WAL (Jeff Janes, #215)
- Fix sync-wals error if primary has WALs older than the first
backup
- Support for double quotes in synchronous_standby_names setting
- Minor changes:
- Improve messaging of check --nagios for inactive servers
- Log remote SSH command with recover command
- Hide logical decoding connections in replication-status command
This release officially supports Python 3 and deprecates Python 2 (which
might be discontinued in future releases).
PostgreSQL 9.3 and older is deprecated from this release of Barman.
Support for backup from standby is now limited to PostgreSQL 9.4 or
higher and to WAL shipping from the standby (please refer to the
documentation for details).
Version 2.7 - 21 Mar 2019
- Fix error handling during the parallel backup. Previously an
unrecoverable error during the copy could have corrupted the barman
internal state, requiring a manual kill of barman process with
SIGTERM and a manual cleanup of the running backup in PostgreSQL.
(GH#199)
- Fix support of UTF-8 characters in input and output (GH#194 and
GH#196)
- Ignore history/backup/partial files for first sync of geo-redundancy
(GH#198)
- Fix network failure with geo-redundancy causing cron to break
(GH#202)
- Fix backup validation in PostgreSQL older than 9.2
- Various documentation fixes
Version 2.6 - 4 Feb 2019
- Add support for Geographical redundancy, introducing 3 new commands:
sync-info, sync-backup and sync-wals. Geo-redundancy allows a Barman
server to use another Barman server as data source instead of a
PostgreSQL server.
- Add put-wal command that allows Barman to safely receive WAL files
via PostgreSQL's archive_command using the barman-wal-archive script