mainstoreBackup - Support: sr #108489, [SOLVED] No hardlinks

 
 

sr #108489: [SOLVED] No hardlinks

Submitter:  Achim <esj>
Submitted:  Fri 31 Jan 2014 05:45:23 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 13 Feb 2014 09:22:51 AM UTC, comment #4: 

Hi Heinz-Josef,

> You can also use maxFilelen=0 and logrotate (but I never tested that)


This works for me with the options "size", "compress" and "rotate" in logrotate to allow a compressed ring buffer.

If logrotate detects a logfile > "size", it will be rotated if logrotate is triggered. This happens by default once a day by /etc/cron.daily/logrotate on a Ubuntu 12.04.

Regards, Achim

Achim <esj>
Mon 03 Feb 2014 09:22:55 AM UTC, comment #3: 


> I would like to have also a possibility to compress the older ones

see logFile + saveLogs + compressWith (+ eventually maxFilelen)

You can also use maxFilelen=0 and logrotate (but I never tested that)

Regards, Heinz-Josef


Heinz-Josef Claes <hjclaes>
Group administrator
Mon 03 Feb 2014 09:05:01 AM UTC, comment #2: 

Hi Heinz-Josef,

> If you really found / find a place with this kind of description, please tell me where.


Yes, I'll do of course. But until now I wasn't successful.

> This is totally wrong and absolutely makes no sense.


Good to know, now it's clear and working!
I also understood the useage of the "blocked file" feature.

logInBackupDir with compressLogInBackupDir is now also activated and very nice.

As the standard logfile could get very big (maxFilelen and noOfOldFiles adjusted) I would like to have also a possibility to compress the older ones. I haven't found any compression for the standard files, can I do this with logrotate? Or could this cause conflicts?

Regards, Achim

Achim <esj>
Sun 02 Feb 2014 08:37:23 AM UTC, comment #1: 


> Special for the last point I found that hint somewhere in the documentation that one "series" could be used for this scenario. Unfortunately I can't find the hint again ;-(


If you really found / find a place with this kind of description, please tell me where. This is totally wrong and absolutely makes no sense. (But I think this is a misunderstanding or typo at some point - I cannot believe this exists in the documentation.)

Running two different backups into one series results in the fact that storeBackup treats them as one backups each time, so both keep* configurations are used one after the other. Also, in default configuration, storeBackup.pl only takes the meta data of the last backup of each series. If you only use one series for two different type of data sets in alternating order, naturally hardlinking doesn't work.

> I checked the inodes and found out, that the same big files had multipe inodes ;-( Fatal for VM, ISO or media backups...


Btw, the "blocked file" feature only is useful for storing big files with parts in it changing from time to time. So eg. it's very useful for VMs, but doesn't help for ISOs (which normally never change).

> Also only one (the youngest) .md5CheckSums.bz2 was read, but this is quickly overread in the debug log.


I think it's always useful to use option logInBackupDir. This also allows you too look into the log easily years after creating the backup.

If I remember well, you can also use eg.
--logFile /tmp/log --maxFilelen 0
Setting maxFilelen to zero means the log file will not be rotated.

Regards, Heinz-Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Fri 31 Jan 2014 05:45:23 PM UTC, original submission:  

Hi all,

another trap I jumped into...

To separte important from unimportant backups I decided to use different keepAll's for different directories to back up:

- two different backups
- two different configs
- one "series"

Special for the last point I found that hint somewhere in the documentation that one "series" could be used for this scenario. Unfortunately I can't find the hint again ;-(

And this was the trap becaus the important and the unimportant backup rotated the most time. So one of my destination disks was sometimes full.

I checked the inodes and found out, that the same big files had multipe inodes ;-( Fatal for VM, ISO or media backups...

The I found out that by default only the youngest backup from all (1) series is considered unless otherBackupSeries tells anything else...

Also only one (the youngest) .md5CheckSums.bz2 was read, but this is quickly overread in the debug log.

Now and better:
- two different backups
- two different configs
- two different series
- otherBackupSeries=all:default (will be reduced after some days in test)

Regards, Achim

Achim <esj>

 

(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)
  • -email is unavailable- added by esj (Submitted the item)
  •  

    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
    2014-02-13 hjclaes StatusNone Done

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code