|
#1
|
|||
|
|||
Restoring to a folder
I want to back up a small(~14GB used) volume, then restore its contents to a folder. Unless I'm mistaken, there is no way to restore to a folder when using SuperDuper.
Do I have any better options than backing up to an image, mounting the image and then copying the contents of that image into a folder? Using the Finder to then copy tens of thousands of files seems very unpleasant. Is there some nice little terminal command or utility that would be a better choice for this copy? Is there some nice little terminal command or utility that would be able to read directly from the disk image file and copy into a folder I designate? |
#2
|
||||
|
||||
Why are you trying to store its contents in a folder, Eric? Would a sparse image suffice, since it can be opened and managed like any other volume?
If you're just going to copy out of the image into a folder, you could do the *whole* operation with Finder... but since you probably can't authorize to copy that much data, it's unlikely to work...
__________________
--Dave Nanian |
#3
|
|||
|
|||
There are several issues embedded in my comment.
First, to reply: It is not that I want to "store" the contents of a disk image in folder. I want to REstore a disk image TO a folder. Currently, we can backup volumes to images and folders to images. And we can restore images to volumes. But we cannot restore an image to a folder. Realize than an image will not always contain a bootable volume: it may contain only a folder (a collection of files), just a single very large file, a data-only volume, etc. I realize I can open an image and use the Finder to copy everything (or pick and choose) to another location. That will often be useful, but also is not what I'm looking for. I really do not want to have to rely on the Finder to copy these files. And I'd prefer to not even let the Finder see the files before they appear in my target folder. (I don't want Spotlight or some other "service" grabbing for things on a mounted image.) Also, there may be invisible files on the image. A mounted image will not show those files in the Finder, and therefore they cannot be selected for copying. For another thing, I want all the file information preserved during the process. I do not want permission settings or modification dates of the files changing, for instance. It's also difficult to believe that the Finder is going to be very efficient copying thousands and thousands of files. And how good it its validation checking? As I say, I'd prefer a solution that will restore the contents of a disk image file to a folder (without needing to mount that image). As a second choice I'll settle for mounting the image and using a command or tool in the terminal to do the copy task. Which one(s) will preserve all the "Macintosh stuff" in files? In your reply you wrote "...but since you probably can't authorize to copy that much data...." I've never heard of this sort of limit. Are you saying that the Finder will refuse to copy more than a certain number of files at a time?? In case anyone wonders why I would want to keep a collection of file in a disk image (instead of simply in a copy of the folder), it is because in an image the files are "hermetically sealed." I can safely have a disk image visible to my file system without exposing its contents to the file system. I won't mistakenly begin working inside my "backup" folder, iTunes or iPhoto or Spotlight or WHATever will not notice the contained files and feel bound to do something with them, etc. Also, again, the image should be an exact copy of my files, not the simply the Finder's idea of what the current user can see or do. |
#4
|
||||
|
||||
First, I used the wrong term -- sorry. I didn't mean "much" in quantity terms, I meant for permissions -- trying to copy a whole system, and authorizing against the whole thing.
But, regarding the rest -- sorry. We can't do that... and even if we could, they'd be seen by Finder anyway, since you'd have to mount (or we would)... and Spotlight sees the files as soon as they hit the file system, since that's all done with kqueues. Block restore -- the only real way to avoid mounting -- couldn't be done to a folder either, because it happens at far too low a level. You'd have to replace the *entire* drive with the restoration... and then it gets seen, and indexed. Etc. So, unfortunately, we don't look to be the solution to your needs. Sorry, Eric!
__________________
--Dave Nanian |
#5
|
|||
|
|||
Quote:
Quote:
Quote:
*sigh* Not exactly one-stop shopping. |
#6
|
||||
|
||||
Well, you can reach inside an image and pull files out, but since it's a volume like any other, it gets mounted and used. The *advantage* to an image is that it's just like any other volume, and restoration is easy. You have rather unique requirements here, which is why it seems to be a problem... but I truly don't understand the problem with "exposing" the files to the file system, because it can't really do any "harm"... what could possibly happen?
__________________
--Dave Nanian |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Copy Script for Applications folder? | Pisces | General | 7 | 07-06-2005 11:04 AM |
problems restoring from image | lpn | General | 5 | 06-27-2005 04:08 PM |
Image restore ends with an error | adamd | General | 3 | 06-22-2005 09:50 AM |
safety clone and utilities folder | camner | General | 1 | 05-20-2005 07:06 AM |
Backup folder to folder | mortenosx | General | 1 | 04-30-2005 05:42 PM |