How to update from 17.2 to 18.2

Goncalo Sousa

unread,

Apr 27, 2020, 10:05:45 AM4/27/20

to bareos-users

I have read https://docs.bareos.org/IntroductionAndTutorial/UpdatingBareos.html but it doesnt specify the order or how to only the database.

How do I upgrade it?

The server is CentOS Linux release 7.5. This means I have to upgrade the Clients FD's too or are they compatible?

Brock Palen

unread,

Apr 27, 2020, 11:45:42 AM4/27/20

to Goncalo Sousa, bareos-users

Generally older FD will work with newer SD and DIR. But do make sure your SD and DIR are the same version. Save a lot of headaches.

That said if you can update the FD I would for fixes.

Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting

> --
> You received this message because you are subscribed to the Google Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/d3f8f977-3fc8-44f7-b458-8ea68a0d8652%40googlegroups.com.

Goncalo Sousa

unread,

Apr 27, 2020, 11:52:38 AM4/27/20

to bareos-users

How can I check the versions?

How can I upgrade bareos?

segunda-feira, 27 de Abril de 2020 às 16:45:42 UTC+1, Brock Palen escreveu:

Generally older FD will work with newer SD and DIR. But do make sure your SD and DIR are the same version. Save a lot of headaches.

That said if you can update the FD I would for fixes.

Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting

> On Apr 27, 2020, at 10:05 AM, Goncalo Sousa <gtemp...@gmail.com> wrote:
>
> I have read https://docs.bareos.org/IntroductionAndTutorial/UpdatingBareos.html but it doesnt specify the order or how to only the database.
>
> How do I upgrade it?
>
> The server is CentOS Linux release 7.5. This means I have to upgrade the Clients FD's too or are they compatible?
>
> --
> You received this message because you are subscribed to the Google Groups "bareos-users" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to bareos...@googlegroups.com.

Brock Palen

unread,

Apr 27, 2020, 11:58:08 AM4/27/20

to Goncalo Sousa, bareos-users

If you installed form packages update your repo to point to the newer version. Eg. follow the install documentation. Your package managers should auto find the newer version mark the components for upgrade. It will auto run the scripts to update your database schema. If it doesn’t you can find the scripts in the install location an edit/run them manually. Generally you will not need to do this.

Then restart the services and that’s it.

As for checking version, use your package manager or use from the bconsole

status director
status storage=<…>
status client=<…>

If you leave off the =clientname it will prompt you to pick from a list.

Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting

> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/8767d51e-a61a-429f-a033-7e2be528fc63%40googlegroups.com.

Goncalo Sousa

unread,

Apr 27, 2020, 12:12:47 PM4/27/20

to bareos-users

So I just need to update repo and yum update bareos and run

su postgres -c /usr/lib/bareos/scripts/update_bareos_tables
su postgres -c /usr/lib/bareos/scripts/grant_bareos_privileges

and restart on server the bareos service? The Clients stay with version 17.2 and to new clients will have to do with 18.02 right?

> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/8767d51e-a61a-429f-a033-7e2be528fc63%40googlegroups.com.

Brock Palen

unread,

Apr 27, 2020, 3:14:17 PM4/27/20

to Goncalo Sousa, bareos-users

Yep in most cases that’s it. The packages should auto run the update scripts for the database, so you likely won’t even have to do that. Bareos will refuse to start if the schema is to old.

Yes work on updating your FD’s over time so they don’t get to far behind.

Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting

> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/6fd634a0-90d0-427d-b9d0-3bd7061351a0%40googlegroups.com.

Oleg Volkov

unread,

Apr 28, 2020, 2:29:46 AM4/28/20

to bareos-users

I found the safety way was to set up new server and move clients to it.

The fail back was much easy, without loosing backup history.

Goncalo Sousa

unread,

Apr 28, 2020, 7:28:55 AM4/28/20

to bareos-users

When I upgrade will I loose my history?

