I use Ubuntu's automated backup, and have successfully restored from backup before.

I just installed 64-bit 13.04, overwriting an install of 32-bit 13.04. I hadn't realized, when I installed the 32-bit, that I was equipped for the 64-bit. I went through the trouble of re-installing now, rather than waiting for the next Ubuntu release, because I think I screwed things up royally while trying to install and use Wine. I thought I'd better start fresh. I say all this in case switching from 32-bit to 64-bit could somehow be related to my trouble.

I used GUI, System Settings, Backup, and pointed it toward the external drive I use (which is connected by USB, and recognized by the computer), and to the relevant folder on that drive, but it won't take my password. It says, "Encryption Password Needed," and I type in the one that I've always used. The windows makes busy for a bit, saying "Restoring . . ." and "Preparing . . .," but nothing shows up under "Details," and within a few seconds I'm returned to "Encryption Password Needed."

This is alarming, of course.

Update: I have realized that what I use is Deja Dup. I've found the Help page called Backup Help / Restoring Files / When Everything Goes Wrong. There's nothing there about a password no longer working.

Is there a workaround? Via the terminal, perhaps? I sure hope so.

Thanks.

it sounds like you overwrote the encryption key
without it
you do not unencrypt that backup

SOL

John VV,

In what manner can the encryption key be overwritten? I obviously never intended to do that, I trust that the software would make it a pretty deliberate process, and I won't believe I've done it until I understand how it could have happened. Until then, I'm going to look for other possibilities.

Thanks.

how it happened
you overwrote the operating system and all the files


next time keep a copy of the keys on a cd and off site

I'm not clear on what it means to keep a copy of the keys on a CD. By "keys," do you mean passwords?

I successfully restored files, using Deja Dup, after installing Ubuntu 13.04, overwriting 12.04, with no problem, so I don't see why doing essentially the same thing again would get me such a different result. In case going from the 32-bit OS to the 64-bit somehow did make the difference, I reinstalled the 32-bit, but I'm still having the same trouble.

I also, by the way, tried restoring from an earlier backup, in case the latest was corrupt, but same result.

What if I had tried to restore the files to a different machine? Would having reinstalled the OS in this machine make the restoration impossible in another machine? I feel like I'm dealing with Heisenberg's boxed cat, or a photon facing two slits.

I haven't been able to find any explanation online to the need to store "keys" in another location in order to restore files from a backup. All I read is how simple and straightforward Deja Dup is, and how important it is not to forget the password. No one says, "Make sure you save the keys elsewhere before installing a newer OS."

Something obviously is different this time from when I installed 13.04 over 12.04. If, as you say, "keys" have been overwritten in a way that makes the old password no longer work, wouldn't the overwrite be in some manner that is predictable? I.e., if the old password has been overwritten, surely it would be overwritten the same way in every case, so that there is a different, determinable, set of keystrokes that would satisfy the password request.

Thanks.

if you lose the encryption keys ( likely RSA 768 or 1024 )
you are " up bleeps creak ,without a paddle "

you handle them the same as mission critical back ups
on site and with a copy off site or in a different place

if you mess up the local back up ( it happens at work and at home )
dog chews on the dvd ......
you have a second back up

I still don't understand the same things I didn't understand after your last post. I didn't lose the password. I don't understand how or whether an encryption key is different from a password. I don't recognize "RSA 768 or 1024."

I'll keep looking.

Thanks.

Perhaps it would be a good idea, before using encryption, to actually read all the documentation on how it works.

Also learning exactly how installation of OS,s, any OS, is done. Installing completely different OS's, like a 64 bit version of a 32 bit version is not, no matter what the gui looks like to you, the same OS at all.

Yes all that stuff is laced with language that you do not understand. You can look that up too and find out what it means.

This really looks like you don't have a lot of respect for your own data. You really should try to understand what you are doing before you do it.

Your passwords, that you still have, are for exactly what? Well they are to unlock encryption keys. All encryption keys, like a decoder ring from a Cracker Jack box allow for the decoding of the encrypted material.

So you have sent a message to yourself that was encoded using YOUR unique decoder ring and then YOU burned the encoder ring. Now you want to read that secret message. All YOU have to do is rebuild that decoder ring from the ashes.

That data is recoverable. It will take a lot of money and a lot of time for some company with the knowledge to do so. Or YOU could learn to do so.

Encryption is not unbreakable. The idea is to make it time consuming enough to do so that the data is worthless when the process is done.

There are other ways to safe guard your data under Linux. This all has to do with file permissions and all that complex user and groups boring stuff. It relies on strong user passwords and a separate and considerably stronger root password.

Once you work all that system out you will then be ready to learn something about encryption. Like enough to use it without loosing the keys for it.

