Jump to content
dragonmac

Retrospect and file permissions problem?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×