[ale] Help with data recovery

Mon Aug 24 17:34:22 EDT 2020

>>This indicates to me that you are right, Bob. The password was the
password. There is no other key that's being created and stored somewhere.
It also would seem to indicate that the password is somewhere on the backup
drive, but I don't have any idea where on the drive that would be.<<

Hey Jim,
One thing to remember is that the key itself will probably be encrypted.
That's likely what the password is for.  It's less secure than a two-key
system, but the single key would be worthless if anyone who found your key
could come along and use it to unlock your encrypted asset.  Like keeping
your front door key under the welcome mat.  Not very secure.  So the
password is simply to decrypt your key and make it usable for you and only
you.  The key probably stays decrypted just long enough for you to use it,
and then the decrypted version disappears or something.  The password would
probably be part of the text (or all of it) that is used to encrypt the
key.  Providing that password back into the decryption formula would
decrypt the key.  In this case the password would not need to be stored
anywhere.  I'm no expert on encryption--there are many who are on this
list--but I think that's how it works... or maybe some other way!!!  ;-D

On Mon, Aug 24, 2020 at 4:19 PM Jim Ransone via Ale <ale at ale.org> wrote:

> Much thanks to everyone for the suggestions and advice so far! Here is an
> update:
>
> I have attempted to duplicate the entire scenario on an older spare laptop.
>
> - I installed the same OS - Ubuntu Studio 20.04.
> - I created a folder and filled it with a handful of files.
> - I used Deja Dup to back up the folder onto a usb flash drive. (Didn't
> want to risk doing something weird to my actual backup drive.) Was asked to
> create a password.
> - Reinstalled Ubuntu Studio 20.04 with the same settings as before
> (erasing everything.)
> - Reinstalled Deja Dup.
> - Used Deja Dup with the password to successfully restore the backup.
>
> This indicates to me that you are right, Bob. The password was the
> password. There is no other key that's being created and stored somewhere.
> It also would seem to indicate that the password is somewhere on the backup
> drive, but I don't have any idea where on the drive that would be.
>
> So either I am misremembering the original password, as you suggested,
> Bob, or there is some other issue. I have seen comments online about a bug
> that cause it to sometimes fail to store the key.
>
> Jim
>
>
> On Mon, Aug 24, 2020, 3:51 PM DJ-Pfulio via Ale <ale at ale.org> wrote:
>
>> If you have backups, but have never attempted to restore them onto a new
>> system, you don't actually have any backups. You have "hope and prayers."
>> We know how well that works.
>>
>> IT pros get called into clients all the time where they've been doing
>> backups for years, but never tested them. Turns out all that time and
>> effort was useless because of some small issue. Corruption, constant
>> failures the last 5 yrs, missing encryption key, so key part of the data
>> not included in the stored backups.  There's always something. Always.
>>
>> If you've never tested the restore for your backups, in a clean-room
>> environment, then it is highly, likely that they won't work.
>>
>> Of course, if you have the money and time to clone 50 HDDs to have 50
>> backup versions, fantastic.  1 copy is great, but what happens if a file
>> gets malware and nobody notices for 60 days?  120 days - 180 days of
>> versioned backups are pretty easy and really don't take much storage.
>>
>> Cloning is the brute force backup method. Extremely wasteful and
>> unnecessary for Unix systems. I'd love to know how to have 180 days of
>> cloned storage for high risk systems.  Whereas versioned backups for the
>> email gateway here are:
>>          Time                       Size        Cumulative size
>>
>> -----------------------------------------------------------------------------
>> Sun Aug 23 01:30:02 2020         63.1 MB           63.1 MB   (current
>> mirror)
>> Sat Aug 22 01:30:02 2020         1.86 KB           63.1 MB
>> Fri Aug 21 01:30:02 2020       496 bytes           63.1 MB
>> Thu Aug 20 01:30:02 2020       895 bytes           63.1 MB
>> ...
>> Wed Apr 29 01:30:02 2020       788 bytes           63.4 MB
>> Tue Apr 28 16:27:34 2020       744 bytes           63.4 MB
>> Mon Apr 27 01:30:02 2020         11.6 KB           63.4 MB
>> Sun Apr 26 01:30:02 2020       866 bytes           63.4 MB
>>
>> That system uses:
>> $ df -hT
>> Filesystem     Type      Size  Used Avail Use% Mounted on
>> /dev/vda1      ext4      8.8G  4.3G  4.1G  52% /
>>
>> Why backup 4G when 64MB will do?  Just sayin'.
>>
>> On 8/24/20 2:45 PM, Jim Ransone via Ale wrote:
>> > David, thanks for the advice!
>> >
>> > Bob, does "single key" mean that my password is the key itself?
>> >
>> >
>> > On Mon, Aug 24, 2020, 2:23 PM Bob via Ale <ale at ale.org <mailto:
>> ale at ale.org>> wrote:
>> >
>> >
>> >       From ddging it looks like Deja Dup uses a single key (symmetric
>> cipher).
>> >
>> >     The OP wrote:  "I tried the password and it acted busy for a little
>> >     while and then asked for the password again. Not sure what that
>> means."
>> >
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> https://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20200824/2ee32f1d/attachment.html>