 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Applications / Mac Applications / October 2006Disk images as HD backups?
I've gotten a bit weary of the complexities and long execution times of Retrospect backups -- even incremental backups seem to involve a very long scanning time -- and am thinking of converting to weekly disk image (.dmg) backups instead. Are there any serious downsides to just creating a weekly disk image copy of the entire contents of the HD in my iBook G4 OS 10.3.9 laptop (which contains about 27 GB at present) on a 40 GB FireWire pocket drive as part of my backup strategy, along with a daily SuperDuper! Smart Copy bootable backup on another pocket drive? I realize neither of these are "archival" -- but would the disk image be bootable? Or would it require moving the pocket drive to another Mac which already has a working system? Could any experts out there scribble down a quick AppleScript which would delete the old disk image file, create the new one, and unmount the pocket drive each time I invoke it? Thanks for any counsel. In comp.sys.mac.system AES <siegman@stanford.edu> wrote: > Are there any serious downsides to just creating a weekly disk image > copy of the entire contents of the HD in my iBook G4 OS 10.3.9 laptop > (which contains about 27 GB at present) on a 40 GB FireWire pocket drive > as part of my backup strategy, along with a daily SuperDuper! Smart Copy > bootable backup on another pocket drive? No. > I realize neither of these are "archival" -- but would the disk image be > bootable? Probably. That depends on the drive. > Could any experts out there scribble down a quick AppleScript which > would delete the old disk image file, create the new one, and unmount > the pocket drive each time I invoke it? You can just have the backup app erase the disk first. Billy Y.. > In comp.sys.mac.system AES <siegman@stanford.edu> wrote: > [quoted text clipped - 16 lines] > > You can just have the backup app erase the disk first. And *that* is when your main hard drive bearing chooses to seize up. Remember -- things hate people. Isaac > I've gotten a bit weary of the complexities and long execution times of > Retrospect backups -- even incremental backups seem to involve a very [quoted text clipped - 10 lines] > bootable? Or would it require moving the pocket drive to another Mac > which already has a working system? Disk images are *never* bootable. They are file objects and hence, require a file system, with its attendant operating system to mount them. Those facilities are available only after a successful startup. However, one can make an image of a bootable disk and once restored to a physical disk, the result will be bootable. [request for script snipped]  SignatureTom Stiller PGP fingerprint = 5108 DDB2 9761 EDE5 E7E3 7BDA 71ED 6496 99C0 C7CF > I've gotten a bit weary of the complexities and long execution times of > Retrospect backups -- even incremental backups seem to involve a very [quoted text clipped - 16 lines] > > Thanks for any counsel. I use Retrospect too, and I seriously doubt that it would be slower than copying the entire 27 GB of your hard drive to a disk image. SignatureJohan W. Elzenga johan<<at>>johanfoto.nl Editor / Photographer http://www.johanfoto.nl > I've gotten a bit weary of the complexities and long execution times of > Retrospect backups -- even incremental backups seem to involve a very [quoted text clipped - 15 lines] > > Thanks for any counsel. I use SuperDuper on my 15" MacBook Pro. I used CCC earlier on but it was too flaky for my taste. SuperDuper is a great Mac application 'It just works!'. I do weekly disk backups. Retrospect is very good and it gives you the ability to pick up changed files along the way so you can restore to a date. It remains to be seen how timemacine in leopard will fit into this mix but for now SuperDuper does it for me. A satisfied customer. SignatureRegards, John [commenting on using SuperDuper! for backups] > I do weekly disk backups. Weekly! I guess I'm paranoid in that I do two SuperDuper! backups each night one to each of two different hard drives. I would find it exceedingly upsetting to have to go back to where I was a week ago. SignatureJames Leo Ryan ..... Austin, Texas ..... taliesinsoft@mac.com > [commenting on using SuperDuper! for backups] > [quoted text clipped - 3 lines] > one to each of two different hard drives. I would find it exceedingly > upsetting to have to go back to where I was a week ago. Well, if you code or work on photos or video projects every day I can understand. Me, I fire up my Mac every couple of days to add stuff to iTunes or to work on photos so it wouldn't kill me to go back a few days. And there is no way I'm backing up twice a night. Greg Signature"All my time I spent in heaven Revelries of dance and wine Waking to the sound of laughter Up I'd rise and kiss the sky" - The Mekons [responding to stating that I run two backups each night as I wouldn't want to lose more than a day's worth of work] > Well, if you code or work on photos or video projects every day I can > understand. Me, I fire up my Mac every couple of days to add stuff to > iTunes or to work on photos so it wouldn't kill me to go back a few days. > And there is no way I'm backing up twice a night. The backups are automatically run in the middle of the night when I'm comfy in bed and most likely asleep. SignatureJames Leo Ryan ..... Austin, Texas ..... taliesinsoft@mac.com > I've gotten a bit weary of the complexities and long execution times of > Retrospect backups -- even incremental backups seem to involve a very > long scanning time You realize that it's the _fact_ of creating incremental backups that requires the long scan, I hope. The scan is to determine what files have changed since the last backup. Which means looking at the directory entry for every file on every volume that's scheduled for backup. > -- and am thinking of converting to weekly disk image > (.dmg) backups instead. [quoted text clipped - 4 lines] > as part of my backup strategy, along with a daily SuperDuper! Smart Copy > bootable backup on another pocket drive? The biggest problem is that you lose the trail. The value of incremental backups is that they let you go back to any of several previous points in the life of a document. G SignatureWhat I write is what I mean. I request that anyone who decides to respond please refrain from "disagreeing" with something I didn't write in the first place. >> I've gotten a bit weary of the complexities and long execution times of >> Retrospect backups -- even incremental backups seem to involve a very [quoted text clipped - 4 lines] > changed since the last backup. Which means looking at the directory > entry for every file on every volume that's scheduled for backup. Well, if Dantz was a better vendor, they would probably already have fixed this issue for Macs running Tiger. Now that Spotlight has arrived, generating a list of all files modified since a particular point in time should be a simple query to the spotlight index. Full scans would still be required for any volume that contains any folders in the "Privacy" mode. >> -- and am thinking of converting to weekly disk image >> (.dmg) backups instead. [quoted text clipped - 8 lines] > backups is that they let you go back to any of several previous points > in the life of a document. And, as noted already, if you choose to do full clones, and erase your only copy before making a new backup, you are seriously at risk of finding out about "soft" data corruption during the copy. It is quite possible for disk problems to "hide" in unread portions of the drive until it comes time to read that portion. 27GB cloned to a 40GB external definitely fits that scenario. But this problem actually applies to all backup solutions - it's just that the "delete, then clone" cycles more frequently than the "base dump, then inc, inc, inc, inc, inc, ..., reset new base dump". Two alternating backups (either clone or traditional base+inc) fixes this problem, but at a significant additional cost of backup space/media. I still use Retrospect, because 1) it allows me to go back to previous versions of files, and 2) because it allows me to back up all my systems (Mac, PC, and Linux) on a single server. For multiple networked systems, I think an automated network backup like Retrospect is the only way to go. Even for single systems, the choice between cloning and Retro isn't clear, since you can get Retrospect Express bundled with external hard drives and internal or external DVD-RW drive for practically free from www.macsales.com. > >> I've gotten a bit weary of the complexities and long execution times of > >> Retrospect backups -- even incremental backups seem to involve a very [quoted text clipped - 6 lines] > > Well, if Dantz was a better vendor, Note that it's only nominally Dantz any more. It's now EMC.... > they would probably already have > fixed this issue for Macs running Tiger. Now that Spotlight has arrived, > generating a list of all files modified since a particular point in > time should be a simple query to the spotlight index. It's not. A. Spotlight's not reliably available for their customer base, and more importantly B. Spotlight's not reliably functional among the subset of their customer base for whom it is available. So there's not really much incentive for them to do so. > But this problem actually applies to all backup solutions - it's just > that the "delete, then clone" cycles more frequently than the "base > dump, then inc, inc, inc, inc, inc, ..., reset new base dump". Two > alternating backups (either clone or traditional base+inc) fixes > this problem, but at a significant additional cost of backup > space/media. True. It always comes down to deciding how much your data is worth to you. With 500GB FW drives now readily available for under $300, and 250GB drives available for under $100 to those who invest a little time I think the cost is rapidly losing significance. > I still use Retrospect, because 1) it allows me to go back to previous > versions of files, and 2) because it allows me to back up all my systems > (Mac, PC, and Linux) on a single server. Ditto, on both counts. G SignatureWhat I write is what I mean. I request that anyone who decides to respond please refrain from "disagreeing" with something I didn't write in the first place. >>> I've gotten a bit weary of the complexities and long execution times of >>> Retrospect backups -- even incremental backups seem to involve a very [quoted text clipped - 10 lines] > generating a list of all files modified since a particular point in > time should be a simple query to the spotlight index. You are assuming that Retrospect only looking at the modification date and nothing else. Bad assumption, there. If Retrospect compared only modification dates, we'd be in a *lot* of trouble! And I doubt very seriously shoe-horning Spotlight in would do anything but make the comparison take much longer, because, with all the overhead, it's simply not the right tool for the job. Your assumption shows how little you really know about professional-quality incremental backup software. This isn't an "issue" that needs to be fixed on Tiger - it's just the way it works. SignatureJR >>>> I've gotten a bit weary of the complexities and long execution times >>>> of Retrospect backups -- even incremental backups seem to involve a [quoted text clipped - 20 lines] > isn't an "issue" that needs to be fixed on Tiger - it's just the way it > works. I'm glad there are truly smart folks around who can educate me then. Tell me how the contents of a file can be changed on any Unix system without the file modification field being set. And what sorts of file metadata updates are _not_ captured by mdimport... I'd also like to hear your speculation about how Leopard's Time Machine works, given that all reports I have heard indicate that it does NOT do a daily full volume scan. While all the data may or may not be in place to do incremental dumps without a full file system scan in Tiger, they are apparently there in Leopard. Your assumption that the metadata datastore indexes cannot _possibly_ contain the info needed to do a proper incremental dump is pretty lame given that fact that Apple will be using those same indexes for Time Machine. > Tell me how the contents of a file can be changed on any Unix system > without the file modification field being set. And what sorts of file > metadata updates are _not_ captured by mdimport... The modification date field itself can be fiddled with. So you could end up with an unchanged file whose date has changed or a changed file with a static mod date. I honestly have no idea how Retrospect will handle either of those situations because I'm not sure offhand what criteria they use to determine whether a file is in need of backup. The sorts of metadata that aren't captured by mdimport are anything that the single importer selected to process a file doesn't update. This can happen by omission, intentional or otherwise, or the import process could fail as happens with distressing regularity on my G5. Spotlight, today, does not provide a reliable enough selector for a mission critical task like data backup. > I'd also like to hear your speculation about how Leopard's Time Machine > works, given that all reports I have heard indicate that it does NOT do > a daily full volume scan. Bluntly, that's not especially relevant. It's a major revision of OS X away and there's no telling how much has changed. There's a lot of room for improvement in Spotlight over what 10.4.x has delivered. I hope, for example, that they've decided to update Spotlight such that multiple MD importers are given a shot at any given file. > While all the data may or may not be in place to do incremental dumps > without a full file system scan in Tiger, they are apparently there in > Leopard. Right. But we're talking about Tiger and earlier. So if it's not reliable today, it's not a good expenditure of resources for product that's shipping today. > Your assumption that the metadata datastore indexes cannot _possibly_ > contain the info needed to do a proper incremental dump is pretty lame > given that fact that Apple will be using those same indexes for Time > Machine. So the summary response is: 1. The behavior in Leopard is not relevant to a currently-shipping product. When more than 0% of EMC's customers are using Leopard, that's likely to change. 2. The problem is not that "the metadata datastore indexes cannot _possibly_ contain the info" it's that currently they do not _reliably_ contain that information. SignatureWhat I write is what I mean. I request that anyone who decides to respond please refrain from "disagreeing" with something I didn't write in the first place. > I'm glad there are truly smart folks around who can educate me then. > > Tell me how the contents of a file can be changed on any Unix system > without the file modification field being set. And what sorts of file > metadata updates are _not_ captured by mdimport... Try the experiment in my next paragraph, and it's at least one reason why Mac backups have to churn through everything to decide what to copy / back up. I believe things changed with Tiger, but under Panther, move a file from one folder to another using Finder. Both folders reflect the modification date, but the file itself does not. File contents have not changed, but it's now in a different place, and a backup program needs to work that out. The only way I know to achieve both fast incremental backups and data integrity on a restore operation is to record: a) the date and time of the backup of each and every file, including where it resides. b) a backup of _all_ directories, including date and time, of course. c) the backup date and time recorded needs to be that of the backup start, to cover files which may be modified during the execution of the backup. It's a more complex subject than it would seem to to be to the casual observer. Feedback welcome, 'cos I'd like to know how it's possible to speed up incremental backups in an OS X environment. SignaturePaul Sture |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.