Oleg Volkov

unread,

Apr 28, 2020, 8:12:40 AM4/28/20

to bareos-users

No, I am talking about rollback, reverting back to previous version.

Upgrading of production server suggest that you have any roll back plan.

Anyway it is your choice, not mine.

Goncalo Sousa

unread,

Apr 28, 2020, 8:37:34 AM4/28/20

to bareos-users

yum history rollback [id] doesn't do the job?

Brock Palen

unread,

Apr 28, 2020, 9:39:05 AM4/28/20

to Goncalo Sousa, bareos-users

Just take a dump of your DB, and copy of your configs, before you upgrade.

You should have catalog backups anyway as it’s a vulnerable part of your system. That’s all you really need to roll back manually if needed. I like taking a SQL dump manually even though I have my catalog backups so I can avoid messing with bscan/bextract etc.

It also lets me manually inspect the dump that it worked as planned.
(yes always test restore your backups also)

Brock Palen
1 (989) 277-6075
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting

> --
> You received this message because you are subscribed to the Google Groups "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/34303ce5-505a-4f9c-b531-f9262b169689%40googlegroups.com.

Spadajspadaj

unread,

Apr 29, 2020, 5:51:32 AM4/29/20

to bareos...@googlegroups.com

In short, yum history rollback is not a good way to do do anything other than very small package changes. i.e. downgrading from version 1.4.27 to 1.4.26 of some package or completely removing package you just installed for testing along with all dependencies.

Longer explanation:

Yum history rollback just finds out which packages are to be installed (and in which versions) and which are to be removed. After that it simply downloads needed pakage files and runs appropriate install/remove actions. It's in no way similar to any "restore snapshot" operation. In case of files contained in the packages, the situation is easy - the "new" package installs new packages, then the files belonging to the "old" package but not belonging to "new" one are removed. Simple.

It gets more tricky with package scripts. RPM runs like this:

1. Runs pre-install script

2. Installs files

3. Runs post-install script

4. Runs pre-uninstall script

5. Removes files

6. Runs post-uninstall script

Steps 1-3 are run if there's any package installation or update (upgrade/downgrade) and steps 4-6 are run if there's any package removal (uninstall/upgrade/downgrade).

Bear with me, it's getting more magical :-)

The scripts executed during the operations are run almost completely without any additional environment or context. The only parameter is "a number representing the number of instances of the package currently installed on the system, after the current package has been installed or erased" (http://ftp.rpm.org/max-rpm/s1-rpm-inside-scripts.html). This means that install scripts might be run with an argument of 1 (initial install) or 2 (upgrade/downgrade) since after the install stage the number of package instances on the system will be equal to those numbers and the uninstall scripts might be run with an argument of 0 (complete removal) or 1 (upgrade/downgrade) since that's how many instances of package will be left after the uninstall phase. There is probably an option for

You can see how it's used by querying a package with rpm -q --scripts. A good example here is an openssh-server package which runs some actions only on complete removal.

Unfortunately, the rpm scripts have no more context about the package versions (and don't have any reasonable way for querying the state of the rpm database in the middle of a transaction) so there is no way of knowing whether the update operation is an upgrade or downgrade. And we need also to remember than usually "big upgrades" invoke some "external" changes, like database schema upgrades, which are not easily rollbackable (as we said before - rpm rollback doesn't work on system-level snapshot). Therefore it's usually either assumed that update operation is indeed an upgrade one, not a downgrade. And it's a good practice to check prerequisites before executing needed "upgrade scripts" (like check database schema version beforehand as to not apply an upgrade script twice). Sometimes packagers just create a package with new files and tell you to upgrade the dependencies (like database schema) on your own.

So, long story short - no, there is no simple way to perform a yum history rollback and have a usable system if the upgrade had been "deep".

Therefore if you upgrade Bareos installation upgrade I'd do a full configuration backup and database dump to have a working state to which you can roll back.