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

 
 

sr #108302: davfs2 and TSM backup

Submitter:  Anita Ceulemans <anitaceulemans>
Submitted:  Tue 14 May 2013 06:58:47 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Postponed
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

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

- <_71007>
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 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 _71007 (Posted a comment)
  • -email is unavailable- added by anitaceulemans (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.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-26 _71007 Open/ClosedOpen Closed
    2014-04-20 _71007 StatusIn Progress Postponed
    2013-05-15 _71007 StatusNone In Progress
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code