Jump to content

"partly" absolute paths


Recommended Posts

Hello,

 

we got 16 Mac OSX clients where we only want to duplicate the following directories:

 

~/Documents

~/Desktop

~/Library

 

Whereas from ~/Library some directories will be excluded (like Cache).

 

Unfortunately i couldn't find any hints (through google, documentation or this forum) on how to include/exclude "partly" absolute paths.

 

We have the users home dir (/Users/foobar/) as source (sub?)volume, and what ever i tried, it duplicated all occurances of Documents, and not just ~/Documents.

 

What can i do ?

 

cheers

Andre Schmidt

 

ps. with "partly" absolute paths i mean if source (sub?)volume is /Users/foobar, then /Documents would/should be a "partly" absolute path to /Users/foobar/Documents.

Link to comment
Share on other sites

Could you please describe the exact Selector and type of script you're trying to use? Also, while you're at it, what OS and Retrospect software are you using for your backup computer?

 

What do you mean when you say "it" "duplicated" "all occurrences" of "Documents?" The Selector matched? The Backup script copied? The Duplicate script copied?

 

By "Documents," do you mean all folders exactly named "Documents" or folders with "Documents" as part of the folder name, or just any kind of documents?

 

By "all occurrences," do you mean the Documents folders on subvolumes other than your intended source subvolume?

Link to comment
Share on other sites

>>Could you please describe the exact Selector and type of script you're trying to use?

Sorry, i didn't write down the selectors that did copy any occurances of "Documents", as none of them did what i wanted.

 

Do you know the selector rule that only duplicates the folder ./Documents in the subvolume (/Users/foobar) ?

 

>>Also, while you're at it, what OS and Retrospect software are you using for your backup computer?

Client: OS-X 10.4.9 (ppc) Retrospect 6.1.107, Server: OS-X 10.4.8 (ppc) Retrospect 6.1.126

 

>>What do you mean when you say "it" "duplicated" "all occurrences" of "Documents?" The Selector matched? The Backup script copied? The Duplicate script copied?

I mean any (selector) rule (used in a backup script) that was succesfull on duplicating anything, duplicated all occurances of "Documents" directory any where in the source subvolume (/Users/foobar).

 

>>By "Documents," do you mean all folders exactly named "Documents" or folders with "Documents" as part of the folder name, or just any kind of documents?

I just want to duplicate the folder ~/Documents, (eg. /Users/foobar/Documents, eg. ./Documents) and no other occurance of Documents directory anywhere else inside the source subvolume (/Users/foobar).

 

>>By "all occurrences," do you mean the Documents folders on subvolumes other than your intended source subvolume?

Sorry, i should have said "all occurances of directory named Documents inside the source subvolume". is it even possible to select files/dirs outside of the source subvolume ?

Link to comment
Share on other sites

Quote:

any (selector) rule (used in a backup script) that was succesfull on duplicating anything, duplicated all

 


 

Going forward, it would be helpfull if you kept your descriptive terms more inline with what you are doing.

"Duplicate" means something specific in Retrospect, which is not, from what I'm reading, what you are doing.

 

A Retrospect backup will "copy" files to the Backup Set.

 

> Sorry, i didn't write down the selectors that did copy any occurances

> of "Documents", as none of them did what i wanted.

 

That's a shame, as generally it's helpful in delayed, one-way, text based, community powered tech support to provide information about what you have already tried.

 

That being said, Retrospect on Mac OS X has never understood the concept of root; it remains a Classic Mac OS application at heart, and requires an absolute path to begin with the name of the volume.

 

You might want to define /Users/foo/ on each of your clients as a subvolume, and use those as your Source, then construct Selectos such as:

 

Enclosing Folder Path Name Does Match

foo/Documents/

 

Note the trailing forward slash.

 

Page 176 of the Retrospect User's Guide has more examples of path names in selectors.

Link to comment
Share on other sites

>Going forward, it would be helpfull if you kept your descriptive terms more inline with what you are doing.

>"Duplicate" means something specific in Retrospect, which is not, from what I'm reading, what you are doing.

