I learned a lesson - the hard way !

[pfauland]

Dear all,

 

Besides a lot of support and positive = encouraging feedback I got here, I have to conclude that I put my money on the wrong horse ! Sad, but true.

 

I spent ENDLESS hours, searching through this forum, the internet, was talking to the iomega-phone customer support, which was bringing me lots of knowledge, tips and tricks .. BUT ... my problem (a simple restore of the os plus applications plus data of a Macbook) was not solved. Since more than one month I am now trying to get this done, without success. Always a little tiny "new problem" appears and is stopping the process ....

 

 

My final conclusion for a WORKING backup strategy is the following :

 

1.) ALWAYS have an installation disk for the OS plus for all the applications you need in your drawer.

 

2.) All your data should/have to/must be backupd to secure external media.

 

3.) In the worst case (system crash, hard drive failure, ...), reinstall the system plus all the applications !

 

4.) THEN, you can RESTORE all your data and you are back up and running.

 

The "one click, and you have your system back" solution might work in rare cases but is not the "safe and standard procedure". It's hard to believe but it seems to be true !

 

Even a very friendly and competent service technician at Apple told me, that "also Timemachine is not always able to give you a fulling working system back" ... What do we learn ?

 

If you have to reley on your system plus data the only SAFE and foolproof way is, as described above.

 

I see my investment in this software (Retro 8 for Mac) as a "charity donation" that might help to improve the software PLUS the (missing for ONE year now) documentation one day.

 

I lost my installtion, a looooot of time and money, but I gained WISDOM ....

 

So long ...

 

Peter

[rhwalker]

You left out the most critical step for a working backup strategy: testing.

 

You should never deploy a backup solution without thorough testing to ensure that it meets the requirements of your backup policy. That means bare metal restores, test restores with validation of metadata, etc.

 

Russ

[pfauland]

YES ! You are absolutely right. This opens up one important question: How do I really test that the computer will/would work (= bring back the repaired machine to a "working as before" state) ? In the past, I was doing a restore to another volume or partition, which proved that the correct number of files was restored but this is only half the rent ... In fact thinking about it, one should do a restore to an empty external hard drive, connect this particular drive to the machine and then do a "BOOT FROM THIS EXTERNAL DRIVE" .... Only if then everything works properly, one could say " I do have a working backup ! "

 

.... Any other thoughts ???

[rhwalker]

YES ! You are absolutely right. This opens up one important question: How do I really test that the computer will/would work (= bring back the repaired machine to a "working as before" state) ? In the past, I was doing a restore to another volume or partition, which proved that the correct number of files was restored but this is only half the rent ... In fact thinking about it, one should do a restore to an empty external hard drive, connect this particular drive to the machine and then do a "BOOT FROM THIS EXTERNAL DRIVE" .... Only if then everything works properly, one could say " I do have a working backup ! "

 

.... Any other thoughts ???

No, that's not a sufficient test.

 

One way is to first clone the internal drive to an external drive (many ways to do this, either the "RAID 1 mirror split" with all services off, which creates an instantaneous exact copy, or a cloning program that you trust - I prefer SuperDuper! for many reasons), then format the internal drive (erase, wipe with zeros), then test your bare metal restore procedure.

 

Because testing takes a long time, and you need a baseline against which to test, you might consider booting from an external drive and creating a Disk Utility sparseimage of the computer's internal drive so that you can always clone back to that state from the sparseimage.

 

Also, just because it "boots" is not a sufficient test.

 

You also need to test the metadata restore capabilities of your backup strategy, and this is harder to do than it sounds. I suggest:

Backup Bouncer

 

There are also the issues of compressed system files in Mac OS X Snow Leopard, etc.

 

Russ

[pfauland]

Wow ... This sounds impressive and scary both at the same time. You agree with me, that the commercials and "how-to" documents for all the "professional backup solutions" is just "a bit misleading" to say the least .... Which percentage of users does even know about all this !???

 

So, my "simple scenario" : In case of a (serious) problem to do a reformat / or exchange of hard drive then, playing back system and software via CD/DVD and then "just" restoring the personal data makes more and more sense, as the re-installation from DVD _WILL_ work. And just copying .doc, .pdf, .jpg, .xxx files to a safe place will be also ok.

 

Cheers

 

Peter

 

PS.: formatting the internal drive of a working and in use system to do a backup test, as you described above, is for sure a thing not many users would feel brave enough to do / have the time and expertise .... but I do agree - That's the expert's way of being sure ....

[rhwalker]

It all depends on the value of your data. Ours is valuable, much much more valuable than the price of the backup hardware and software.

 

And it all depends on your backup policy, which is a tradeoff between the amount of time you can afford to be down and the time to restore.

 

