Backuppc no compression when change topdir

Bug #246659 reported by Totologie
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
backuppc (Fedora)
Fix Released
Medium
backuppc (Ubuntu)
Fix Released
Undecided
Unassigned
Declined for Intrepid by Mathias Gug
Declined for Jaunty by Mathias Gug
Declined for Karmic by Mathias Gug

Bug Description

Binary package hint: backuppc

Description: Ubuntu 8.04
Release: 8.04

backuppc:
  Installé : 3.0.0-4ubuntu1
  Candidat : 3.0.0-4ubuntu1
 Table de version :
 *** 3.0.0-4ubuntu1 0
        500 http://fr.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

I need to change the $Conf{TopDir}.

When you change it, you can't use compression... Backuppc doesn't create "cpool" directory and doesn't compress files.
It's not a access right problem. The user "backuppc" have full rights on the new directory
I have the message in log's file
2008-07-08 18:39:59 BackupPC_link got error -4 when calling MakeFileLink(/BACKUP_NEW_DIR/pc/s0000000a/0/test_file, 5f4f86067ff512ef3da70e5b1974952a, 1)

When I change $Conf{TopDir} to /var/lib/backuppc it's working...

Totologie (aboury)
description: updated
Revision history for this message
In , Filipe (filipe-redhat-bugs) wrote :

Created attachment 325239
Patch for lib/BackupPC/Lib.pm

Description of problem:
Changing TopDir in config file does not affect pool and cpool, BackupPC still thinks those are under the default directory /var/lib/BackupPC

Version-Release number of selected component (if applicable):
3.1.0-3.fc10

How reproducible:
Every time.

Steps to Reproduce:
1. Set $Conf{TopDir} = '/whatever'; in config.pl
2. Create /whatever with the default BackupPC directories (pool, cpool, pc, trash) and right permissions.
3. Run a backup.

Actual results:
cpool will be empty, and this will be the output in /var/log/BackupPC/LOG:
2008-11-29 10:23:40 BackupPC_link got error -4 when calling MakeFileLink(/whatever/pc/xxxname/0/f%2fetc/fDIR_COLORS, a1fbdaecae5425dc9d24653e5c87a22e, 1)

Expected results:
The files in cpool would be correctly created.

Additional info:
This mailing list post has a patch for the problem:
http://sourceforge.net/mailarchive/message.php?msg_name=20080808032558.GG13869%40gratch.parplies.de

I'm attaching the same patch here.

I applied this patch to an already installed BackupPC from the Fedora RPM, and after that it worked as supposed to.

Revision history for this message
In , Johan (johan-redhat-bugs) wrote :

I understand the problem...

But these patch is not included upstream, and seems not well tested...

I'll keep this in mind, but won't include it for now, I'd like to have more come backs before.

Revision history for this message
In , Filipe (filipe-redhat-bugs) wrote :

The same problem has been reported several other times in the backuppc-devel list:
http://sourceforge.net/mailarchive/forum.php?thread_name=48CEEE9A.3080106%40resheteva.lan&forum_name=backuppc-devel
http://sourceforge.net/mailarchive/forum.php?thread_name=20080917151648.GC22362%40localhost.localdomain&forum_name=backuppc-devel
http://sourceforge.net/mailarchive/forum.php?thread_name=491B3BD2.4080301%40gmail.com&forum_name=backuppc-devel
http://sourceforge.net/mailarchive/forum.php?thread_name=4921C17B.1050905%40resheteva.lan&forum_name=backuppc-devel

The problem has been reported to the list since August, but so far the developers have not said anything about it. If you have another way of contacting them, please do, since this is a problem that should be simple to solve.

There is an alternative patch suggested by a Debian user, but it's setting the variables on the wrong place, inside the function that reads the config file instead of after calling that function where TopDir may potentially be changed.

If you look at the patch, it's extremely straighforward, all it's doing is setting CPool and Pool *after* resetting TopDir instead of before. You can also do the steps on the reported bug and verify that it indeed happens, and cpool will be empty. In fact, you will have a directory structure created under /var/lib/backuppc, no matter what you set TopDir to.

There is also the Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495504

But there they took a ridiculous approach of saying that if you want to do that, you should use a symbolic link in /var/lib/backuppc to wherever you want to move it, but that is ridiculous since it breaks the installed RPM (rpm --verify will point that out), and also, if that's the case, the possibility to redefine TopDir should be removed from the config.

I still think you should go ahead and apply the patch.

Revision history for this message
In , Johan (johan-redhat-bugs) wrote :

