helpdavfs2 - Support: sr #108302, davfs2 and TSM backup

 
 

sr #108302: davfs2 and TSM backup

Submitted by:  Anita Ceulemans <anitaceulemans>
Submitted on:  Tue 14 May 2013 06:58:47 AM UTC  
 
Category: NonePriority: 5 - Normal
Severity: 3 - NormalStatus: Postponed
Privacy: PublicAssigned to: Werner Baumann <wbaumann>
Open/Closed: OpenOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Thu 16 May 2013 02:12:37 PM UTC, comment #3:

after a few tests following solution is implemented:
not the mount point /export/alfresco is used in the domain definition in the configuration file dsm.sys, but an incremental backup of all the sub-directories /export/alfresco/* is forced.
then the time at which the file system is mounted, plays no longer.

thanks

Anita Ceulemans <anitaceulemans>
Thu 16 May 2013 09:34:17 AM UTC, comment #2:

a look at file attributes in backups:

Name Size Modified Accessed Backed Up

README 1.84 KB 05/08/2012 04/03/2013 04/03/2013
README 1.84 KB 05/08/2012 05/14/2013 05/14/2013

the machine rebooted on: 04/02/2013

a remount of the filesystem was forced on: 05/14/2013

only the access time changed.

the file system is mounted with mount.davfs;
unfortunately the option -noatime is unknown in mount.davfs.

any suggestions?

Anita Ceulemans <anitaceulemans>
Wed 15 May 2013 07:40:05 PM UTC, comment #1:

This depends on what file attributes are used by the backup system to decide which files have changed. I'm not familiar with TSM. Looking at some of the files in two different backups might show this.

There are some restrictions in davfs2 which might cause problems with backup software.

Inode numbers:
When davfs2 sees a file for the first time it will create an inode number which is essentially random. After unmounting and mounting again it will most likely be different. If a buckup system looks at inode numbers it will not work with davfs2.

File modification time:
When davfs2 sees a file for the first time it will create the mtime from the Last-Modified-Time it gets from the server. As long as the server does not change Last-Modified the mtime will always be the same.

And now the difficult case:
When a file is changed locally davfs2 will set mtime to the time when the file was closed. davfs2 will upload the changed file to the server asynchronously and the server will set Last-Modified-Time when the file is completely transferred to the server. So the local mtime will be different from server's Last-Modified-Time. This is not a problem as long as the file system is mounted as davfs2 remembers both of this times. But when the file system is unmounted and the file is not in the local cache then davfs2 will forget the local mtime and create it newly from Last-Modified-Time when it is mounted the next time. The backup software will see a changed mtime think the file has been changed. But this should only happen for files that have been changed locally and only once.

If all files are backed up every time although they have not been changed there must be another reason. The documentation of the backup software as well as a look at file attributes in backups might give a hint.

Werner

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Tue 14 May 2013 06:58:47 AM UTC, original submission:

Each day an incremental backup is made of a file system mounted with mount.davfs:

https://dnetshare.cs.kuleuven.be/alfresco/webdav/ on /export/alfresco type davfs (ro,nosuid,nodev,_netdev)

The software we use is:
- TSM Tivoli version 6, release 1
- Linux beaker 3.2.0-40-generic #64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

After each reboot or remount of /export/alfresco a full dump is made.

Any idea how to fix this problem ?

Anita Ceulemans <anitaceulemans>

 

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

Attach File(s):
   
   
Comment:
   

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 wbaumann (Posted a comment)
  • -unavailable- added by anitaceulemans (Submitted the item)
  •  

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

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 20 Apr 2014 07:39:54 PM UTCwbaumannStatusIn Progress=>Postponed
    Wed 15 May 2013 07:40:05 PM UTCwbaumannStatusNone=>In Progress
      Assigned toNone=>wbaumann

    Back to the top


    Powered by Savane 3.1-cleanup1