If, for example, the client computers all have Network Home Directories (NHDs) on a server, and all email is kept on the server, and no local documents are stored on the network computers, then it's a simple matter to image one computer and not even back up the local computers - you can always reimage.

 

Or, if you use a solution like radmind to monitor incremental changes to each computer from a master image, it's also simple to reimage the local computers.

 

Likewise, backup and restoration of a server is complex, and is not currently supported by Retrospect 8 (because R8 has no scripting capability that can be used to coordinate snapshot of particular server databases with services turned off, etc.).

 

Again, it all depends on your backup policy, and many people never formulate the backup policy as the first (and necessary) step against which any backup strategy must be evaluated.

 

Here are some of the issues to be considered when formulating a backup policy:

What should a good backup policy address?

 

Russ

[pfauland]

Dear Russ,

 

Again, I can only agree with you. In most cases the data are MUCH MUCH more valuable than soft-/hardware (as those can be "easily" replaced, while data that are lost are lost forever. Explain that to a paying customer ...)

 

What is annoying to me is, that with R8 I am stuck in doing a simple RESTORE and each time, I thought, I found a way out, there is another "simple little problem" that stops the process.

 

I would have expected, that things like "do a full backup", "restore a media set", "copy a backup" etc. should have been tested under countless configurations in order to make the product "stable" for the normal customer. To add special features later is fine, but to throw a "half-baked potato" on the table is ... strange ... according to my understanding.

 

Checking some log-files, I have seen that a ".DS_store" file stopped the restore procedure. I mentioned my suspicion about that to the Iomega Support expert and now got the response ".... files starting with a dot should not be in a backup, it's worth trying (!!) to remove them". So I will. But, IF these dot-files are a killer criteria to just crash a RESTORE, why are they even taken into the backup !???? Maybe I am the very first person on the plant, who had this problem ??? I don't think so. (Retro 6 was working for a long time on the system WITHOUT one single problem, I could remember). This means, I will go now manually through ALL folders, checking for dot-files / folders and remove them from the list of files to be restored and I will see what happens ....

 

Thanks anyway for your constant support !

Edited December 3, 2009 by Guest

[rhwalker]

I would have expected, that things like "do a full backup", "restore a media set", "copy a backup" etc. should have been tested under countless configurations in order to make the product "stable" for the normal customer. To add special features later is fine, but to throw a "half-baked potato" on the table is ... strange ... according to my understanding.

Your expectations match mine and those of many others. The software seems to have been released without a design review, without documentation, without user input/review as to UI issues, and without adequate software QA/QC. Perhaps someday it will emerge from the present interesting technology demonstration that is not yet ready for production use. It's only a year since the product was announced the first week in January 2009, so perhaps we just need to be patient for a few more years.

 

Russ

[rhwalker]

I mentioned my suspicion about that to the Iomega Support expert and now got the response ".... files starting with a dot should not be in a backup, it's worth trying (!!) to remove them".

That's just complete hogwash, and the Iomega Support "expert" (?) doesn't have a clue and obviously knows nothing about unix.

 

Next time you hear trash like that, ask to speak to the person's supervisor or at least someone who understands unix.

 

Fire up Terminal and do an

ls -al

on a bunch of directories. Unix will not work properly if files beginning with "." are not backed up and restored properly.

 

Simply FYI, the ".DS_Store" files are part of the Finder's hidden metadata, and preserves things like the view for each folder (icon, list, etc.). Deleting ".DS_Store" files is not fatal, and simply causes things like custom view status, etc., to be lost and returned to the defaults.

 

Russ

[CallMeDave]

my problem (a simple restore of the os plus applications plus data of a Macbook) was not solved

 

I see my investment in this software (Retro 8 for Mac) as a "charity donation" that might help to improve the software

 

You don't describe in this thread what you were trying to do that did not work; the thread "How to Restore" indicates quite a bit of confusion on your part about how Retrospect 8 works (not your fault, given the lack of documentation). But that thread ends on 11-7-2009 with you promising "I will report ...." but you never did.

 

Generally I would assume that if you were on the horn with tech support then User Error would not be in play, but given the mind numbing stupidity of the operator who claimed that Retrospect should not backup dot-name files leaves open the possibility that you are still simply Doing Something Wrong.

 

I see no reason to assume that Retrospect 8 cannot do a full restore of a volume within the limitations of the backup itself (files that were not backed up due to circumstances beyond the control of the backup program can not, of course, be restored). A "Live Restore" to a booted volume (via the client software) is a whole 'nother kettle of fish and is not something I would include in my backup policy (bring the mountain to the machine or the machine to the mountain; it doesn't matter, just don't keep them apart)

 