The symlink is what I've used for long times, it was not possible to change the backup dir in BackupPC 2.x ; and I've kept this method.

But I'm okay, I'll take a look to push the new patched version on testing this week ; the patch is very simple, thanks for it.

Revision history for this message
In , Filipe (filipe-redhat-bugs) wrote :

Hi,

Please see this message by Paul Mantz from the backuppc-devel mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_name=42f28fe0812101410v5d625b3g68693c28e1a8b258%40mail.gmail.com&forum_name=backuppc-devel

It includes a patch for the issue (similar to the one I posted, however putting the lines a little lower in the code).

Also have a look at this previous e-mail, where Craig Barratt says Paul Mantz is actually who has been doing more development in BackupPC recently:
http://sourceforge.net/mailarchive/forum.php?thread_name=a1a3029e-c4b5-4788-b381-560a8373e5fb&forum_name=backuppc-devel

He says this patch will be included in the next Zmanda release of BackupPC, and as the other e-mail suggests, it will be also present in the next main release of BackupPC as well.

Revision history for this message
In , Johan (johan-redhat-bugs) wrote :

Paul Mantz released a "BackupPC Community 3.1.1" : http://sourceforge.net/mailarchive/forum.php?thread_name=42f28fe0812221729y3915cdcei1900877208cfbd54%40mail.gmail.com&forum_name=backuppc-users

But, for the moment, changes were not commited upstream, so I won't package this version, I'll wait for changes to be commited upstream, as he promised.

This work on BackupPC seems a little bit closed to me, and zmanda's backuppc.com does not seem to be affiliated in any way with the project.

Patching should also be a solution, but I'd prefer to see an official new release :)

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

BackupPC-3.1.0-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/BackupPC-3.1.0-4.fc10

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

BackupPC-3.1.0-4.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/BackupPC-3.1.0-4.fc9

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

BackupPC-3.1.0-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update BackupPC'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3517

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

BackupPC-3.1.0-4.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing-newkey update BackupPC'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3608

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

BackupPC-3.1.0-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

BackupPC-3.1.0-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
Thilo-Alexander Ginkel (thilo.ginkel) wrote :

Just having experienced this problem myself I did some research and apparently changing $Conf{TopDir} after installation is not supported as stated by the README.Debian for BackupPC:

-- 8< --
If you do not like the default data directory (/var/lib/backuppc/), you
should move this directory where you want and make a symbolic link from
the new directory to the default one (all paths are hardcoded so it's the
easiest way to change the data directory).
-- 8< --

There are, however, workarounds, which are documented at: http://backuppc.wiki.sourceforge.net/change+archive+directory

Revision history for this message
Peter Whittaker (pwwnow) wrote :

I'm marking this as confirmed as it meets the definition of a real bug no matter how one looks at it.

Not being able to move TopDir is a bug: Many of us have /var on / and have / on a single fast disk, but want our main data on our SAN or RAID array. For example, I have /home on /dev/md0 and set TopDir to /home/backuppc. We can move it, but it isn't supported - not supporting such a crucial feature is a bug.

Having hardcoded default paths is a bug. It never ceases to amaze that hardcoded paths continue to make it into production software.

I've also added the symlink, hope it eliminates that error.

Changed in backuppc (Ubuntu):
status: New → Confirmed
Revision history for this message
x (xyzx-deactivatedaccount) wrote :

It's not actually a hardcoded path but a bug in one of the perl scripts.
The attached Fedora bug has a patch for this bug.

There is also a bugreport at Debian, but they "resolved" it by telling the the reporter to create a symlink... which is not the right way to do this imho.
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495504)

Changed in backuppc (Fedora):
status: Unknown → Fix Released
Revision history for this message
Peter M (peter-bolkhuis) wrote :

My suggestion would be to _at least_ add a notice about this behaviour in the distr config file. This is still a bug in 9.04.

After forgetting this issue when struggling with it in 8.04 as well, just cost me a couple of hours (when realizing what it was I did felt kinda stupid not to rember it but still..) trying to understand the somewhat cryptic error message (`MakeFileLink returns error -4`) .

Anyway, adding a extra notice about this somewhere should at least help new users to avoid this problem.

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Does this problem persist in 9.10 (Karmic) or in the Lucid beta? The RedHat bug report is somewhat confusing as to whether the cpool patch has been released....

Revision history for this message
Chuck Short (zulcss) wrote :

This is fixed in natty.

Changed in backuppc (Ubuntu):
status: Confirmed → Fix Released
Changed in backuppc (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.