Shirt Pocket Discussions  
    Home netTunes launchTunes SuperDuper! Buy Now Support Discussions About Shirt Pocket    

Go Back   Shirt Pocket Discussions > SuperDuper! > General

 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #7  
Old 01-20-2006, 11:43 PM
Syzygies Syzygies is offline
Registered User
 
Join Date: Jan 2006
Posts: 23
I had this same idea, got quite excited about it, and within 5 minutes of googling realized (of course) it had been done. The idea has many virtues: Don't rely on a proprietary format, take advantage of 20 cents/GB hard drives to store the data Finder-readable. Don't implement a specialized "snapshop" for each backup date as Retrospect does; you've got a friggin' file system already available to store information about files. (This is the same revelation that took Apple decades to realize: Why implement a resource fork, when the application could be a file system directory storing whatever you want? Retrospect evolved in the days of tape, but modern efforts can rethink the paradigm.) If one daydreams about a time-traveling hard disk whose contents change with one's desired view date, there can't be a simpler interface than clicking on a dated folder holding that view.

There's a free cross-platform product called rsnapshot which does exactly this. It depends on the Unix command line tool rsync, which was only updated to handle resource forks correctly in Tiger. Nevertheless, if one searches the web to confirm all is well in Tiger, one finds patch files for Tiger rsync, to fix issues with the current release. To put this all together, one needs to be very comfortable around-the-block with makefiles, etc.

rsnapshot is a PERL script. rsync takes on a lot more than the problems faced copying between two local drives; its primary concern is fast network copying. So in a way, rsnapshot is a kludge, though it's well thought of. I agree that a solid, minimalist duplicate finder written in C could do the heavy lifting here, managing the resource forks, Spotlight data, etc. correctly while building hard links or whatever once it determined duplicates and carried out the needed copies.

If this is a 'column' view, then ChronoSync takes a 'row' view: An auxiliary top-level folder called _Archived Items holds a parallel copy of one's directory structure, with backup copies of revised files all in the same parallel location, automatically given names like Backups Library_v001. Handy when you've hosed a particular file, and want to peruse the earlier versions all at once. However, ChronoSync can't clone volumes; it operates using a particular user's permissions, so an administrative account can't easily archive an entire machine. I've had various 'issues' and one repeatable lethal crash that takes one of my user archives out of commission, and I've yet to hear back ever from ChronoSync's tech support. In contrast, while I've been able to discover some obscure minor issues with new releases of SD!, it overall has been astoundingly stable and reliable, and my questions get instant replies. I've been stressing SD!.

I come around more and more to the view that .dmg image files are a great currency. One knows Apple and others will be able to open them in a decade. With DVDs down to 30 cents or less each, breaking image files into 4.2g chunks and burning them asynchronously becomes very appealing. (I'll post my scripts for this soon.) I crave a small burn watcher application that notices whenever I walk by and pop in a blank DVD-R, fetches the next burn job in the queue, and pops out the verified DVD when it's done. With images on external hard drives, this asynchronous task could be moved to a different machine. Getting the initial copy to disk image done fast when it's convenient to do so is what SD! excels at.

That said, the exact file structure of an archive becomes increasingly irrelevant, as long as one uses the built-in file system somehow so Spotlight can find everything. (Apple's goal here is to get everyone to forget about actual file locations, so our drives can become every bit as messy as our physical offices.) The most convenient file structure would support burning older portions of the archive compactly to DVD, then deleting to make space. Hard linking doesn't achieve this goal; every view is a complete snapshot, taking as much space as the entire original. Rather, the views save space collectively by overlapping each other.

This argues in favor of "differential backup" directories, containing only the differences generated in a given time frame. (rsnapshot could presumably be extended to generate a second set of directories containing any desired difference views.)

One reasonable evolution for SP! would be a filtering option to not copy any file found on one volume or image, in copying to a second volume or image. So e.g. use a complete "March 1, 2006" image to help generate and keep current a "latest version changed in March" image. Come April, demote the "now" image to "April 1, 2006", burn the March changes, and continue. Do the same for shorter time frames, as desired...

Last edited by Syzygies; 01-20-2006 at 11:51 PM.
Reply With Quote
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to verify a Scheduled Backup? tuqqer General 3 12-06-2005 06:50 PM
Sparse image from aborted DMG backup? Winston General 9 10-22-2005 12:28 PM
Request for help with an AppleScript to run two SD SmartUpdates emikysa General 2 10-13-2005 12:10 PM
(Zero-length) File caused SuperDuper to abort backup alancfrancis General 7 08-31-2005 10:42 AM
Smart Backup Error bill s General 20 02-04-2005 09:46 AM


All times are GMT -4. The time now is 07:54 AM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.