A "qualified yes but" on the backup question. Ideally backups are run every day. Assuming a five day work week, you start with four tapes labeled Monday through Thursday backing everything that has been flagged as modified on that date. On the Friday you do the same using a range of the last five days as the selection criteria, using a tape labeled first Friday. You recycle the Monday thru Thursday tapes the next week and end with a Second Friday tape. The last working day of the month you use a tape labeled with the name of the month and a selection range to include the total month. The next month you recycle all the weekly tapes as well as the daily tapes as before. The last working day of the year you do a yearly tape selecting all of that years dates. The following year you recycle all of the monthly tapes.
You will note that only things present when the backup is run appear on the tape, thus if something is deleted before the daily, weekly, monthly, or yearly tape is run, it will not be present on the backup tapes. Let's say the files were deleted in November and had been on the system long enough to have been backed up on the October tape. That tape will still be available until the end of October in the following year and file recovery is possible up until the day the Oct tape is recycled. If the files were deleted before the end of the month they were generated you have until that week number tape rolls around in the next month for recovery. The same applies if it didn't make the Friday tape except now your window of opportunity is a few days. If it was deleted before the nightly tape was run, you're screwed.
Backup systems are designed to preserve real valuable data, they do have a limited provision for things deleted in error but if the deletion is done intentionally and no attempt is made to recover, the files are gone with the first recycled tape.
There is another subtle problem. Hard drives are organized into addressable areas which then set the minimum file size. Suppose you type "Hi" into a word processor and save it in a file. The resultant file would contain the character codes for the "H" and "i" and be padded with nulls to the end of file marker which would be typically one l kilobyte (997 nulls). Because most emails tend to be fairly short a different scheme is needed to prevent this unnecessary waste of disk space. Your email client software creates folders for you in-box, trash and such. These folders are not the same as the folders created by the operating system. As a matter of fact the OS treats them as files in there own right. When your email software is receiving individual emails it appends them to the "in-box" folder which the OS then treats as a file. The email software creates it's own index into the file "in-box" and packs the individual pieces of mail nose to tail to compress out all of the unused waste space. In other words, the identity of individual pieces of mail is lost once the OS takes control of the file named "in-box". That's why you get those cryptic messages that "The Folder Is Being Processed, Please Wait". The only way to recover the individual pieces of mail from the file is to look through the email client software. For those old enough to remember, it is a "partitioned data base.
Regards,
GtG
PS The system described gives good coverage with a minimum of tapes generated. I suppose you could do a full system backup every night which would give you 99% coverage (anything deleted before the tape is run is gone!), but it would soon exhaust both your budget and your storage space not to mention the problem of knowing what is stored on which tape...
Did you ever think when looking at rack upon rack upon rack of 9-track 6250bpi tapes that “this is as good as it is going to get?”
I know I didn’t.
Somehow, I look back on the automated tape libraries of the 80’s mainframe operations and think “While it looked clunky at the time, at least they actually had a real backup system.”
Today, the problem is compounded by orders of magnitude by laptops and other floating devices...
Thanks for the info.
Copenhagen is certainly a major motive for the CRU data to be leaked when it was.
However, another motive could be what you describe here. Namely, the October 2008 back up data was going to be overwritten in October 2009.
Just a thought.
“””You will note that only things present when the backup is run appear on the tape, thus if something is deleted before the daily, weekly, monthly, or yearly tape is run, it will not be present on the backup tapes. Let’s say the files were deleted in November and had been on the system long enough to have been backed up on the October tape. That tape will still be available until the end of October in the following year and file recovery is possible up until the day the Oct tape is recycled.”””