alternativa repository - old release

[Allan Patrick]

Does anyone know of a repository that has copies of old versions of
bareos? I understand that there must be a license, it would be for old
versions only.

Thanks

[Andreas Rogge]

Am 21.05.23 um 03:51 schrieb Allan Patrick:

> Does anyone know of a repository that has copies of old versions of
> bareos? I understand that there must be a license, it would be for old
> versions only.

If you have a requirement why you need a specific package in a specific
version and it is not "I don't want to upgrade", then I'm pretty sure we
can help you with that.

Also, we're really interested to learn why people run ancient versions
of Bareos.

Best Regards,
Andreas
--
Andreas Rogge andrea...@bareos.com
Bareos GmbH & Co. KG Phone: +49 221-630693-86
http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz

[Willem Basson]

In our case, we just don't want to upgrade 'yet'. We have some custom integrations between our custom code and the Director, and it is not yet compatible with versions newer than 20.

[Andreas Rogge]

Am 29.05.23 um 15:08 schrieb Willem Basson:

> We have some custom integrations between our custom code and the
> Director, and it is not yet compatible with versions newer than 20.

Since Bareos 21.0.0 was released in December 2021 (almost 18 months
ago), you had the chance to adapt your integrations, but didn't.
How long do you think you'll need to upgrade? Maybe I can convince sales
to provide a time-limited (but otherwise free) access to the
subscription repository for you.

[Willem Basson]

Indeed, we had 18 months. But we didn't know that we had 18 months, because old versions were historically still available, so readying ourselves for Bareos upgrades hasn't featured as the most important thing to do yet.  We made a temporary plan by pulling old packages out of our backups for the time being.
The overall strategy is still extremely inconvenient, but I think it is a temporary inconvenience. I think if we understand the versioning cadence, we will be ok in future. The way we understand it, somewhere close to the end of the year, a new version will become 'current' (not sure if it is a coincidence that the version number matches the last two digits of that current year). Around the same time, a new version will appear in 'next', giving consumers around 11 months to become ready to switch to it.
What would have been great, is for at least a short period of time, there was also a 'previous' repo at downloads.bareos.org. Even a month or 3 would suffice. Right now, there is now way to cleanly and confidently move servers from one version to another. But I totally understand if your reasoning is that we need to pay if we need that functionality, since you don't recommend using the community version in production.

Maybe I should reach out to sales about bulk licensing?

[Andreas Rogge]

Am 31.05.23 um 10:15 schrieb Willem Basson:

> Indeed, we had 18 months. But we didn't know that we had 18 months,
> because old versions were historically still available, so readying
> ourselves for Bareos upgrades hasn't featured as the most important
> thing to do yet.  We made a temporary plan by pulling old packages out
> of our backups for the time being.

I'm glad you found a solution that works for you right now.
We also realize that a lot of people are running old version of Bareos
(a lot of people still seem to run 17.2). What we're trying to do is to
"push" the community to switch to the latest version, so we get more
feedback on that.
Breaking anyone's Bareos setup was definitely not one of our goals!

> What would have been great, is for at least a short period of time,
> there was also a 'previous' repo at downloads.bareos.org. Even a month
> or 3 would suffice. Right now, there is now way to cleanly and
> confidently move servers from one version to another. But I totally
> understand if your reasoning is that we need to pay if we need that
> functionality, since you don't recommend using the community version in
> production.

We announced that change. On December 19th 2022 when the new release
policy was announced, we clearly stated that outdated and discontinued
versions of Bareos will be removed from the download server.
That new release policy was also mentioned in the press release for
Bareos 22.
While the policy change basically stated that old packages would go away
immediately, we left the packages there for more than four months so
people had some time to adapt and migrate.

I somehow feel that we're bad at communicating stuff like that, because
a lot of people seem to not have noticed before the packages actually
went away.
If anybody has an idea how we can improve on that, please go ahead and
tell us!

> Maybe I should reach out to sales about bulk licensing?

That would be nice. I spoke to sales yesterday and explained your
situation. If you reach out to them, I'm pretty sure they can come up
with some kind of solution that works for you.

[Hwid DUNES]

May I present my REX about the policy change.

I choose bareos in 2018 because it was recommended by the French Government. We are a French High School, with our own datacenter. My team operates 100 virtual machines and nearly 20 physical ones for hosting web sites and applications. Some of them are very very old. My oldest is Debian 3.1 ! Please don't laught. It's realy hard to maintain and to keep secure. Old stuffs with huge amount of data cost a lot to move to modern versions. The main word is if it's works don't fix it. That's why we need old bareos versions.

My oldest bareos client version is 15. Directory and Storage are running version 19.2.7 on Debian 9 and Debian 10. I'd like to move the director and storage to Debian 12 / Bareos 22, but we have higher priorities. It's not planned yet.

