 |
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. |
|
|
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? |
|
|
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) |
|
|
Without systemtest that can be replayed, I have for the moment no ideas how the plugin behave in the case you describe. |
|
|
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. |
|
|
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. Screenshot_20231106_120029_1.jpg (42,446 bytes) |
|
|
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? |
|
|
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? |
|
|
`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. |
|
|
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. |
|
|
A note for information, there's actually a work in progress (need some final adjustments, but globally functionality are all in, except documentation changes) https://github.com/bareos/bareos/pull/1599 |
|
|
Thanks a lot, quite some progress has been made ! :) |
|
|
PR1599 will get merged today into master, and will appear in bareos 23 release. |
- Anonymous
