bugstoreBackup - Bugs: bug #28155, storebackup 3.2: Owner in Backup...


bug #28155: storebackup 3.2: Owner in Backup wrong, even if ignorePerms=no

Submitted by:  None
Submitted on:  Thu 03 Dec 2009 11:00:04 AM UTC  
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: Open

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Mon 30 Sep 2013 10:00:28 AM UTC, comment #3:

I never got an email about this report :-( .

I think it's clear. The behavior is described in section "Limitations" (since version 1.x).

I'll mark it as "invalid", because it's working like expected.

Heinz-Josef Claes <hjclaes>
Project Administrator
Thu 03 Dec 2009 02:49:57 PM UTC, comment #2:

Okay. I figured it out.
storeBackup creates one copy of a file and creates hardlinks to this copy if a file has the same checksum. This behaviour is completely independent of the filename...

This is cool (and can save a lot of disk space and backup time), but comes along with some disadvantages. The biggest disadvantage are:

1) Users can not restore their files by just copying them from the backup (f.e. via a filemanager). They have to use storeBackupRecover.pl (which means: they will ask the administrator... :-) ).

2) After a crash you need a rescue CD with storeBackup (and PERL etc.) installed. The restore via rsync can be the path into deep, deep trouble... (at least, this should be marked very, very clearly in every documentation.)

Thu 03 Dec 2009 01:45:14 PM UTC, comment #1:

After my bugreport I performed some research (I know, it's better the other way around...):

a) Let there be some identical files in the original data:

-rw-r--r-- 1 abc users 287 2006-06-18 12:55 /home/abc/.gtkrc-2.0
-rw-r--r-- 1 def users 287 2006-06-07 20:37 /home/def/.gtkrc-2.0
-rw-r--r-- 1 ghi users 287 2006-09-06 17:47 /home/ghi/.gtkrc-2.0
-rw-r--r-- 1 jkl users 287 2006-07-14 17:22 /home/jkl/.gtkrc-2.0
-rw-r--r-- 1 mno users 287 2006-06-27 13:19 /home/mno/.gtkrc-2.0

b) After the backup, the following files can be found at the backup media:

-rw-r--r-- 10 mno users 287 2006-06-18 12:55 /mnt/backup/default/2009.12.03_02.05.02/home/abc/.gtkrc-2.0
-rw-r--r-- 10 mno users 287 2006-06-18 12:55 /mnt/backup/default/2009.12.03_02.05.02/home/def/.gtkrc-2.0
-rw-r--r-- 10 mno users 287 2006-06-18 12:55 /mnt/backup/default/2009.12.03_02.05.02/home/ghi/.gtkrc-2.0
-rw-r--r-- 10 mno users 287 2006-06-18 12:55 /mnt/backup/default/2009.12.03_02.05.02/home/jkl/.gtkrc-2.0
-rw-r--r-- 10 mno users 287 2006-06-18 12:55 /mnt/backup/default/2009.12.03_02.05.02/home/mno/.gtkrc-2.0

  • The owner of the backup file is the owner of the last file which has been saved during backup
  • The timnestamp is the timestamp of the first file which has been saved during backup
Thu 03 Dec 2009 11:00:04 AM UTC, original submission:

Version: storeBackup 3.2
Backup Scenario: Backup of some directories to an attached USB harddrive
OS: Linux 2.6.18-6-686-bigmem (Debian 5.0.3, daily updates)


  • Removed storeBackup 1.19 which comes along with Debian
  • Installed storebackup 3.2
  • Created configfile as described in the documentation
  • Performed first backup
  • After the backup, I checked the ownership of the files in the original home directories (/home/) and in the backup (mnt/backup/srv/default/2009.12.03_02.05.02/home/). Result: Most of the uid's are wrong.

Settings in config file:




(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by hjclaes (Posted a comment)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 30 Sep 2013 10:00:28 AM UTChjclaesStatusNone=>Invalid

    Back to the top

    Powered by Savane 3.1-cleanup1