mainstoreBackup - Support: sr #108325, storeBackupRecover.pl and no free...

 
 

sr #108325: storeBackupRecover.pl and no free space on target

Submitter:  None
Submitted:  Tue 18 Jun 2013 09:54:16 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  Done
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 01 Jul 2013 10:12:37 PM UTC, comment #4: 

Problems with  offsite-harddrive Backup solved:

mhddfs: join several filesystems together to form a single larger one

https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC4QFjAA&url=http%3A%2F%2Fromanrm.ru%2Fen%2Fmhddfs&ei=qP7RUceEJtD04QTU8oHoDg&usg=AFQjCNFRLbWZiS8A2XaBFd2cB2SIQ85KZQ&sig2=AoPMkMaYcDh3BnhbojHf6A&bvm=bv.48572450,d.bGE

Ciao

Lopiuh at gmail.com

Anonymous
Sat 29 Jun 2013 11:09:30 AM UTC, comment #3: 

fault corrected in the next release

The description of the problem below was wrong - but lead to the same problem in storeBackup.pl itself :-) .

In storeBackupRestore.pl, the error message from bzip2 or cp (or whatever) simply was not evaluated.

Heinz-Josef Claes <hjclaes>
Group administrator
Wed 19 Jun 2013 11:32:51 PM UTC, comment #2: 

Hi Heinz,

no problem at all (as far as verifying restored files against backup files is mandatory for me). I use

rsync -avhxSDci --dry-run --no-g --no-p --no-t RESTORE-path bcukup-DIR-path

for that. It is transparent as far as I DO NOT use compression in  storeBackup.

note: -H should not be used because of different hardlinks in restored files (some of the identical files) and storeBackup (all of the identical files). --no-g --no-p --no-t is necessary because in the backup directory all ahrdlinked files have the same and after restore the correct values are restored by storeBackup.

I write this in order to give my "best practice" feedback. It was sensible to me to use a different tool (here rsync) to verify the backup prog (storeBackup).

Could not be better, thanks to storeBackup.

One problem left: offsite-Backups

My offsite-harddrives  are smaller than the source-directory. I don't find a simple file oriented copy solution to spread the source files on several disks. I use storeBackup to feed the 6 TB NAS. But I dont find a simple solution to divide out (2x 2,x TB Series) on several disks (I don't want to bring in directory limits and to create more series just because of offsite Harddisk size). I don't want to by again new 3 TB disks ;-) I don't like to use anything complicated (Bacula, BackupPC, Amanda), I don't like to use anything simple but not file orientaed (tar, dar, tape, ...)

(Maybe someone has an idea)

Greetings

lopiuh ÄT gmail.com

Anonymous
Wed 19 Jun 2013 01:25:41 PM UTC, comment #1: 

Since some time storeBackup is able to store the correct md5 sum in the backup also if a file changes it's content during the backup.

The changes made for this were implemented by a further number of fork/proc. The bug ist, that the error messages of the last program in this chain (which is eg. bzip2) are not transported to the storeBackup.pl log module.

I know the problem and hopefully will solve it soon.


Heinz-Josef Claes <hjclaes>
Group administrator
Tue 18 Jun 2013 09:54:16 AM UTC, original submission:  

Hi,

during run of storeBackupRecover.pl target runs full.

There is no error message (if all dirs can be created). In my case files could not be created.

-n -v don't give any failing information

used ext4 as target, nfs as source

full command:

/mnt/data/gen/storeBackup/bin/storeBackupRecover.pl -r  /mnt/foo/storebackup/server_gen/2013.06.09_03.05.11/tm -t .

Any clue?

greetings

lopiuh

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.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-06-29 hjclaes StatusIn Progress Done
    2013-06-19 hjclaes StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code