folder to folder
 

I thought I was being SO smart…

I bought a 1TB drive over at Costco, thinking I would use it as backup. But I have three other drives, all accumulated over the years, and I use them all [one for itunes, one for startup, one for shared project files]. Maybe not the best setup, but that's what I have.

I figured I would back up each of these to a separate folder on the new mega drive.

Except I can't. SD doesn't support a folder-to-folder config, or if it does, I sure can't see how to do it?

Michael

Just partition the backup drive into three volumes, one for each source. Then, direct the backups as appropriate.

Thanks…I was looking for an answer that didn't require partitioning as predicting future size is not easy, but I think I can make this work.

Folder to Folder
 

Don't want to sound painful but I was hoping that SuperDuper would allow me to do this too, as you can in Silverkeeper.

I just want to be able to copy all of the stuff I want and instead of it being copied to an image file, I would just like to copy it to another folder on an external drive and to a fileserver on the network.

Is there no way this can be done?

Agreed. And painful. 'Just partition the drive' isn't a very good solution, for lots of reasons [although in fairness the OS ability to resize partitions deals with the worst of these, but adds a level of administration].

My experience with SD is this: I like it, I bought it, but every time I start to re-examine my backup strategy it is lacking in some important aspect. In this case, being able to copy folders to folders is a deal-killer.

I guess I should add that I find the descriptions of what it is going to do to be difficult to understand. I imagine a lot of time has been spent on this, but it's back to the drawing room, boys…

This is not something we support; sorry!

msadesign -- I encourage you to write into support with specific feedback on what you find difficult to understand. That's not feedback I get very often. Thanks.

I think the issue here is the mindset of the user not being understood by the developer. And as a professional designer, I am well aware of how hard it is to understand someone's way of thinking.

More to the point, the user approaches the software trying to solve a particular problem, and the subset of this is wanting to know what is going to happen with his files.

The rules aren't written with that sense, but this is a common pitfall. I've been beta testing a complex drawing package for many years through many iterations [www.engsw.com], published by a very small company. They certainly can't have someone drawing all the time, even though this would richen the program dramatically, and as a result you get lots of UI stuff that really talks more about the application than the user.

In the case of SD, I tried it, and finally bought it, partly out of desperation to leave Retrospect [company was smaller, too, to be fair, and we didn't need some of Retro's features], but largely on the recommendation of MacUser and MacWorld. As I look back on it from a place of years' reading both of those sites, I now know that those reviews and recommendations are based on cursory examinations.

Still, SD is robust at what it does. The biggest frustrations are two: first, knowing exactly what is going to be copied, and what won't be copied, and what will be deleted. This could simply be a list of files or folders or indeed even a typical, Finder-like window showing what happens. And the second frustration, the one starting this thread, is simple lack of flexibility; and on this point there is simply no compromise. Folder to Folder is a must at some point in SD's future.

In some ways, Carbon Copy Cloner tackles both of these points, although it is wrapped in too much jargon to be of use for the casual user, and has some other issues.

No, to me SD is about the easiest backup app to approach, other than Time Machine [and it is fair to say that in some ways TM has muddied the waters and has shifted user expectations by redefining what a backup actually IS and what to expect].

With SD the rub is this: have a look at the description of 'Copy Now', just as an example. Folks, I'm a very experienced Mac user, and I can tell you that there is too much information in that text. By the time I get to the second paragraph my eyes have glazed over and I am struggling to link what I just read in the first graf with the second.

This is what i mean by a better representation of the information, something other than text. A picture, a Finder window, or something; that's why you guys get the big bucks.

Along with all the other small publishers :-)

Michael
www.badlandscaping.com

On the issue of folder to folder 'not being something we do', I wonder why? how is this functionality in any way inconsistent with the design concept?

To me, this looks like a developer-decision based on his understanding of user needs. Fair enough. But I think you got it wrong in this case, that's all.

Michael

OK. Thanks for the feedback, it's appreciated.

I totally agree. I have just run into the pain of sparse images not automatically shrinking. I suppose I could add a before/after script to shrink it, but then I thought "Why can't I just have the backup go to a folder where the image is instead?"

I suppose I may see if I can trick the OS into mounting a folder and see if SuperDuper will see/backup to that.

If you guys aren't going to do Folder to Folder, well that's that, but is there a particular reason?

A sparse image acts like a 'local disk' and ensures that the capability of the destination can properly represent the source - things like ownership, permissions, ACLs, metadata, EAs, resource forks, etc are basically guaranteed to work correctly because they're represented as they are on a local volume. On top of that, the volume is 'rooted' correctly, which means it can be restored with anything, including Disk Utility.

Dave:

I appreciate you staying with me on this thread which is admittedly a little direct, although admiringly so. It just shows the confidence you have in SD.

But I'm not clear on how your previous response fits into the flow of the thread? Certainly I get the idea of a sparse disk and fully understand the point of using it. To me the issues I have with SD are not under the hood, where the app really shines. My points relate to the UI and feature set.

Michael

It answers the questions of why we use a sparse image in the case the user questioned. Note that Time Machine's "network" backups use a sparse image (or, rather, sparse bundle) for very much the same reason.

Backups directly from folder to folder weren't part of the initial mission of SuperDuper. That doesn't mean they'll never be included, but to generalize "your" needs to "all user needs", as you did above, isn't really a legitimate argument for the inclusion of a feature.

I'm pretty well acquainted with the "broad" user needs in this category. But I'm always open to listening to requests for other features -- sometimes I add them, sometimes not, depending on those broader needs (or perceived 'future' broad needs) and the utility/transparency of the feature.

So -- as I said, I appreciate the requests and suggestions: thanks.

opps. See you were responding to another post…doh.