sorry, i should have used "duplicate script"

 

>A Retrospect backup will "copy" files to the Backup Set.

i know, and im using "Duplicate". "copy" files from A to B

 

>That being said, Retrospect on Mac OS X has never understood the concept of root; it remains a Classic Mac OS application at heart, and requires an absolute path to begin with the name of the volume.

i never used the old mac os versions... but does this mean there are no plans on _upgrading_ to "OS X style" ?(like using ~/ to reach user home dir. ./ (or /) to reach the root of the source)

 

>You might want to define /Users/foo/ on each of your clients as a subvolume, and use those as your Source, then construct Selectos such as:

Enclosing Folder Path Name Does Match

foo/Documents/

i dont get the logic in here, if the source is "/Users/foo", why do i have to use "foo" in the path name ? its outside the source! (must be something with that old mac os you mentioned)

and if i try selector with "Users/foo/Documents/" that doesnt work, why ? (just curious)

 

well, this seems to work, but is there a better method ?

as with this method i would have to make an individual selector rule for every client ! (as the user names are not the same)

 

i just want to duplicate "/Users/<username>/Documents" dir on every client with one selector rule "script", is this possible with Retrospect 6.1 under Mac OS-X ?

Link to comment
Share on other sites

> i dont get the logic in here, if the source is "/Users/foo", why do i have to

>use "foo" in the path name ? its outside the source!

 

You didn't read my suggestion carefully. "...define /Users/foo/ on each of your clients as a Subvolume" makes "foo" the Source Volume. Paths need to begin with the Volume name (as noted in the manual, on the page referenced above).

 

You could do the same thing by defining /Users/ as your Subvolumes, then using "/Users/foo/" in the selectors, using the syntax suggested above.

 

The farther you drill down to define your Subvolumes, the less Retrospect has to work to scan the data you want to backup.

 

> i would have to make an individual selector rule for every client ! (as

> the user names are not the same)

 

Yep.

 

> just want to duplicate "/Users/<username>/Documents" dir on every client

>with one selector rule "script", is this possible with Retrospect 6.1 under Mac OS-X ?

 

Dunno. Probably not.

Link to comment
Share on other sites

Thinking about this further:

 

Quote:

we got 16 Mac OSX clients where we only want to duplicate the following directories:

 


 

You have not clearly stated exactly how you're trying to set this up. Duplicates in Retrospect are not as flexible as Backups are.

 

The Destination for a Duplicate in Retrospect has to be a volume. Do you have an individual folder on your secondary hard drive(s), defined as a Subvolume, for each of the 16 users?

 

The Source for a Duplicate in Retrospect can only be one Volume; so you'll need an individual Script for each of the 16 users.

 

So your desire to have a single Selector is moot; you need individual Duplicate operations for each user anyway. So making the slight modifications necessary for each script's selection criteria doesn't sound like too much of a hardship.

Link to comment
Share on other sites

ok,

 

ill try to go with this:

 

~/Library and ~/Documents as subvolume sources on every client

1 backup script for every client

1 selector script for all clients

 

thanks for the infos

.andre

 

ps. as we are growing rapidly, it would be very nice if i could just have a list of clients, and one backup script that would go through all the clients and backup to <clientname_username> backup file...

Link to comment
Share on other sites

Quote:

it would be very nice if i could just have a list of clients, and one backup script that would go through all the clients and backup to <clientname_username> backup file...

 


Hmm.. having that many backup destinations sound like a lot of work and, as Dave pointed out, Backups have significant advantages over Duplicates. (We only use Duplicates where we need to be able to retrieve and restore a file in Finder.)

 

For your consideration , here's what we find works best for us; YMMV:

 

We define specific client folders as subvolumes in Configure> Volumes. To limit backups to the subvolumes, we go to Configure> Clients and configure each client to back up "Selected Volumes," highlighting only the desired subvolumes.

 

(A word on using "Back up Selected Volumes" on the client: this preference applies only when the client "container" itself is chosen as the backup source. Choosing a specific volume on the client as the source overrides the "selected volumes" preference.)

 