Without knowing your _exact_ backup policy and the _exact_ steps you took in your disaster recovery attempts it is impossible to know where the point of failure occurred. It might have been a defect in the software or a failing of the wetware between the keyboard and display.

 

Dave

[pfauland]

First of all, thanks for "not leaving me alone" :-)

 

Well, to repeat _exactly_ what I was doing, let me summarize:

 

I do have a disk media set that contains a full backup of MacBook B. After a hard disk failure of this MacBook, I wanted to use the restore assistant - with Retrospect running on another MacBook A - to play back the system plus data to macbook B, which is connected to A via Firewire and booted in target disk mode. The backup itself - the mediaset containing all the data for B to be more precise is stored on an external NAS. Following the advice of the iomega support guy, this mediaset was copied to macbook A. in the restore assistant, the mediaset is selected as source, macbook b is selected as target, then the machinery starts properly .... around 70% of files are restored, then it stops with a message in the log file, telling me, that ".DS_store" could not be written" (error -1101).

 

That's it for now.

[pfauland]

That's just complete hogwash, and the Iomega Support "expert" (?) doesn't have a clue and obviously knows nothing about unix.

 

Next time you hear trash like that, ask to speak to the person's supervisor or at least someone who understands unix.

 

Fire up Terminal and do an

ls -al

on a bunch of directories. Unix will not work properly if files beginning with "." are not backed up and restored properly.

 

Simply FYI, the ".DS_Store" files are part of the Finder's hidden metadata, and preserves things like the view for each folder (icon, list, etc.). Deleting ".DS_Store" files is not fatal, and simply causes things like custom view status, etc., to be lost and returned to the defaults.

 

Russ

 

This is really shocking. I have to admit - put shame on my face - that I am far from being a unix expert myself. I was just hoping to talk to an expert via the hot line in order to solve my problem. And now this .... If this .DS_store file is not really the "source of all problems", as it can be there but does not have to, I wonder why it stopped the restore procedure ? General question, why does the restore of thousands of files stops, if ONE file has a problem ?

 

My plan was to see, if skipping this one file, would make the rest of the restore finish successfully ...

[pfauland]

You don't describe in this thread what you were trying to do that did not work; the thread "How to Restore" indicates quite a bit of confusion on your part about how Retrospect 8 works (not your fault, given the lack of documentation). But that thread ends on 11-7-2009 with you promising "I will report ...." but you never did.

 

I see no reason to assume that Retrospect 8 cannot do a full restore of a volume within the limitations of the backup itself (files that were not backed up due to circumstances beyond the control of the backup program can not, of course, be restored). A "Live Restore" to a booted volume (via the client software) is a whole 'nother kettle of fish and is not something I would include in my backup policy (bring the mountain to the machine or the machine to the mountain; it doesn't matter, just don't keep them apart)

 

Without knowing your _exact_ backup policy and the _exact_ steps you took in your disaster recovery attempts it is impossible to know where the point of failure occurred. It might have been a defect in the software or a failing of the wetware between the keyboard and display.

 

Dave

 

I was trying to summarize my backup strategy again here in this thread. You are right, I should have reported in the original thread about my progress (or lack of it).

 

One possible reason for the "mess" might be that for the media set involve I had a "unix path discrepancy" from the beginning. Reminder: media set is stored on NAS (path : /volumes/Backup/Retrospect/......). in retrospect I see the catalog and/or media set members e.g. as /volumes/Backup-1/..... Comment from support: "NAS has to be unmounted before using retrospect to avoid mounting the same volume/folder two times".

 

