An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Page 1 of 3 1 2 3
Using DU to Clone Lion to a APM firewire drive
#17504 09/20/11 02:19 PM
RHV Offline OP
OP Offline

Joined: Sep 2009
Using DU, I used to clone Snow Leopard on my intel iMac to a partition on my external APM formatted firewire drive. I also cloned Leopard from my PPC iMac to another partition on that drive. In both cases, I could restore from the firewire drive to the parent computer using DU.

I've got a third partition on the firewire waiting to take Lion. With Lion, "ought" the cloning and restoring to behave as before -- that is, given that I'm again using the APM formatted firewire drive? (I've googled but can't get confirmation from any using an APM external drive.)

I understand that with Lion I have to do the cloning and the restoring by going first to the new recovery "partition" in Lion (by holding down command-r). That's to be expected.

By the way, those using a GUID external drive report that while DU clones the recovery "partition", CCC and Super Duper don't.

Re: Using DU to Clone Lion to a APM firewire drive
RHV #17515 09/21/11 12:28 AM
RHV Offline OP
OP Offline

Joined: Sep 2009
Okay; so I'm impatient.

I tried to clone Lion on my Intel iMac to my APM external firewire using DU and the Recovery "partition" on my Intel iMac. DU said: No way Jose -- you have to have the GUID formatting on your external to use Restore with Lion.

I had worried about this -- hence my prior post.

So it looks like I need an additional drive to clone both my PPC Leopard and Intel Lion. Good thing drives don't cost much anymore. And if I wanted to use Time Machine for my two iMacs, wouldn't I also need two backup drives?

Re: Using DU to Clone Lion to a APM firewire drive
RHV #17516 09/21/11 12:39 AM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
The Time Machine backups aren't bootable, so it shouldn't be necessary to have a separately-partitioned drive for each.

I've heard, though I haven't verified, that Lion *will* boot from an Apple-partitioned drive, even though DU says you need a GUID-partitioned drive. Third-party cloning programs like Carbon Copy Cloner may be able to clone Lion to an Apple-partitioned drive.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Using DU to Clone Lion to a APM firewire drive
tacit #17520 09/21/11 12:59 PM
RHV Offline OP
OP Offline

Joined: Sep 2009
Thanks for that. I went over to the CCC forum. Mike B says there (in general terms -- not with respect to just Lion) that to clone a PPC and an Intel Mac to an external drive, two such drives are needed, one formatted as APM and one as GUID. I know that is wrong up to and including Snow Leopard -- at least it is wrong for DU as the cloning tool.

I posted a question there. So I'll look to see Mike B's answer.

I'm not clear about using Time Machine and one external for both my PPC and Intel Mac. I'd have to have, of course, two partitions on the external. But how should the external be formatted -- APM or GUID?

Re: Using DU to Clone Lion to a APM firewire drive
RHV #17521 09/21/11 03:46 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: RHV
Thanks for that. I went over to the CCC forum. Mike B says there (in general terms -- not with respect to just Lion) that to clone a PPC and an Intel Mac to an external drive, two such drives are needed, one formatted as APM and one as GUID. I know that is wrong up to and including Snow Leopard -- at least it is wrong for DU as the cloning tool.

I posted a question there. So I'll look to see Mike B's answer.

I'm not clear about using Time Machine and one external for both my PPC and Intel Mac. I'd have to have, of course, two partitions on the external. But how should the external be formatted -- APM or GUID?


I have yet to run into an intel that won't boot from an APS partitioned hard drive. There are some limitations, some real, some artificial:
1) you cannot run an intel firmware update while booted off a volume on an APS partitioned drive
2) you cannot select a volume on an APS partitioned drive using a Mac OS X operating system installer (the installer will lie and tell you that you cannot start off that volume)

I don't know why people keep spreading the misinformation that intels can't boot off APS partitions. I do it several times a day here. All my service drives are partitioned APS because I use them for both PPC and intel.

I'm certain at some point Apple will drop APS support from the boot firmware, but afaik they haven't done it yet.


I work for the Department of Redundancy Department
Re: Using DU to Clone Lion to a APM firewire drive
Virtual1 #17523 09/21/11 04:56 PM
RHV Offline OP
OP Offline

