Follow-up from https://discussions.apple.com/message/13337119#13337119

Thanks for the tip, Pete. But, as you may have read, I DO use a different set of saved data: clones done with Disk Utility while booted from another disk. I never (yet?) had a problem with these Disk Utility copies of the system disk and I always reboot on them to check their validity after creating them. As I noted in the referenced previous discussion, Disk Utility DOES check the integrity of the saved data...

The trouble is that it is much longer to do a Disk Utility save than a Time Machine incremental save. So I was only using Disk Utility every second week, while I was manually saving incrementally with Time Machine every second day... I now absolutely need to find another solution... Thanks again for shooting me in the foot, Apple... I do not so much resent the fact that Time Machine is bugged (this happens...), but the fact that Apple advertises it as a backup utility when it does not check data integrity. This last point is seriously dishonest (this is an understatement if there ever was one).

Re. the previous two replies (Linc Davis and etresoft).

May I point out that:

1) My way of using Time Machine may be non standard, it is documented as supported.

2) You state that my argument for not using FV 2 are not valid: would you care to explain why? If a non authorised person has to do maintenance on the system, it is only normal that this person is not given access to confidential data. FV 2 simply does not allow this, while "legacy" FV does. Apple's convenience is not necessarily compatible with the customer's need. And "legacy" FV is still officially supported.

3) You explain me that I'm the weakest part of the backup scheme. OK. I have detailed my backup procedure. Please, explain me WHAT in it is not valid? All I do is ensuring that, when a manual save is done, no user file is left open, no encrypted data is accessed and no remote connection exists. Please, tell me how is this supposed to corrupt a backup?

4) The one possible cause for a problem I spotted in these two replies: I did not (this second time, not the first time 15 months ago when I got as a result a non bootable system disk after a "successful" restore...) use one of the two interfaces provided for this purpose. OK. Then, why is it possible to access saved data in a non supported way if this is critical for the integrity of the saved data? Nice utility that allows this...

OK. So, my problem is that I did not restore the user files in a supported way.

Question: I'd like to find out where the supported ways of restoring files are documented. I ask because I couldn't find it on the support site AND THERE ARE SUPPORT ARTICLES (from Snow Leopard time) THAT DO RECOMMEND RESTORING INDIVIDUAL FILES BY MANUALLY MOUNTING THE SPARSEBUNDLE IMAGE THE WAY I DID...

Also, I did open Time Machine when logged in an encrypted account, went to the date of the save I wished to restore, and accessed directories Users, then Username and doubleclicked on username.sparsebundle. This offered me to "Open with DiskImageMounter" and I dutifully clicked (and also double-clicked) on the button. Which, in either case, produced NO result... What is going wrong there?

So I had to spend a whole afternoon restoring the complete system disk's last save previous to the time of the accidental unwanted delete on a clone of the system disk, then rebooted on that clone, accessed the user files and found that they were indeed this time accessible and uncorrupted. Which allowed me to copy to the normal system disk the ones that were missing.

So far, so good.

Thanks for pointing to me that the problem was possibly there. I now have one record of one Time Machine use in case of problem that went well.

Note that, 15 months ago, when I "successfully" (according to Time Machine) restored my system disk, I did it the supported way and nevertheless was presented with a non bootable disk... This problem was never explained and I've no reason to believe it could not happen again.

No thanks however for hinting that the cause of the problem may have been doing a manual save on a quiesced system. I agree that you may be right in calling this overkill, but I don't agree that it could cause Time Machine to corrupt data. If it did, the product would simply not be worth a single cent.

No thanks either for pointing that the use of a supported feature ("legacy" Filevault) could have been the cause of the problem. Had it been the case, it would have been a bug. Period.

There remain two serious issues with Time Machine.

The first issue is the non functionality of the "Open with DiskImageMounter" button. Any possible explanation?

The second issue is, in a way, much more serious. If manually mounting the sparsebundle file is not supported (while there are support articles that recommend it...) and results, as demonstrated in my case, in restoring corrupted files, then it is a serious security issue that it is at all possible to do it. The more so as forbidding it should not be very difficult to implement.

Well, I must say I'm sorry to have to act and write as if I were the grumpy smurf, but I must point out that, until now, I did not have much luck with the one application that, ideally, should never have a problem on any OS.

Also:

"There are 50 million people using the system one way and not having any trouble. You are using the system in a different way and having all kinds of problems. Then you come here and complain that the system doesn't work. The problem is that you have developed your own system. If it doesn't work, you have no one to blame but yourself."

This is a standard answer you could do to any user who runs into any uncommon problem and is simply a way to say "I don't care" to a real problem.