The policy change on old version repository broke all my automatic bareos deployment over those 100 virtual machines and 20 physical hosts. And bareos version 22 is only available for maintained Linux distributions. I was only aware of the policy change after analysing the broken situation. Killing old software is a serious issue for the open source world.

I am wondering about compiling and packaging our .deb packages for old debian versions with an accurate bareos version, may be opening a public debian repository for that. Or leaving bareos...

Having to pay to have acces to old version is not fair. But paying for having accurate versions on old linux distribution would awesome.

Best regards.

Nicolas / HWID DUNES Team / Lyon / France

[IT PI]

Dear Bareos,

I work for an international nonprofit and I chose bareos in 2015 as our backup system, and I never looked back - it is really fantastic software (if you dedicate a bit of time initially to read the documentation). Especially the fact that we can have a separate storage daemon in our office for tapes while having all the rest in the server room of a partner organization (so we don't annoy them needing weekly access to change tapes).

However, as previous posters mentioned, time is scarce and new systems cost quite a lot of money.

I have one (important) physical server running Ubuntu 18.04 which gets security updates until 2028 through ESM (https://ubuntu.com/security/esm). Of course, replacing it has been planned for some years but budget and time constraints didn't allow that. Currently there is bareos-filedaemon v21 installed. I would like to upgrade the filedaemon v22 (or v23 if dependencies work, while not officially released for 18.04) but would also like to have a backup of the 2 deb files (bareos-filedaemon and bareos-common) in case I face a major problem and would need to reinstall v21 bareos client (I think I can do something like dpkg-repack but would rather just download those 2 files). 

However, I cannot find them anymore.

If old packages of community editions could still be made available online, that would be really great. Officially 18.04 and even 16.04 can still be run with ESM (maybe something similar exists for other distributions)

thank you,

[Frank Kohler]

On 1/23/25 11:14, 'IT PI' via bareos-users wrote:
> Dear Bareos,
>
> I work for an international nonprofit and I chose bareos in 2015 as
> our backup system, and I never looked back - it is really fantastic
> software (if you

Thanks! The team is following the ML and appreciating words like this.

> If old packages of community editions could still be made available
> online, that would be really great. Officially 18.04 and even 16.04
> can still be run with ESM (maybe something similar exists for other
> distributions)

Thanks for comparing us with Canonical - while we prove enterprise
scalability and readiness our organizations are quite different.


best,

Frank

--
--
Frank Kohler

Bareos GmbH & Co. KG

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH

Geschäftsführer: Stephan Dühr, J. Steffens, P. Storz

[Bruno Friedmann (bruno-at-bareos)]

I mean if you can afford ESM pricing and have that need to get access to bareos software maybe you should send a request to sales about getting a subscription :-)

[IT PI]

Hello,

a caveat when trying to use old bareos (FD) versions which I experienced: I backed up data with filedaemon v24 (using SD and DIR v24) and tried to restore it on another server which used filedeamon v21. The results were dozens of errors in the job like:

....

2025-02-11 13:05:27 target-fd JobId 14854: Error: findlib/attribs.cc:406 File size of restored file /mnt/vol0/restore/mnt/path/to/restored/file.JPG not correct. Original 610304, restored 197142.

....

this affected not all files, but "some" (not all checksums were different between original and restored files). backup and restoring using same server (FD v21) while using SD and DIR v24 did not cause any problems (I did some test-restores). The fileset used for both backup+restore workflows (FD21->FD21 and FD24->FD21) are identical (see below). client configs are also identical. The files were encrypted, but I triple-checked the used keypairs/masterkey and this should not have been the issue.

So I upgraded our "very important" server to 20.04 (everything went fine), upgraded to FD v24 and a test restore again worked flawlessly.

this is the fileset I used for backing up with FD24 (and FD21):

FileSet {
  Name = "source1-bkp1"
  Description = "Backup of /mnt/backup_manual"
  Include {
    Options {
      Signature = SHA1 
      Compression = LZ4
      verify = pins1
      Check File Changes = yes
      One FS = No     # change into other filessytems
      FS Type = btrfs
      FS Type = ext2  # filesystems of given types will be backed up
      FS Type = ext3  # others will be ignored
      FS Type = ext4
      FS Type = reiserfs
      FS Type = jfs
      FS Type = xfs
      FS Type = zfs
    }
    File = /mnt/backup_manual/
  }
  # Things that usually have to be excluded
  # You have to exclude /var/lib/bareos/storage
  # on your bareos server
  Exclude {
    File = /var/lib/bareos
    File = /var/lib/bareos/storage
    File = /proc
    File = /tmp
    File = /var/tmp
    File = /.journal
    File = /.fsck
  }
}