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

 
 

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

Submitter:  None
Submitted:  Thu 03 Dec 2009 11:00:04 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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.)

 Anonymous
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
Anonymous
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)

Scenario:

  • 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:

sourceDir=/my-files/
backupDir=/mnt/backup/my-files
lockFile=/tmp/storeBackup_my-files.lock
contExceptDirsErr=no
exceptDirs=
exceptTypes=
cpIsGnu=yes
linkSymlinks=yes
withUserGroupStat=yes
userGroupStatFile=/var/log/storebackup_statistics-last-backup_my-files.txt
exceptSuffix=.*
doNotCompressMD5File=yes
verbose=no
keepFirstOfYear=3650d
keepLastOfYear=3650d
keepLastOfMonth=365d
keepLastOfWeek=120d
keepMinNumber=50
logFile=/var/log/storeBackup_my-files.log
plusLogStdout=no
noOfOldFiles=100

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-30 hjclaes StatusNone Invalid

    Back to the top

    Copyright © 2025 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-04e1.
    Corresponding source code