Loading Profile...
Recent activity
Subscribe to this feed
Mike Bombich replied on March 09, 2010 03:00 to the question "What kind of performance can I expect from CCC?" in Bombich Software:
300GB in a couple hours isn't too far off for most consumer hard drives available right now. In some tests that I did a few months ago, I was copying about 120GB of data in an hour and 20 minutes (internal SATA drives, Mac Pro, Snow Leopard), so about 1.5GB/minute. You're getting about 2.2GB/minute, which is actually pretty good. If you want better speed than that, you'll have to invest in more spindles (hardware RAID) or Flash-based storage.
Performance will be worse for smaller hard drives (e.g. physically smaller, like those in laptops), for older hard drives, and for hard drives that are nearly full and thus more likely to be fragmented. You'll also get longer copy times when you have lots of small files vs. a volume filled with just a few very large files. Finally, you'll see better performance with faster/more efficient interfaces -- eSata is faster than Firewire, Firewire is faster than USB (FW800 is faster than USB 2.0, USB 2.0 may be slightly faster than FW400).-
Mike Bombich asked a question in Bombich Software on March 09, 2010 03:00:
What kind of performance can I expect from CCC?Good gravy, Carbon Copy Cloner is slow. 2.25 hours in and not even 300GB copied (internal to internal) -
Mike Bombich started following the idea "Custom forms, or something similar?" in Get Satisfaction.
-
Mike Bombich replied on March 09, 2010 02:16 to the question "MBP fails to boot / Apple logo changes at startup (cloned drive)." in Bombich Software:
It sounds like your target disk may not have been properly formatted or partitioned. Take a look at this section of the documentation that refers to preparing your target disk for use with CCC. If you did properly prepare it, and you can verify that the partitioning scheme is correct (GUID/GPT), then it could be that the volume is not properly blessed. Re-running CCC with the same settings should clear that up.
The last thing I'd look for is details about your hard drive and its enclosure. I offer some details on what makes a volume bootable here in the documentation (scroll down to "Bootability Verification"), perhaps something there will help you get to the bottom of this.
Mike -
Mike Bombich replied on March 08, 2010 04:46 to the problem "CCC v 3.3.1-b3: Postflight problem" in Bombich Software:
Hi Ton:
CCC isn't doing anything after the postflight script, it's just including the postflight script under an umbrella of coverage for "target disappeared" notifications. This is actually a bug fix for 3.3.1. In earlier versions of CCC, failure to abruptly stop the backup task when the target vanishes could lead to copying data to a hidden folder on the root volume and issues with properly remounting the target volume.
I can certainly see an argument for excluding postflight tasks from this umbrella of coverage, but I have some other concerns about doing that in this current version (to do that well would require some significant changes that I'm not planning to make for this minor bug-fix release).
In your script, it should work to delay the unmount and send that task to the background. For example:
#!/bin/sh
sleep 5 && umount $1 &
That script would return immediately, CCC would finish its business, then a few seconds later the umount command (spawned to its own process) would unmount the target drive.
Mike -
Mike Bombich replied on March 08, 2010 04:30 to the question "How could I copy CCC pre-configured to several Macs?" in Bombich Software:
You could try distributing the scheduled task configuration files that are stored in /Library/LaunchDaemons, but that may not work. CCC stores the universally unique identifier of your source and target volumes and uses that identifier to confirm that it is uses the correct source and target volumes. This prevents mishaps that might occur if you had two volumes named "Backup" ("Macintosh HD" is a very popular volume name too). Check out the "Additional Settings" section of the Scheduler chapter of the CCC documentation for more details on working around this. -
Mike Bombich replied on March 08, 2010 04:24 to the question ".dmg decompress and install , using what ?" in Bombich Software:
Hi Maurizio:
You don't have to manually decompress the disk image, you simply mount it in the Finder by double-clicking on it. Alternatively, you can restore the contents of the disk image using CCC. That topic is covered here in the documentation.
Mike -
Mike Bombich replied on March 08, 2010 04:18 to the question "Deleting old CCC incremental backup folders" in Bombich Software:
Yes, you can delete those directories. You're right about what they contain, they're whatever items had changed or had been removed from the source. Once you're confident that you aren't going to need an older version of a particular file, or a file that you deleted, then it's safe to remove the older archives. A future version of CCC will offer an interface for managing those archives, but for now you just have to clear some of them out every couple months or so.
Mike -
Mike Bombich replied on March 08, 2010 04:14 to the problem "Errors after recent update. Scheduled items no longer working." in Bombich Software:
Hi wadedansby3:
Two things to try:
1) Clear out the privileged helper tool and its configuration
a) In the Finder, navigate to /Library/LaunchDaemons and toss the "com.bombich.ccc.plist file to the trash (you can leave the scheduled task item in place).
b) Navigate to /Library/PrivilegedHelperTools and toss the com.bombich.ccc file to the trash.
c) Restart your computer. (I don't usually like to recommend this because I don't like to restart my own computer. In this case, I'm not confident that the main system scheduler, launchd, has properly registered the helper tool's configuration file, which is something it will only do on initial installation or on a restart)
2) Enable debug logging in CCC's help menu, try the task again, then resubmit your logs via the Help menu > Report a problem > Submit Logs tab (no need to submit another report).
I'm confident we'll have your rsync/mknod issues resolved once we get this worked out too :-)
Thanks,
Mike -
Mike Bombich replied on March 06, 2010 03:54 to the question "can i clone a raid 5 disk" in Bombich Software:
Yes, that should work fine as long as it is formatted HFS+ (I've tested it). CCC acts at the volume level, so whatever hardware you have underneath that filesystem doesn't typically matter. -
Mike Bombich replied on March 06, 2010 02:43 to the idea "Can you change the name of a volume after tasks are saved?" in Bombich Software:
Hi Harvey:
Being able to load a scheduled task back into the Cloning Console to make edits is on my to do list. Thanks for the bump!
Mike -
Mike Bombich replied on March 06, 2010 02:40 to the question "rying to retrieve files from a broken HD onto a new drive." in Bombich Software:
Hi Jason:
I sorry to hear about your bad luck. If the drive doesn't actually mount, CCC won't be able to help recover files from the disk. I offer some advice to people dealing with dead/dying hard drives in this section of the documentation. If it's really dead, though, you'll have to look at something like Drive Savers for physical data recovery.
Good luck!
Mike -
Mike Bombich replied on March 06, 2010 02:31 to the question "incorrect permissions after clone" in Bombich Software:
Hi BiL:
First, save yourself some time by not erasing the target disk. As long as you use the "Delete items from the target that do not exist on the source" option, CCC will copy only the items that have changed and delete whatever doesn't belong. The end result should be two identical volumes. Over the lifetime of your hard drives, you'll put less wear and tear on them with this method.
On the permissions issue, can you post what the ownership and permissions are on your Applications folder? The defaults are owner:root, group:admin, owner:Read & write, group: read & write, other: read only. Or what you'd see in the Terminal:
ls -la /Applications
drwxrwxr-x+ 69 root admin 2346 Jun 25 2009 .
The method you're using sounds fine, I wouldn't expect any permissions problems. That said, what settings did you use in CCC?
As for the Adobe updater, I've heard a few reports of Adobe apps misbehaving when the cloned volume boots another Mac. Do these issues occur when you use the cloned volume to boot the source computer?
Thanks,
Mike -
Mike Bombich replied on March 05, 2010 23:12 to the question "Cloning Multiple Partitions on Remote Macintosh?" in Bombich Software:
CCC clones volumes, not whole disks. To get the other partition, you'll have to indicate that partition's mountpoint (e.g. /Volumes/Other Disk) in the Remote Settings dialog. -
Mike Bombich replied on March 05, 2010 15:20 to the question "remove old Authentication Credentials" in Bombich Software:
On the source machine, the Authentication Credentials Installer installs the "keys" to /var/root/.ssh/ (the files are named "ccc_dsa" and "ccc_dsa.pub"). On the source, these files are harmless and don't permit access to anything on the local machine, so there's no harm in leaving them there. For posterity, though, you would remove them by pasting this command into the Terminal application:
sudo rm /var/root/.ssh/ccc_dsa*
On the remote Macintosh, the Authentication Credentials Installer edits /var/root/.ssh/authorized_keys to include the contents of the ccc_dsa.pub key from the source machine. This command in the Terminal application will remove any entries added by CCC:
sudo perl -n -i -e 'print unless /= CCC_/' /var/root/.ssh/authorized_keys
A future version of CCC will have a better methodology for establishing (and un-establishing) trust between the two machines, it just isn't something I've gotten to yet.
Mike -
Mike Bombich posted a topic that has since been removed from Bombich Software. see the change log
-
Mike Bombich replied on March 04, 2010 19:07 to the problem "CCC cloned to a folder in /Volumes rather than to the disk itself" in Bombich Software:
We call this a "Ghost" clone, and it's a tricky issue to resolve because there are several different ways that it can happen. What you described, however, sounds like a scenario that I should be handling appropriately.
Cleaning up the ghost clone is easy:
1) Unmount any externally-attached hard drives and physically disconnect them from your computer
2) Choose "Go to folder" from the Finder's "Go" menu
3) Type "/Volumes" and hit return
4) Find the folder that is named for the volume you thought you were cloning to and toss it in the trash (you may be prompted to authenticate). Once you empty the trash, your disk space will be back.
I'm sorry this happened, and I want to figure out how to prevent it from happening again. Can you please email your CCC.log file to me (mike@bombich.com)? It is located at /Library/Logs/CCC.log. For privacy reasons, we ask that you do not post the log file here.
Thanks!
Mike -
Mike Bombich posted a topic that has since been removed from Bombich Software. see the change log
-
Mike Bombich replied on March 03, 2010 15:00 to the question "Does CCCloner do incremental backups?" in Bombich Software:
Yes, CCC does incremental backups. That's actually the default behavior -- if your target drive already has some data on it that matches that on the source drive, CCC won't recopy it, it will just update the items that need to be updated. This section of the documentation covers this in complete detail if you want more information before running CCC.
Mike -
Mike Bombich asked a question in Bombich Software on February 28, 2010 03:05:
Can I schedule a backup task to an encrypted disk image with CCC?I am occasionally asked about scheduling backup tasks to encrypted disk images. This isn't something that is currently supported in CCC, though I am investigating ways to make this possible without compromising convenience or security. Here are some of the concerns involved.
To mount a disk image you must first provide some sort of authentication. The typical user experience on Mac OS X is to either provide your encryption key when prompted, or to save the key in the keychain. This presents a logistical challenge for a utility that runs in the background, as the root user, and at times when no user is even logged in. There are a few approaches I could take, but they all reduce the security of your encrypted disk image or reduce the automation of the backup process:
1) You could store the encryption key in the Keychain and I could access that keychain programatically. This would be fine as long as a) the correct user is logged in and b) the keychain is unlocked, or a user is present to unlock the keychain when prompted.
2) I could prompt the user sitting at the keyboard to provide the disk image's encryption key. This would work fine, but would only work if a user is logged in (and the right user, at that), and would reduce the level of automation in the backup procedure.
3) I could store the encryption key in a proprietary encrypted form in the scheduled task configuration. Because CCC would need to have the key to encrypt the dmg's encryption key, this would essentially amount to "security through obscurity".
In the current version of CCC, you can schedule a backup task to a mounted, encrypted disk image, and schedule it to run whenever the target is reconnected to the computer. CCC will run the backup task when you mount the disk image, so all you have to do to initiate periodic backups to your encrypted disk image is to mount it manually.
Mike
| next » « previous |