Now after copying the needed media set to Macbook A and rebuilding the catalog, the restore to Macbook B started (everything looks promising) ... then before finishing the complete restore, it stops (log message :" .DS_store could not be written (-1101) " ....

 

Cheers

 

Peter

[rhwalker]

I have to admit - put shame on my face - that I am far from being a unix expert myself.

There is no shame in ignorance. We were all ignorant once. The shame is when clueless "experts" pontificate on subjects about which they have no knowledge.

 

General question, why does the restore of thousands of files stops, if ONE file has a problem ?

Well, to me, it seems to indicate a bug in the program. Now, there are certain rare instances where Retrospect isn't able to overwrite a file, but it's a bug for that to stop the restore. Retrospect 8 is in its infancy, and is not bug free. Anyone who deploys it into production in its current state is an early adopter, taking the risks that such an approach causes.

 

My plan was to see, if skipping this one file, would make the rest of the restore finish successfully ...

A very reasonable plan.

 

Russ

[CallMeDave]

You can create a Restore Script with a Rule to exclude .DS_store files from being written. That might get around whatever it is that's stopping the operation.

 

 

[pfauland]

Retrospect finished successfully RESTORING the mediaset after I removed only this .DS_store file.

 

Nevertheless, the system is not booting ....

 

 

[rhwalker]

I really suspect that you've got some odd permissions issue floating around that is preventing the .DS_Store restore and perhaps causing other issues.

 

It may be that Retrospect's install didn't go right (Retrospect and its clients are supposed to run setuid root to give it read/write access to everything for exactly this reason).

 

I suggest that contact EMC Retrospect support:

Contact EMC Retrospect support

 

This may be a bug with a known workaround or it may be something where they could walk you through the recovery process to figure out what is wrong. In the absence of a manual and in the absence of a recovery boot CD, that's about the best suggestion I could give.

 

Or you could put the MacBook into Target Disk Mode, attach it as a local disk to the machine running Retrospect, and do a local restore. I'd suggest first doing a MacOS X install onto the TDM computer, bringing it to current OS update status, then doing the restore on top of that.

 

Russ

[impala]

I wonder if that was the root /.DS_Store file for that volume. That would make sense that the file would be in use by the Finder even as retro was trying to replace it.

 

You may be new to target mode. One thing you have to watch in target mode (or any external drive) is the "ignore permissions" setting. Select the volume in finder, do Get Info, and at the very bottom is a checkbox called "Ignore ownership on this volume". Sometimes you want it checked to do certain things, but you DO NOT want it checked when you are doing backup or restore.

 

Also, what option did you choose in the restore script dialog on the "Destinations" tab. IE: "Overwrite Corresponding", or "Restore entire Volume", or something else?

[mathisdw]

Just sharing my experience and a little advice:

 

I have used Retrospect for about 10 years, with plenty of frustration the whole time. I have seriously searched for a replacement about 4 times, but each time, I concluded that no other affordable software has nearly as good a feature set as Retrospect. When it works, it's great. And it "usually" works. Retrospect 8 for mac is the most stable version I've seen, which is promising. Retro 7.6 for Windows was crashing once a week.

 

If you stay with R8, I would recommend using a strategy in which you expect Retrospect itself to be unreliable. For me, that means:

 

(1) backing up catalog files and retrospect config files to their own backup sets, so that WHEN a catalog file gets corrupted (it ALWAYS does eventually), you can just restore it, and when Retrospect crashes and forgets all your clients, you can restore that, too.

 

(2) splitting my clients into groups of about 5-10 machines each (I have 11 groups). That way, WHEN a catalog gets corrupted (it will), you do a restore from backup and only 5-10 machines have lost any data, and only a few days' worth. Also, big catalog files seem to be toxic -- all sorts of R8 and system problems start to occur.

 

(3) Do a disk-to-disk-to-tape strategy, because backing up only to tape is FAR too slow and will kill your tape drive, and backing up only to disk will result in you losing ALL of your backups eventually (this happened to me at least 5 times).

 

(4) Don't expect grooming to work. (Well, it works if you initiate the groom manually, AND there's a lot of disk space available. But if you wait for it to groom automatically, be prepared to lose your catalog file.)

 

With these methods I'm doing pretty well right now. I've got tape backups no more than 2 weeks old at any time, and I've got all recent backups on disks. I have had to restore catalog files occasionally, but R8 handles that well. You can just use them and R8 thinks there are no more recent backups than what appear in the restored catalog. Before I started backing up my catalogs, these corruptions were disasters.

 

I might also add:

 

(5) Do read these forums and do report all your bugs.

Edited December 8, 2009 by Guest

[cyclopath]

shooting from the hip here....

 

my first guess is that the target disk was mounted "ignore ownership" when the restore was done (that seems to be the default on external disks)

 

Retrospect _should_ have complained, but I don't have a lot of faith left when it comes to Retro8 doing "what it should".

 

-nigel

[kerryd]

All interesting. I agree about this documentation thing. This is a complex program and what's included is extremely weak.

 

I use a variety of backup systems just for safety. I do use SuperDuper! and if my internal drive were to fail I'd just be able to reverse clone my drive from my external drive. I actually did it once for a different reason and all was good and my drive defrag'd as a side result.

 

I have a friend that had his computer stolen this summer and he was able to do a complete restore from Time Machine. I've never tried this but have used Time Machine to restore data files more than once. I also use Crashplan to store critical data in the cloud.

 

So two separate external HD's for backups and the cloud. I hope in all of this somewhere I'm covered should disaster ever strike that something will work.

 

I used to use Data Backup but they still can't get their system to work with Snow Leopard surprisingly. It was actually a pretty straight forward but powerful backup program in Leopard but since they couldn't get it to work with Snow Leopard I decided to return to Retrospect a month ago. I consider Retrospect overkill for my needs but since I used it for years I was able to get onto it fairly fast. I would think for a lot of Mac users though, with the poor documentation, this would be a hard program for them to implement.