Restoring to a certain date

Restoring to a certain date

Post by - Bobb » Sat, 17 Jun 2006 01:08:11



Reading about someone's  backup procedure made me think of this:  When
you restore, I assume that you can't restore to a certain date, so in
case I needed to ( tax audit etc) I've always backed up every month to a
new filename. Not being too anal, but disk space / blank CD's are not an
issue for me so it's just as easy...

Big picture: on my backup drive I have a Money Folder: in there I have
M2001 , M2004 , M2006 folders ( for the different versions)
in each of those folders... as I backup each new month I create a new
folder. so in M2004 I have a 2006 folder in there a January, February
folder etc. and as the new month arrives, my backup for that month go
into its own folder. So that if I wanted to restore my info as of Feb
2005 I'd pick the version of Money (M2004) then the 2005 folder, then
the Feb file and as I backup I do overwrite the current month until the
end of the month , so only one file per month. Occasionally burn all of
those to one CD.

Is there a way to do that otherwise ? (Other than restoring " the latest
one" and manually deleting every entry in every account back to Feb
2005 ) If so , I need not do this.

Bobb

 
 
 

Restoring to a certain date

Post by Cal Learner-- MV » Sat, 17 Jun 2006 01:16:13



Quote:>Is there a way to do that otherwise ? (Other than restoring " the latest
>one" and manually deleting every entry in every account back to Feb
>2005 ) If so , I need not do this.

No better way to do that. There is an AsOf selector in the Portfolio
view, but there is no equivalent for regular transactions.

You could enhance that recovery in worst case situations by keeping
a copy in the safe deposit box, or encrypting a copy and having a
friend store the CDR for you.

 
 
 

Restoring to a certain date

Post by Dick Watso » Sat, 17 Jun 2006 02:55:05


Since every report and most other tools allow control over date query, I'm
at a loss to understand the functional--as opposed to *retentive
satisfaction--benefit of doing this. (I do keep multiple generations of
backup--maybe back 18 months or so--but that's only in case I discover that
something got lost/broken and I hadn't noticed it for a while. I'm not sure
what the real probability of such an event is. At some level, if I haven't
noticed it for long enough, it must not REALLY matter, so I accept the
residual risk.)

If you store an encrypted copy, you better be darn sure you know the
password/have the key/preserve whatever tool did the encryption/use some
very standard scheme to encrypt.

A potentially bigger threat over time is loss of backward compatibility of
the apps to use any of this old data. Unless you want to keep lots of museum
piece machines running museum piece software, this is a real issue. (Note
current problems of M06 users upgrading M02 and earlier files...) Likewise,
if you do keep the museum run-able, then you have to watch what media you
use to make sure it's a lowest common denominator. For all of these reasons,
I have taken to storing exported all transactions reports as .CSV on my
archive CD-Rs. I figure IF I can find a way to read the CD-R, surely there
will be a way to get intelligence out of a .CSV a LONG time into the future.
Even then I worry about the permanence of the CD-Rs.




> >Is there a way to do that otherwise ? (Other than restoring " the latest
> >one" and manually deleting every entry in every account back to Feb
> >2005 ) If so , I need not do this.

> No better way to do that. There is an AsOf selector in the Portfolio
> view, but there is no equivalent for regular transactions.

> You could enhance that recovery in worst case situations by keeping
> a copy in the safe deposit box, or encrypting a copy and having a
> friend store the CDR for you.

 
 
 

Restoring to a certain date

Post by Cal Learner-- MV » Sat, 17 Jun 2006 03:51:58



Quote:

>If you store an encrypted copy, you better be darn sure you know the
>password/have the key/preserve whatever tool did the encryption/use some
>very standard scheme to encrypt.

True. Some encryption schemes actually allow you to have more than
one password. That way you could have a very long but memorable one
in addition to a more convenient but forgettable/short-lived one.

I also like to name the archive with something that could serve to
jog my memory of what password scheme was used, tho that meaning
would be incomprehensible.

Quote:

>A potentially bigger threat over time is loss of backward compatibility of
>the apps to use any of this old data. Unless you want to keep lots of museum
>piece machines running museum piece software, this is a real issue. (Note
>current problems of M06 users upgrading M02 and earlier files...) Likewise,
>if you do keep the museum run-able, then you have to watch what media you
>use to make sure it's a lowest common denominator. For all of these reasons,
>I have taken to storing exported all transactions reports as .CSV on my
>archive CD-Rs. I figure IF I can find a way to read the CD-R, surely there
>will be a way to get intelligence out of a .CSV a LONG time into the future.
>Even then I worry about the permanence of the CD-Rs.

I like a self-decrypting archive, but that still depends upon being
able to run an EXE file. That ability would probably be available
even fifty years from now. That does not mean that the current
computers then will be able to do that, I expect there will be some
machines set aside that would make that service available. The
permanence of CD-Rs is a question, but it seems to be better than
magnetic media. 20 years should be enough, since I would expect to
generate such a CDR every few years.

Regarding using straight text data, even within the encrypted file,
that has its merits. Its farther than I plan to go at this point.
Printing a report or two to a text file would seem to be a
reasonable idea.