Joined: Sep 2009
Well, you're right -- as I found out this morning. I used the latest CCC to clone Lion to a partition on my external APM firewire. I could boot that partition.

The Recovery Partition is not copied. But so what if you've got a clone to copy back to the parent machine. And if you "really" want the Recovery Partition on the parent machine, you can reinstall the latest Lion there.

CCC is rather impressive. (I've never used it.) I have only 29 gigs on my Intel machine but CCC copied them in 15 minutes! And if I do the same clone in a week, CCC will copy just the new stuff. I'm going to have to give Mike B some money.


Re: Using DU to Clone Lion to a APM firewire drive
RHV #17535 09/22/11 03:22 AM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
CCC is definitely worth making donations for. I have used it personally and with my clients on countless occasions. I have a policy that any time I use it with a paying client, I always donate some money (again). It's a great piece of software that has saved my bacon several times.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Using DU to Clone Lion to a APM firewire drive
tacit #17558 09/23/11 05:05 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Free candy!

http://vftp.net/virtual1/temp/MFIF/Klone_2011.09.23.A.zip

let us know how this compares with CCC. wink


I work for the Department of Redundancy Department
Re: Using DU to Clone Lion to a APM firewire drive
Virtual1 #18663 10/23/11 05:00 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: Virtual1
Free candy!

http://vftp.net/virtual1/temp/MFIF/Klone_2011.09.23.A.zip

let us know how this compares with CCC. wink

Sorry I've been so slow to get to this.

The first thing I learned about Klone is that, unlike CCC, it does not permit cloning your boot volume.

So I booted into my 10.5.8 partition and...
  1. I erased the partition in which I store my clone.
  2. I cloned my boot volume using Klone.
  3. I erased the partition again.
  4. I cloned my boot volume using CCC.
Results (I've saved copies of Klone's Terminal window, CCC's log, and assorted disk usage info from Disk Utility in case you're interested in seeing it.):
  • Sat Oct 22 23:29:04 EDT 2011 Starting Klone...
  • Sat Oct 22 23:41:53 EDT 2011 -15584976 KB remains, 00:0-5:0-45:0-24 at 752 KB/sec current, 00:00:0-41:0-2 at 6329 KB/sec average

    Klone finished with return code 1, stopping scoreboard... Terminated
    logout

    [Process completed]
  • CCC: 10/22 23:59:51 Time elapsed: 00:09:51.
As you can see, Klone and CCC took 13 minutes (plus the time it took to boot into my Leopard volume and back into my boot volume) and 10 minutes (in total), respectively, to complete the same task.

I didn't boot into the Klone cloned volume to confirm this, but judging from volume sizes as reported in Disk Utility it looks like Klone maintained HFS+ Compression as does CCC.

Edit: I forgot to mention that my boot volume is about 5.5GB in size.

Last edited by artie505; 10/23/11 05:01 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Using DU to Clone Lion to a APM firewire drive
artie505 #18672 10/24/11 07:40 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
ditto will clone the booted volume, but you will need to use -X lest it try to copy /dev/* and /Volumes/* which will turn ugly.

I've had several "experts" tell me that they heard an expert somewhere say cloning/backing up a booted volume is a bad idea, but nobody could tell me why or provide anything more than hearsay to back up their words so I am ignoring them wink


I work for the Department of Redundancy Department
Re: Using DU to Clone Lion to a APM firewire drive
Virtual1 #18675 10/24/11 08:55 PM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
In theory, backing up a booted Unix volume is a bad idea because there are a large number of open files all the time on any Unix system, and it's long been considered bad form to attempt to copy an open file. On top of that, a Unix boot volume is unstable; it's constantly being read from and written to even when the computer is just sitting there.

In practice, well-behaved systems limit the file reads and writes, especially with temporary files or VM files, to well-known directories that can be excluded from the backup.

There are times when backing up a booted volume can lead you into trouble. For example, if you use Apple's Mail.app, it keeps incoming messages stored as files on the hard drive, and it indexes the mailboxes using a SQLite database that's always open for writing as long as Mail.app is running. Backing up the mailbox directories or the SQLite database at the moment mail comes in will result in a backup that isn't coherent, is missing some of the files, or both.

I make clones of my booted volumes all the time, but I make a point to ensure that no user-level applications are running when I do it.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Using DU to Clone Lion to a APM firewire drive
Virtual1 #18679 10/25/11 05:06 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
> I've had several "experts" tell me that they heard an expert somewhere say cloning/backing up a booted volume is a bad idea, [....]

If correct, wouldn't that put the kibosh on Time Machine backups?


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Using DU to Clone Lion to a APM firewire drive
tacit #18680 10/25/11 05:08 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
> I make clones of my booted volumes all the time, but I make a point to ensure that no user-level applications are running when I do it.

That's the route I've traveled since giving a moment's thought to the implications of cloning a volume while booted into it.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Using DU to Clone Lion to a APM firewire drive
artie505 #18684 10/25/11 05:53 AM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
Time Machine backups are a special animal. They don't back up operating-sysem-level files and aren't intended to be bootable, and they're more database entities than file-level entities.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Using DU to Clone Lion to a APM firewire drive
tacit #18686 10/25/11 06:17 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: tacit
Time Machine backups are a special animal. They don't back up operating-sysem-level files and aren't intended to be bootable, and they're more database entities than file-level entities.

Aaah! Thanks for the clarification.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Using DU to Clone Lion to a APM firewire drive
tacit #18697 10/25/11 10:00 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: tacit
I make clones of my booted volumes all the time, but I make a point to ensure that no user-level applications are running when I do it.

That's what I used to do, back in the days when I was backing up my MacOS 8.6 and earlier systems using Retrospect. Retrospect had the nice feature that, after copying all the files that had changed, it would go back and compare them with the copies. (They didn't do that right for a while: they'd just read back what they'd just written to see if they wrote it right, but that doesn't detect read errors. I got some very bad backups because of that. They eventually fixed it so that they copied all the files, then made a second pass comparing all the files, making sure they were reading everything from disk again and not just from cache.)

But when I went to OS X, I discovered to my dismay that "no user-level applications" wasn't nearly good enough. I was astonished at how much OS X does in the background, a lot of it with important files that really needed to be backed up. For a long time I made vain attempts to shut down more and more stuff, but it was becoming unwieldy to remember all the things that needed to be turned off, and increasingly problematic to remember to turn it all back on again after the backup. (At the least, you had to disconnect from the internet during the backup, because so many background processes are constantly updating files with information that becomes available online.)

I finally conceded that the only safe way to do it (and in practice the easiest way also) was to boot from a different volume. I never back up a running boot volume anymore.

Except with Time Machine. TM isn't perfect, but it knows it's backing up a running system, and goes to extraordinary lengths to mitigate the risks.

One thing it does is almost childish in its simplicity, but an effective stratagem nevertheless: it keeps all the backups. If one of them is bad, you can restore from another. This still isn't perfect (you need to know the backup is bad, you need to know which files to restore, etc.), but it was enough to justify giving it a chance to prove itself.

Another thing it does is that every time it does a backup, it does two backups in rapid succession, back to back. Each time it backs up, it backs up only the files that have changed since the last good backup, using the FSEventLog mechanism to find those changes very fast. Much much faster than the time it would take to look at every file to see if it had changed. (Other backup programs spend much more time figuring out which files have changed than they do actually copying them.) When it does that second backup, the "last good backup" is the first one, so the only files that have changed are the ones that changed during the copy phase of the first backup. (The first backup has already caught all the files that changed while it was evaluating what files had changed.) It only takes a few seconds to find and copy those, so the second backup is a consistent copy across the whole filesystem to within a few seconds. (This not only guards against single files changing at the time, but related files that need to be updated and backed up in a consistent state.) It's still not perfect, but the window for failure is getting narrower.

Some files it knows cannot be backed up. If it finds a disk image file that's currently opened read/write, it knows there's no way that file can be backed up. Instead, it punts, saying that the previous backup of that file is "good enough". (Stale data is better than bad data.) One way to look at that is, as far as TM is concerned, a disk image file doesn't actually change until it's closed, and it'll get backed up then.

Some it knows how to deal with. It knows what an sqlite database is, and backs it up in a consistent state even if it's being updated at the time. (How? Talk to the database gurus. Database designers have to deal with multiple simultaneous updates all the time, and many a doctoral dissertation has been written on each tiny aspect of that problem. TM just plays by the rules that SQLite sets up.) That means it gets a consistent view of your Mail data even if Mail is retrieving mail at the time.

During a backup, it uses an FSEvent stream to watch what files are being changed. It can detect a file that changes while it's being backed up, and knows the copy is no good. If it happens in the first pass, it puts that file in the list of things to copy in the second pass. If it happen in the second pass, it will either ignore the change (just like it does for disk images mounted read/write), or will sometimes mark the entire backup as bad, putting up an error alert to that effect. (I don't know how it decides which action to take. I've seen it do both.) No matter. The next backup, an hour later, will probably be good. Two hours between backups is still a lot better than any other backup method can strive for.

Is it perfect? Not if you believe in Murphy, but it's not shabby.

Re: Using DU to Clone Lion to a APM firewire drive
tacit #18706 10/25/11 02:16 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: tacit
Time Machine backups are a special animal. They don't back up operating-sysem-level files and aren't intended to be bootable, and they're more database entities than file-level entities.

The “aren't intended to be bootable” part is true enough (in the immediate sense), and easily overcome by installing an OS on the backup disk (assuming we're not talking about a NAS, which wouldn't be bootable with any backup software). However, the backups Time Machine produces certainly are intended to be bootable —once restored back to some disk.

Therefore, the “don't back up operating-sysem-level files” part may be a bit overstated. [or, i'm not sure exactly what you meant.] In either event, stuff that gets skipped by TM is generally considered to be expendable (though a few exceptions may be argued by some users).

$ defaults read /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions

Code:
{
    ContentsExcluded =     (
        "/Volumes",
        "/Network",
        "/automount",
        "/.vol",
        "/tmp",
        "/cores",
        "/private/tmp",
        "/private/Network",
        "/private/tftpboot",
        "/private/var/automount",
        "/private/var/folders",
        "/private/var/run",
        "/private/var/tmp",
        "/private/var/vm",
        "/private/var/db/dhcpclient",
        "/private/var/db/fseventsd",
        "/Library/Caches",
        "/Library/Logs",
        "/System/Library/Caches",
        "/System/Library/Extensions/Caches"
    );
    FileContentsExcluded =     (
        "/private/var/log",
        "/private/var/spool/cups",
        "/private/var/spool/fax",
        "/private/var/spool/uucp"
    );
    PathsExcluded =     (
        "/.DocumentRevisions-V100",
        "/.MobileBackups",
        "/MobileBackups.trash",
        "/.MobileBackups.trash",
        "/.Spotlight-V100",
        "/.Trashes",
        "/.fseventsd",
        "/.hotfiles.btree",
        "/Backups.backupdb",
        "/Desktop DB",
        "/Desktop DF",
        "/Network/Servers",
        "/Previous Systems",
        "/Users/Shared/SC Info",
        "/Users/Guest",
        "/dev",
        "/home",
        "/net",
        "/private/var/db/efw_cache",
        "/private/var/db/Spotlight",
        "/private/var/db/Spotlight-V100"
    );
    UserPathsExcluded =     (
        "Library/Application Support/SyncServices/data.version",
        "Library/Caches",
        "Library/Logs",
        "Library/Mail/Envelope Index",
        "Library/Mail/AvailableFeeds",
        "Library/Mirrors",
        "Library/PubSub/Database",
        "Library/PubSub/Downloads",
        "Library/PubSub/Feeds",
        "Library/Safari/Icons.db",
        "Library/Safari/WebpageIcons.db",
        "Library/Safari/HistoryIndex.sk"
    );
}


Re: Using DU to Clone Lion to a APM firewire drive
Hal Itosis #18712 10/25/11 05:33 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: Hal Itosis
stuff that gets skipped by TM is generally considered to be expendable

Not merely expendable, but in most cases stuff you wouldn't want to restore.
  • While a case might be made that log files might be useful for historical review, actually restoring a log file would constitute a loss of information.
  • Restoring temporary files would only create orphans; the application that originally created them has forgotten them, and won't use them even if they're restored.
  • A similar case can be made for cache files. In most cases the application that cached them has forgotten about them, and won't use them even if they're restored.
  • Restoring your virtual memory file would be disastrous, even if possible.
  • Your Spotlight database is actually a cache (in the sense that everything in it came from elsewhere and can be recreated if need be), but more importantly it's supposed to reflect what's on the disk volume now. Restoring your Spotlight database would break its contract, because you'd be setting it back to a reflection of what was on the disk volume then.
If it would be a mistake to restore a file, it's futile to back it up. Most of TM's exclusion rules are a consequence of this principle if futility, and not based on mere expendability.

It is true that some of the rules reflect expendability:
  • A case could be made for restoring log files as part of a whole-disk recovery, even though you'd never restore individual logs, but not a strong enough case to justify the expense of backing them up over and over again. Who ever looks a log files anyway? (Present company excluded.) They're nearly expendable as is.
  • Files in the trash have been explicitly marked as expendable by the user, but additionally they're probably redundant, having been backed up from wherever they were before they were put in the trash.

A few exclusion rules are for the sake of security. Backing up /Users/Guest would violate the contract that when Guest logs out all of its files are gone, gone, gone.

Some files that would be excluded for one of those other reasons could also be excluded for the sake of efficiency. Repeatedly backing up a large constantly changing file (like Outlook data) quickly becomes expensive enough, both in time and in the space it chews up in the backup, to make you feel that, even if the file is not expendable, hourly backups of it are. I think most user-defined exclusion rules are based on efficiency.

Of course, there's a lot of overlap. Your virtual memory file could never be restored, it's expendable, and backing it up would be a security breach as well as horrendously expensive. (It's also probably impossible to back it up even if you were so inclined.) A file that won't ever be restored must be expendable in some sense. The expense of backing up a file needs to be weighed against the cost of rebuilding it (or even of losing it).

But when I review TM's built-in exclusions, the most common basis I see is futility, not expendability. Don't back up what you're not planning to restore.

Re: Using DU to Clone Lion to a APM firewire drive
ganbustein #18736 10/27/11 03:00 AM
RHV Offline OP
OP Offline

Joined: Sep 2009
Originally Posted By: ganbustein
Originally Posted By: tacit
I make clones of my booted volumes all the time, but I make a point to ensure that no user-level applications are running when I do it.


That's what I used to do, back in the days when I was backing up my MacOS 8.6 ...
But when I went to OS X, I discovered to my dismay that "no user-level applications" wasn't nearly good enough. I was astonished at how much OS X does in the background, a lot of it with important files that really needed to be backed up. For a long time I made vain attempts to shut down more and more stuff, but it was becoming unwieldy to remember all the things that needed to be turned off, and increasingly problematic to remember to turn it all back on again after the backup. (At the least, you had to disconnect from the internet during the backup, because so many background processes are constantly updating files with information that becomes available online.)

I finally conceded that the only safe way to do it (and in practice the easiest way also) was to boot from a different volume. I never back up a running boot volume anymore.


Well, from the point of view of time, cloning by booting from a different volume is not the easiest way. The easiest way is to clone from the boot volume.

And, in my eight or so years of experience using Mac OS X's DU for cloning, up to Snow Leopard and now with Lion using CCC, cloning from the boot volume works just peachy fine. And I never bother to close down the internet connection either. Unlike Tacit, I don't bother to close down all the apps I've just been using. So what if Text Edit is open and so is Safari? Makes no difference.

After doing a clone, I always test it by booting from it for a test day. Never found a problem.

I'll happily and thankfully bow to Ganbustein if he can produce a good sized sample of competent Mac users who have had trouble cloning from the boot volume. Even better, if that sample was statistically significant. (Most samples aren't.)

But without some negative data on cloning from the boot volume, warnings against it are ... to put it politely ... just unsupported opinions. And they look really foolish to some of us empiricists who have been cloning from the boot drive for years without trouble.

Empirical data is what counts in everything -- wonderful theoretical opinions unsupported by empirical data are fun to contemplate and possibly the ringing bells for future improvements, but nothing to take seriously in their unsupported clothing.

As Ganbustein said elsewhere in these forums, let's get real.

Re: Using DU to Clone Lion to a APM firewire drive
RHV #18739 10/27/11 12:29 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: RHV
Well, from the point of view of time, cloning by booting from a different volume is not the easiest way. The easiest way is to clone from the boot volume.

And, in my eight or so years of experience using Mac OS X's DU for cloning, up to Snow Leopard and now with Lion using CCC, cloning from the boot volume works just peachy fine. And I never bother to close down the internet connection either. Unlike Tacit, I don't bother to close down all the apps I've just been using. So what if Text Edit is open and so is Safari? Makes no difference.

After doing a clone, I always test it by booting from it for a test day. Never found a problem.

I'll happily and thankfully bow to Ganbustein if he can produce a good sized sample of competent Mac users who have had trouble cloning from the boot volume. Even better, if that sample was statistically significant. (Most samples aren't.)

But without some negative data on cloning from the boot volume, warnings against it are ... to put it politely ... just unsupported opinions. And they look really foolish to some of us empiricists who have been cloning from the boot drive for years without trouble.

Empirical data is what counts in everything -- wonderful theoretical opinions unsupported by empirical data are fun to contemplate and possibly the ringing bells for future improvements, but nothing to take seriously in their unsupported clothing.

As Ganbustein said elsewhere in these forums, let's get real.

I don't recall seeing an 'RHV' back at the MacFixIt forums, but there were frequent threads there about unbootable clones. Same at macosxhints. Or —if the clones were bootable —the other fun thing that happened is that utilities like DU and DW would refuse to repair the original while booted from the clone. (which was one of the primary reasons for the clone in the first place... not mere backup, but a boot drive from which to repair the HD when things got borked up).

The main reason a cloned OS refused to repair a mounted original was that it somehow believed that it was still booted from the original. Some "link" seemed to exist between the two. [the clone operation had worked "too well" for such purposes.]

Tons of times i had to advise folks to **install** an independent OS for emergency booting. Booting into the same "exact" OS that we want to repair or restore is problematic.

For real.

Re: Using DU to Clone Lion to a APM firewire drive
Hal Itosis #18740 10/27/11 12:37 PM
Joined: Aug 2009
Likes: 7
Online

Joined: Aug 2009
Likes: 7
Originally Posted By: Hal Itosis
Tons of times i had to advise folks to **install** an independent OS for emergency booting. Booting into the same "exact" OS that we want to repair or restore is problematic.
I always use SuperDuper to clone my main drive and have never had a problem repairing it with either DU or DW when booted from the clone. I have never tried Ditto so I can't comment.


Jon

macOS 11.7.10, iMac Retina 5K 27-inch, late 2014, 3.5 GHz Intel Core i5, 1 TB fusion drive, 16 GB RAM, Epson SureColor P600, Photoshop CC, Lightroom CC, MS Office 365
Re: Using DU to Clone Lion to a APM firewire drive
jchuzi #18741 10/27/11 05:00 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
Originally Posted By: jchuzi
I always use SuperDuper to clone my main drive and have never had a problem repairing it with either DU or DW when booted from the clone.

Well... obviously if everyone had this sort problem, then i wouldn't need to mention it to anyone. But quite clearly such has not been the experience of 100% of all users. So if you want to take chances by having your only backup be the same OS which you rely on for emergency booting, be my guest... but that is not my advice in any case. An autonomous boot volume is always going to be more prudent (both for backup integrity and boot OS isolation).

Originally Posted By: jchuzi
I have never tried Ditto so I can't comment.

If you ever used Carbon Copy Cloner version 1 (back during Puma and/or jaguar), then you've tried ditto. It's actually a fantastic little command line utility, for backing up user folders and such. (but dealing with system files and making stuff bootable requires additional tools).

Last edited by Hal Itosis; 10/27/11 05:06 PM.
Re: Using DU to Clone Lion to a APM firewire drive
RHV #18742 10/27/11 05:30 PM
Joined: Aug 2009
Likes: 1
Offline

Joined: Aug 2009
Likes: 1
Originally Posted By: RHV
And, in my eight or so years of experience using Mac OS X's DU for cloning, up to Snow Leopard and now with Lion using CCC, cloning from the boot volume works just peachy fine. And I never bother to close down the internet connection either. Unlike Tacit, I don't bother to close down all the apps I've just been using. So what if Text Edit is open and so is Safari? Makes no difference.


With those two programs in particular, you're unlikely to have problems. A TextEdit file that's open isn't held open for writing on the disk; the only way you'll have an issue is if you save that file at the exact moment it's being cloned, which is unlikely. Having Safari open while you clone may result in the Safari cache files on the clone being a bit scrambled, but that's no big deal.

Other programs are more problematic. Some programs, including Mail and iPhoto, use SQLite databases. Carbon Copy Cloner doesn't know how to deal with these in a coherent way; it just treats them as files. If you're cloning your Mail database while new email is arriving, or cloning your iPhoto database while you are importing, tagging, rearranging, rating, scanning for faces, or sorting photos, you may end up with a clone that has a scrambled database. This isn't too big a problem in Mail--there are ways to force it to rebuild mailbox indexes--but in iPhoto, your library may be unreadable and have to be rebuilt. I've seen this happen. Rebuilding an iPhoto library is not easy, and you lose all your album names, ratings, tags, and faces.

Originally Posted By: Hal Itosis
I don't recall seeing an 'RHV' back at the MacFixIt forums, but there were frequent threads there about unbootable clones. Same at macosxhints. Or —if the clones were bootable —the other fun thing that happened is that utilities like DU and DW would refuse to repair the original while booted from the clone.


I haven't seen that problem, and I'm a bit mystified how it could happen. The only way I can see for such a thing to happen is if the clone were still referencing files on the original, via aliases or symlinks or some other mechanism, and as a result the original drive still had open files. That's a problem that's not necessarily related to cloning per se.

Certainly I've never experienced that problem. I've been using tools like CCC to clone active boot volumes for many years, and have probably at this point done it literally thousands of times (not only on my own systems but on clients' systems as well) without problem.


Photo gallery, all about me, and more: www.xeromag.com/franklin.html
Re: Using DU to Clone Lion to a APM firewire drive
Hal Itosis #18743 10/27/11 05:46 PM
Joined: Aug 2009
Likes: 1
Moderator
Offline
Moderator

Joined: Aug 2009
Likes: 1
Like Jon, I have always used SD to clone my main boot volume while that was running. Never a problem. That said, (and with the occasional exception of a safe boot) I follow the manual's recommendations.
While stating that this is not strictly necessary, the SuperDuper! manual recommends in Step 1: Prepare for your backup to quit all running applications, and perhaps even do a safe boot into the volume to be cloned. Final note: I am NOT running Lion, but Leopard (PPC Mac).


alternaut moderator
Re: Using DU to Clone Lion to a APM firewire drive
alternaut #18745 10/27/11 08:11 PM
Joined: Sep 2009
Offline

Joined: Sep 2009
For the record: I never had any clone problems either. cool (those few i bothered to test anyway)

But i did help [and/or read about] dozens who did have problems. If y'all want to wander the MFI archive and dig up some old threads, maybe you can explain what actually went wrong. wink [tacit is basically right... and like i said: there was some "linkage" in the clone which made the utility believe it was booted from the same disk it was supposed to repair. No one has ever figured out how exactly that happened (e.g., it's this symlink in /usr/bin or wherever), so no one ever "fixed" whatever it was, nor can anyone predict when it might happen to them.]

Meanwhile, i don't see any need to take a chance, when avoiding the potential issue requires only a basic partition/install.

The SuperDuper philosophy is this: backup... and when the HD fails, you can boot from that backup and "get back to work immediately" (meet deadlines, etc). And that's fine... unless this bug bites (or perhaps if your backup has a "backup" of the same problem).

Page 1 of 3 1 2 3

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.034s Queries: 64 (0.026s) Memory: 0.7367 MB (Peak: 0.9271 MB) Data Comp: Zlib Server Time: 2024-03-29 01:10:30 UTC
Valid HTML 5 and Valid CSS