View Issue Details

IDProjectCategoryView StatusLast Update
0001563bareos-corefile daemonpublic2023-11-20 11:46
Reporterhostedpower Assigned Tobruno-at-bareos  
Status closedResolutionfixed 
PlatformLinuxOSDebianOS Version12
Summary0001563: New python PostgreSQL problem with symbolic links

We don't have a fixed directory to specify the postgresql folder. We have many different possibilities on different OS's. Also the version gives a different path for each OS.

Unless there is another way to fix this, the only option we see is using a symbolic link. However we cannot properly restore when doing this. The target folder is immediately overwrritten.

Steps To Reproduceln -s /var/lib/postgresql/15/main /var/lib/pgsql_data

The backup configuration then uses: postgresql_data_dir=/var/lib/pgsql_data

Then the backup runs fine , and I believe it takes all data. However when we restore, we end up with just a symlink to pgsql_data , the files inside the symbolic link are IMMEDIATELY overwritten and lead to losing our original postgresql immediately.

Additional InformationSome screenshots posted here:
TagsNo tags attached.




2023-10-31 17:54

manager   ~0005489

Thanks for the report
We will emphasis into the documentation that postgresql_data_dir parameter need to be a real path and dir, and not a symlink to that path.

If you give a symlink to Bareos for backup, that one has to be backup as a symlink, and restored like it was a symlink, meaning pointing data to the location they were during the backup, then the rest of the data goes into it.

We process exactly the same with the tablespace where in data/pg_tblspc you're getting symlink to a real location that is decoded to backup files in the real location.


2023-10-31 18:06

reporter   ~0005490

Isn't this fixable somehow? It's very hard for us now to configure a job. It will be different all the time parameter very often...

How is this solvable?


2023-11-03 10:32

reporter   ~0005494

Hi , the old plugin has no such issues at all, I was expecting the same for the new plugin. I'm a bit disappointed no solution would be provided.

Here is a screenshot from the old plugin. These are symbolic links as well, but it doesn't treat it like that!
image.png (20,739 bytes)   
image.png (20,739 bytes)   


2023-11-06 10:16

manager   ~0005497

Without systemtest that can be replayed, I have for the moment no ideas how the plugin behave in the case you describe.


2023-11-06 10:45

reporter   ~0005498

Hello Bruno, what do you mean? I just checked backups done with the previous plugin and there the listing and restore is just fine, it also uses symbolic link.


2023-11-06 12:03

manager   ~0005499

What I mean is the following, when you backup a symlink, this has to be recorded as a symlink
Below home and lib are symlink to directory, ioda is a directory, you can see that attributes are quite different.

The previous plugin didn't take care of the root given. The new one respect the type as the bareos-fd C++ code would have done.


2023-11-06 12:06

reporter   ~0005500

The previous plugin allowed to have a simple configuration and worked always very fine for the use case.

Can you instruct us how we configure the new plugin in a way it will always find the correct path for PostgreSQL?


2023-11-07 14:10

manager   ~0005502

After checking some possible, we will adapt to a new approach which will offer more security and robustness in such cases.

It look like we can remove the postgresql_data_dir parameter, because the cluster will be able to give that location.
`select setting from pg_settings where name = 'data_directory';`

Concerning wal_archives dir, we will check if this location is a symlink, and if it is, we will issue a warning in the job, and we will backup the real location.

This mean, in restore, real locations will be presented, and will be correctly restored to the "where" parameter.
Beware that previous limitations about tblspace link still apply like it is mentioned into postgresql documentation.

Would be this behavior a correct fix to your needs?


2023-11-08 13:54

reporter   ~0005506

`select setting from pg_settings where name = 'data_directory';` --> sounds like a truly fantastic solution and it will always work, waaaay better!!! :D :D

The wal_archives are a fixed physical folder we picked (on purpose), but it cannot hurt if a symbolic link would work too.

So yes , go ahead, it will be a great optimization!

Could you explain this part for the sake of completeness since I don't understand: "Beware that previous limitations about tblspace link still apply like it is mentioned into postgresql documentation."

PS: You could maybe even detect that the data dir has changed automatically, and enforce a full backup in such case. Because it's likely a new postgresql version was installed when this happens. A restore that was done probably also needs a full backup afterwards? I think it doesn't know this now.


2023-11-08 16:06

manager   ~0005507

Hi thanks for your quick feedback.
This is what will be implemented: all configuration known by the cluster will be used
cluster_configuration_parameters = dict([('data_directory',''),('log_directory','')('config_file',''),('hba_file',''),('ident_file',''),('krb_server_keyfile',''),('ssl_ca_file',''),('ssl_cert_file',''),('ssl_crl_file',''),('ssl_dh_params_file',''),('ssl_key_file',''),('ssl_crl_dir','')])
so cluster like in debian world will have their configuration backup with the plugin (at least we will try to have that complete)....

We also add a safety measure to Failed the job if archive_mode is off, or archive_command is empty: both are needed to qualify a system ready for PITR

We will emit a warning if wal_archives_dir is a symlink, that we are backuping not the symlink but the real location.

For the other request, I will have to decline to do more without some sort of sponsoring and at a later point.
- The limit is that a plugin can't upgrade a job level after start (we can fail).
- If we detect a major pg changes during incremental compared to last full we fail the job asking for a new full
- About cluster restored and restarted: it is documented that people should run a new full afterwards, and maybe there's some possible detection with history timeline.


2023-11-15 17:51

manager   ~0005515

A note for information, there's actually a work in progress (need some final adjustments, but globally functionality are all in, except documentation changes)


2023-11-15 20:29

reporter   ~0005516

Thanks a lot, quite some progress has been made ! :)


2023-11-20 11:46

manager   ~0005520

PR1599 will get merged today into master, and will appear in bareos 23 release.

Issue History

Date Modified Username Field Change
2023-10-31 10:19 hostedpower New Issue
2023-10-31 17:54 bruno-at-bareos Note Added: 0005489
2023-10-31 18:06 hostedpower Note Added: 0005490
2023-11-03 10:32 hostedpower Note Added: 0005494
2023-11-03 10:32 hostedpower File Added: image.png
2023-11-06 10:16 bruno-at-bareos Note Added: 0005497
2023-11-06 10:45 hostedpower Note Added: 0005498
2023-11-06 12:03 bruno-at-bareos Note Added: 0005499
2023-11-06 12:03 bruno-at-bareos File Added: Screenshot_20231106_120029_1.jpg
2023-11-06 12:06 hostedpower Note Added: 0005500
2023-11-07 14:10 bruno-at-bareos Note Added: 0005502
2023-11-08 13:54 hostedpower Note Added: 0005506
2023-11-08 16:06 bruno-at-bareos Note Added: 0005507
2023-11-15 17:51 bruno-at-bareos Note Added: 0005515
2023-11-15 20:29 hostedpower Note Added: 0005516
2023-11-16 09:29 bruno-at-bareos Assigned To => bruno-at-bareos
2023-11-16 09:29 bruno-at-bareos Status new => assigned
2023-11-20 11:46 bruno-at-bareos Status assigned => closed
2023-11-20 11:46 bruno-at-bareos Resolution open => fixed
2023-11-20 11:46 bruno-at-bareos Note Added: 0005520