dragonmac Posted January 31, 2013 Report Share Posted January 31, 2013 Anyone know if Retrospect 10 solves this issue? Retrospect and file permissions problem? This just bit me in the @## this past week, over 700GB of data got backed up with the only change being ACL add. Had to since I just moved from 10.4.11 to 10.6.8 on a main file server. I have more permissions to tweek as well but I am holding off now till I find a solution. If 10 fixes this I'll upgrade, if not I'm hunting for a new backup tool cause this is nuts. Mike Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 31, 2013 Report Share Posted January 31, 2013 Had to since I just moved from 10.4.11 to 10.6.8 on a main file server. The file metadata is different between Mac OS X 10.4.x and 10.6.y. That is why Retrospect 6 is not supported on Mac OS X 10.6 or later, but supported up to and including 10.5.z. Since the OS presents the metadata to Retrospect as "different", then the file is seen as "different". (For instance, changed modified date is part of the metadata and is an obvious reason to backup the file again. There are other reasons, too.) This is not a Retrospect problem. Any backup package would do the same thing: Backup the files again. If it doesn't, I say it's a bug in that package as it will not observe file changes (in the metadata). Quote Link to comment Share on other sites More sharing options...
dragonmac Posted February 2, 2013 Author Report Share Posted February 2, 2013 I was using Retrospect 8 under 10.4.11 Server on an Intel Xeon Mac Pro, not Retro 6. The engine worked local but had to use my laptop (10.6.8) to administer changes via the Retro 8 admin. Under 10.4.11 < there was POSIX, which changes to, did not require the file to be backed up again. I believe just a change was noted to the permissions table in the backup so when a restore was needed the correct/most resent permissions where assigned. Under 10.5 > ACL is stable and needed in most cases to achieve inheritance. Metadata change or no Metadata change, the need to completely backup a file for an ACL permissions change does not seem to be needed. Am I then to assume that even when a file is "Opened", which creates a Metadata change to "Last Opened", but the file is not "Modified" that Retrospect 10 or 8 would backup the whole file again?? PS Going to test your claim with Time Machine, and see if a new copy of the file is saved for just an ACL change. Even if so there has to be a better way. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted February 2, 2013 Report Share Posted February 2, 2013 Time Machine will not run under 10.4.x, so that test can't be performed. We had a similar situation with Windows (and Retrospect for Windows). One client was dual boot, XP and Vista. It had three hard drives: One system disk each for XP and Vista and one called Data. There was one Retrospect client installed for each OS. First we backed up "Data" when running under XP. Then we backed up Data when running under Vista. All files were backed up again due to changed metadata. It was the same hardware, only the boot OS was changed. You will experience the same thing during the transition from 10.4.x to 10.6.y. Quote Link to comment Share on other sites More sharing options...
xvi Posted February 2, 2013 Report Share Posted February 2, 2013 Michael, I don't think OS X maintains a separate "last modification date" for data and metadata. So, except for a full byte compare, there's no way to know what part of data/metadata changed when the modification date changes. It can even be that nothing but the modification date changed (e.g. by using the "touch -m" command in Terminal). BTW, the modification date IS part of a file's metadata. After a bit of thinking, I'd say that "separate last modification date for data and metadata" would be a filesystem (i.e. HFS+) feature, not an OS feature? But I might be totally wrong... Quote Link to comment Share on other sites More sharing options...
prl Posted February 2, 2013 Report Share Posted February 2, 2013 U*ix file systems have long had separate fields for last accessed (stat.atime) , last modified (stat.mtime), and metadata last modified (stat.ctime, inode changed time). IIRC those timestamps go right back to the Sixth Edition Unix file system (1975). The '-c' option to ls displays and sorts by the inode change time. The following commands create a file, display its modification (ls default) time and inode change time, waits 2 minutes, then changes the file permissions (which modifies the inode, but not the data) and displays the times again. As I expected, the inode modification time changes, but not the file data modification time: Cambyses:~ prl$ touch x; ls -l x; ls -lc x; sleep 120; echo chmod; chmod 777 x; ls -l x; ls -lc x -rw-r--r-- 1 prl admin 0 3 Feb 10:33 x << Data modification time -rw-r--r-- 1 prl admin 0 3 Feb 10:33 x << Metadata modification time chmod << Change metadata -rwxrwxrwx 1 prl admin 0 3 Feb 10:33 x << Data modification time (unchanged) -rwxrwxrwx 1 prl admin 0 3 Feb 10:35 x << Metadata modification time (changed) Cambyses:~ prl$ This is on a HFS+ file system, so it does support different timestamps for file data and file metadata, and these are visible at least to the Unix interface to the system. The exact semantics of the fields may differ from native U*ix file systems, but the basic functionality is there. Example run on OS X 10.8.2, and on a HFS+ [MacOS Extended (Journaled)] file system. 1 Quote Link to comment Share on other sites More sharing options...
xvi Posted February 4, 2013 Report Share Posted February 4, 2013 prl: You're right, I was wrong! Quote Link to comment Share on other sites More sharing options...
dragonmac Posted February 6, 2013 Author Report Share Posted February 6, 2013 U*ix file systems have long had separate fields for last accessed (stat.atime) , last modified (stat.mtime), and metadata last modified (stat.ctime, inode changed time). IIRC those timestamps go right back to the Sixth Edition Unix file system (1975). The '-c' option to ls displays and sorts by the inode change time. The following commands create a file, display its modification (ls default) time and inode change time, waits 2 minutes, then changes the file permissions (which modifies the inode, but not the data) and displays the times again. As I expected, the inode modification time changes, but not the file data modification time: Cambyses:~ prl$ touch x; ls -l x; ls -lc x; sleep 120; echo chmod; chmod 777 x; ls -l x; ls -lc x -rw-r--r-- 1 prl admin 0 3 Feb 10:33 x << Data modification time -rw-r--r-- 1 prl admin 0 3 Feb 10:33 x << Metadata modification time chmod << Change metadata -rwxrwxrwx 1 prl admin 0 3 Feb 10:33 x << Data modification time (unchanged) -rwxrwxrwx 1 prl admin 0 3 Feb 10:35 x << Metadata modification time (changed) Cambyses:~ prl$ This is on a HFS+ file system, so it does support different timestamps for file data and file metadata, and these are visible at least to the Unix interface to the system. The exact semantics of the fields may differ from native U*ix file systems, but the basic functionality is there. Example run on OS X 10.8.2, and on a HFS+ [MacOS Extended (Journaled)] file system. Well this is my point exactly. You made the change via chmod which adjusted the POSIX permissions. What does an ACL change do? Where is that change made, to what part of the metadata? Why did Retrospect 8 under 10.4.11 ignore POSIX changes, and why does Retrospect 8 under 10.6.8 treat any ACL change NOT POSIX as if the file needs to be backed up again. This goes to the argument by other that the "Metadata modification time" changed so Retrospect makes a new copy but POSIX changed the "Metadata modification time" but never to my knowledge made a completely new backup of a file for only a POSIX permission change. Time Machine will not run under 10.4.x, so that test can't be performed. ... You will experience the same thing during the transition from 10.4.x to 10.6.y. I am using Retrospect 8 have been for years, under 10.4.11 previously and now under 10.6.8 which has Time Machine. I am testing an ACL change only, on a file tonight, and have a Time Machine test. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted February 7, 2013 Report Share Posted February 7, 2013 What does an ACL change do? Since control list settings are portable with the file (with the proper tools, moving a file brings the ACL settings along intact) I would assume that a change to the ACL is a change to the file. Where is that change made, to what part of the metadata? To the part of the metadata that you changed? Add a user, you've changed the part of the metadata that stores users? Why did Retrospect 8 under 10.4.11 ignore POSIX changes It didn't; Retrospect 5-8 maintained dynamic POSIX information for each file in the Catalog, allowing for a permission change to be held in proxy until the need for restore. and why does Retrospect 8 under 10.6.8 treat any ACL change NOT POSIX as if the file needs to be backed up again. Because Retrospect doesn't maintain dynamic ACL information in the Catalog, just as the Catalog file doesn't maintain other information dynamically. Perhaps doing so was impossible, or too difficult, or simply Not a Good Idea. If changing some or any or all ACL information in a file causes Retrospect to not "match" that file to what's stored in the Catalog then Retrospect will, by design, back that file up again. 1 Quote Link to comment Share on other sites More sharing options...
dragonmac Posted February 7, 2013 Author Report Share Posted February 7, 2013 It didn't; Retrospect 5-8 maintained dynamic POSIX information for each file in the Catalog, allowing for a permission change to be held in proxy until the need for restore. ... Because Retrospect doesn't maintain dynamic ACL information in the Catalog, just as the Catalog file doesn't maintain other information dynamically. Perhaps doing so was impossible, or too difficult, or simply Not a Good Idea. If changing some or any or all ACL information in a file causes Retrospect to not "match" that file to what's stored in the Catalog then Retrospect will, by design, back that file up again. Well I guess thats my answer if Retrospect 10 does not handle ACL in the catalog as it does POSIX? It should be done that way since a change to permissions is not a change to the data within the file. This being the case I would much rather have an option to turn off ACL modifications backup. If I had to restore files I would have to reset the ACL setting which is fine POSIX rules will be enough for me to know what is needed. This would really only be an issue with a massive restore. Knock on wood, I have not needed that, since I RAID all my data so drive failures are an easy fix now. Quote Link to comment Share on other sites More sharing options...
dragonmac Posted February 21, 2013 Author Report Share Posted February 21, 2013 Reply from Retrospect Agent Response: XXXXX contacted us and said that you have some questions about how Retrospect backs up files when permissions change. If the ACLs of a file change, Retrospect see that as a change in the file Meta data and Retrospect will want to re-copy the file. You can try changing one setting in Retrospect, that could reduce how often a file is recopied. http://kb.retrospect...uring-a-backup/ Thank you for using Retrospect, The Retrospect Support Team Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted February 21, 2013 Report Share Posted February 21, 2013 Reply from Retrospect Thanks for the info. It's good to know. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.