I am not trying to be nasty here but you seem to have the idea that you can treat an encrypted Linux system in the same manner that many people treat a Windows system set up with no password so that they are logged in as administrator. It doesn't work that way.

This is security. It means you don't mess with it in a casual manner. You don't change the system without backups that are created with the full knowledge of how it works and what makes it possible for it to work by the system administrator. That administrator is YOU.

ANY recovery of this data that could possibly be dealt with on an open forum would mean that the encryption process was NOT any good.

All you need, having the passwords for the keys, is to recover those encrypted files that hold the encryption keys, the ones YOU over wrote. Simple as that.

Having said all that, you may be able to recover the original OS containing this information. This may be done using a rescue disk with the tool "testdisk" installed. As that os has been overwritten twice now it may not work but I have recovered systems and had them actually boot up and work that were overwritten up to 5 times.

The very first thing to do is to quit booting to that drive. Every use of the file system makes recovery more difficult.

Get a new drive to use to learn on. If you have 2 drives this would be great. Switch to the other drive.

If you can put 2 clean drives in your box or use externals you could install on one and use it for a couple days, reinstall over it and do it again (with a 64 bit version over a 32 bit first version, then reinstall a 32 bit version over that 64 bit install. Then on your other drive install a solid system, install testdisk and try recovering that first install.

This will give you some practice using the tool. Read the documentation. Do this as many times as needed to recover that first of 3 installs.

When you have done that do it again. Using encryption on the first 32 bit install. Then play with that until you can recover it. This should work.

When, and only when you have done that, put your current drive in and do it from the same OS you have learned to recover data on.

You need to be working from another drive or Live Session to use testdisk because the drive you are recovering needs to be unmounted.

If your original install can be recovered and boot it is very possible that your encryption keys are still viable and will work. This is the only thing I can see as a possibility of you ever recovering that encrypted data.

Good luck. One thing is for sure. You will learn a lot.

You can go to console and invoke commandAnd show response which you get, without long list of files if any.

1 members found this post helpful.

I'm not a user but as far as I know deja dup is a frontend for duplicity which uses GnuPG. The archive files are just encrypted tarballs and you should be able to manually access them via gpg, rdiff and the tar commands.

It would be nice if you could post any error messages generated by deja dup/duplicity or even GnuPG. Could it be a simple as gpg isn't installed?

widget,

I understand that it looks to you as though I don't care very much about my data. Apparently it also looks like I don't try very hard to learn. I am trying as hard as I can, and if I never used software I didn't understand, I'd be stuck with my notebook and pen. I have already learned many lessons from this episode, but learning doesn't always offer the choice of which mistakes to make, nor how costly they will be. I heartily wish that I were more knowledgeable and less dependent on help from others, and that my mistakes were more sophisticated. That's what I'm working toward.

I will try to make use of what you've written, if I can get past the disparaging tone. I do appreciate your taking the time to write.

eSelix,

Thanks for you suggestion. I'm not yet able to figure out file paths. What was clear and intuitive in Windows remains obscure to me in Linux. I'm using an external hard drive for the backups. Can you tell me how to ask the computer for that pathway?

Thanks for taking the time to respond.

When you right click your external drive, there should be option like "properties", there is usually info about path. Or you can invoke command from console "mount", this will show mounted drives (of course you need first mount it if it was not done automatically), if you will not recognize which one is your backup drive, show output here.

1 members found this post helpful.

I believe that default mount point for drives that are automatically mounted is /media/<username>

And just use your file browser.

1 members found this post helpful.

michaelk,

I don't get error messages. I'm using GUI; I don't know how to use CLI for this. All I get is "Encryption Password Needed," and when I type it, the window makes busy, with expanded "Details" showing nothing, and then I'm returned to the "Encryption Password Needed" stage ad infinitum.

As a bonus, newly this ten minutes, neither "Restore . . ." nor "Back Up Now" is possible via the GUI backup utility. Both options are grayed out. I don't know why; nothing I know of has changed. I tried safely removing the external drive, and plugging it back in, but that didn't help. All the files seem to be in order, accessible (except the encrypted duplicity ones, of course).

Thanks.

Thanks for the guidance, eSelix and michaelk.

I think now I know what I may have done to create this situation. I'll get to that in a moment.

First, here's what the terminal shows:
Here's what I think may be causing my problem: I've been deleting /media/kirsten, because I didn't understand why that subdirectory with my name kept appearing, and it seemed to be making me unable to watch movies on my DVD drive. If you're interested, the thread where I got help with that is here. In brief, DVDs kept showing up under that /kirsten subdirectory, and that seemed to be contributing to trouble getting DVDs mounted and unmounted. At least that's how I understood it. The person who eventually helped me solve the DVD problem agreed that removing /kirsten from /media was a good idea.

My questions are probably obvious, and can be summed up thus: Could this be the source of my trouble, and can I undo the damage?

Thanks.