To make script management easier, we have defined a number of source groups in the Volumes Database. Client aliases are added to a group simply by dragging the client name to the group.

 

We then use the groups as the sources for our various backup scripts. Using groups rather than adding clients individually simplifies the creation or modification of backup scripts, and ensures that new clients are automatically added to every script that they should be.

 

While restoring files from a backup does take a bit more time than copying them from a duplicate, we haven't found it especially burdensome, and for us, this slight downside is greatly outweighed by the advantages of having previous versions of backed-up files available and of speedier incremental backups.

Link to comment
Share on other sites

We define specific client folders as subvolumes in Configure> Volumes. To limit backups to the subvolumes, we go to Configure> Clients and configure each client to back up "Selected Volumes," highlighting only the desired subvolumes.

To make script management easier, we have defined a number of source groups in the Volumes Database. Client aliases are added to a group simply by dragging the client name to the group.

We then use the groups as the sources for our various backup scripts. Using groups rather than adding clients individually simplifies the creation or modification of backup scripts, and ensures that new clients are automatically added to every script that they should be.

 

thanks for the tip about "source groups", i somehow missed that completely blush.gif

 

While restoring files from a backup does take a bit more time than copying them from a duplicate, we haven't found it especially burdensome, and for us, this slight downside is greatly outweighed by the advantages of having previous versions of backed-up files available and of speedier incremental backups.

 

yup, restore (normally) doesn't come so often, so that indeed ain't so time consuming. (actually it seems pretty straight forward)

 

sadly i can (usefully) backup only one user per client with my "~/Documents and ~/Library" method, so i was wondering how do you backup user home dirs without getting "useless" data ? (like, do you backup ~/Movies, ~/Music, ~/Pictures etc... ?)

 

thanks again for the indeed helpful post(s)

.andre

Link to comment
Share on other sites

The best way to avoid backing up certain classes of files is to use a selector in your script.

 

You may find that Retrospect's "canned" selectors will work for you. We have found it better to write our own custom selectors, since, for example, our users have numerous important picture and sound files that need to be backed up, but we want to exclude certain others. You can duplicate an existing selector as a starting point and then modify it to suit your needs.

 

I tend to take the position that it's better to back up too much than too little. I do review our daily backup sessions, and when they seem unusually large, I check to see the reason, using the option to view the files sorted by size without the folder structure. That way I can see if we're backing up large files that don't need to be backed up, or that are being backed up more frequently than necessary, and modify the selector accordingly.

Link to comment
Share on other sites

well,

 

as we all (atleas i) now know that we can't exclude like "~/Library/Caches" but only _anything_ that contains "Library/Caches", the selector becomes pretty useless when trying to filter whole home dir. (i'm talking about 1 selector script for all clients)

 

and using a "regex" style include/exclude is slow as it still scans dirs that it wouldn't even touch when using "partly" absolute paths, no ?

 

AFAIK, the only "usefull" dir to backup is ~/Library, as all very important user made files are (should) allready be on the file server. backup of ~/Documents is just "luxus" for the users.

 

i just hope i dont have to backup more than one user per client in the future... if there ain't gonna be any "fix" for this in Retrospect under MacOSX (then again, i hope i'll be using rsync/tar in the futurecool.gif)

Link to comment
Share on other sites

Quote:

as we all (atleas i) now know that we can't exclude like "~/Library/Caches" but only _anything_ that contains "Library/Caches", the selector becomes pretty useless when trying to filter whole home dir. (i'm talking about 1 selector script for all clients)

 


As mentioned above, though, you can do what you want by defining a subvolume. Unfortunately, if you want to preclude excluding "Library/Caches" folders other than the ~/Library/Caches folders, you will have to do a subvolume for each username.

 

I guess that the only fix for this would be provision for a wildcard in the path name (subvolume of /Users, exclude all files whose pathname starts with "/Users/*/Library/Caches/"). Put in a feature request and hope that it gets implemented some time during the remaining life of the product. Because that's not something that is necessary to support changes in Leopard, it seems that it won't happen before this fall, if ever.

 

Russ

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...