"If I recall correctly, the only time user directories get backed up in the old File Vault is during logout. It is not possible for the admin account to manually save a Time Machine backup while the two encrypted users are logged out. Only they can do the backup when they log out. It sounds like you have hacked up your own system to backup the encrypted user home directories manually. This is most definitely not standard. Perhaps you tried to execute that procedure while one of the users was logged in. That would be a good way to corrupt 80% of your backup. The way old File Vault worked with Time Machine is that, while both the home directory and backup encrypted images were open, it did a backup of normal, unencrypted files. That is relatively stable because if either image were corrupt, your login probably wouldn't work, let alone the backup."

I have hacked nothing and I can guaranty that NO encrypted user is logged in when I do the save, because this system is used like a single user machine. There is ZERO chance that I did it while another user was logged in. Standard or not is irrelevant in such a case. And the save was actually not corrupted, as today's manipulations showed. You are just imagining a fake reality that would fit your position rather than accepting my word. I grant you that you do not have to believe me, but I'm certainly in a better position to know how things are done on this system than you are.

"There is no way to tell how long the old File Vault will work. I think there as already been one bug that only hit people still using the old File Vault. Eventually, it won't work at all."

Interesting position that provide a lot of upward compatibility to the users... They'll appreciate.

Maybe I was not clear. If so, I apologize and shall try to make myself plain.

When you say:

"The only way you should restore files is from the Time Machine interface. You can run the "Time Machine" application or you can choose "Enter Time Machine" from the Time Machine item in the menu bar."

This is what I did yesterday afternoon. Previously, on my first attempt, I had tried accessing and restoring the files from the finder. This, because I had found support articles recommending it. By the way, WHERE can a mere mortal find the official documentation of Time Machine (I assume it does exist...)?

This first attempt had resulted in about 80% of corrupt files (but some were clean...). So vital a utility as Time Machine should never allow to do things in a forbidden way.

You say again:

"Everything. When logged into an encrypted account, all you should do is run the "Time Machine" application or execute the "Enter Time Machine" command."

In case I was not clear, this is precisely what I did. And was prompted BY TIME MACHINE, NOT BY THE FINDER to "Open with DiskImageMounter". Which, when I clicked on the button, did exactly nothing. This is why I asked "What is going wrong there?"

Again:

"No, that sounds like a disaster. If you need to do a complete restore, just hold down "R" and boot into your recovery volume. Then restore from Time Machine. The whole thing is automated."

I agree that booting the recovery disk holding "R" is one of the known ways to recover a whole disk. But, if it should not be done from the Time Machine interface run manually, WHY DOES THE UTILITY ALLOW IT AND EVEN INVITE YOU TO DO SO? This is (if it really is unsupported and forbidden) the serious security hole I was mentioning in my previous reply. Also note that it happens to be the one manipulation that allowed me to recover the lost files.

About the non working "Open with DiskImageMounter" button":

"Whatever you were doing corrupted the volume. No mystery there."

In case you did not understand, again, I was IN THE UTILITY INTERFACE IN THE SUPPORTED WAY. The button was non functional and this is what forced me to restore the whole disk. And I did NOT corrupt anything, as evidenced from the fact that the full restored disk I produced later was bootable and provided access to the uncorrupted data files I was looking for. The fact that the button was non functional in the utility is what I was reporting there.

About my own backup strategy, I repeat that I did not hack anything, simply used manually (a supported feature) a utility that can also run automatically. I did use it on a quiesced system, which can in NO way corrupt a backup if the utility is not bugged. The fact that backups of encrypted accounts happen automatically at logout is irrelevant here, as a manual backup done when encrypted users are logged out also saves their accounts, as evidenced by the fact that I did eventually recover the data I was looking for.

OK. I give up. It is the third time you insist that I corrupted my backups (or that they did not take place), while my previous answers should have made it plain that NO corruption took place and that the backups were indeed done. Otherwise, I could never have eventually restored the lost files. Either I am not clear, or you have a comprehension problem. Or both.

What DID happen is that the way I first tried to restore the lost files was not the way it was supposed to be done.

What I was reporting since my second entry are the following points:

- I restored the file the wrong way because I found articles in the Time Machine discussion that recommended it. This is a first problem.

- When trying to restore the lost files the supported way, the command that should have allowed me to do it was not functional. This is another problem.

- IF it is indeed unsupported and forbidden to restore a whole disk from the utility interface called when logged in, then it is a serious security hole to allow it and invite the user to do so. Besides, it actually worked fine and restored a clean system disk. Which makes me wonder if it is indeed forbidden. This is possibly a third problem, depending on whether this is really forbidden or not.

Such issues in so vital a utility as Time Machine should be addressed.

And these problems have NOTHING to do with with my "human intervention". So, please, stop insisting on it as the cause of my trials, as it is now proven that the way I am doing my backups IS indeed clean (as evidenced by the fact that the lost files were eventually recovered from the backups).