TIP: Click on subject to list as thread! ANSI
echo: os2
to: Leonard Erickson
from: Jack Stein
date: 1999-08-25 18:18:18
subject: Os2 & Dos

Leonard Erickson wrote in a message to Jack Stein:

 JS>Both a full and an incremental backup delete files in that only
 JS>current files on the system are in the archive.
  
 HG> AFAIK, incremental backup adds new files and updates the
 HG> version on the backup media (if there is a similarly named)
 HG> but doesn't delete files from the backup that have been
 HG> deleted from the source.

 JS> It does if you overwrite the original incremental back up each day.  A
 JS> standard back-up routine is to do a full back-up once per week, and an
 JS> incremental daily, overwriting the incremenatal each day, so it
 JS> contains only files that changed or were created since the last full
 JS> back-up.  This is essentially what you are doing, and is what the
 JS> archive bit on files is used for. 

 LE> ARGGHHH! NO!

ARGGHHH! YES!

 LE> The "standard" scheme you refer to requyires a *seperate*
 LE> incremental backup tape for *each day*. 

Nope, it doesn't.

 LE> Doing it the way you just described woud have a file get
 LE> created on Monday, included on monday's incremental backup,
 LE> and *not* included on Tuesday's backup because it hadn't
 LE> changed on Tuesday. So if you were using the same tape for
 LE> monday and tuesday, you'd no longer have the file backed up.

Note quite.  Doing it the way I discribed does not change the archive bit,
which is your choice when you do backups with RAR or PKZIP.  You change the
archive bit on full back-ups, on daily incremental backups you don't reset the 
archive bit, so each day you get all changed files since the last full backup, 
and files that are no longer on the drive are gone, which is what the original 
poster wanted to happen, and also how I want it to happen, and is how I've
been doing it for years, including when I did tape back-ups.

 LE> This is because the archive bits get cleared by *either*
 LE> sort of backup. 

I guess if you use a back-up application that prevents you from controlling
the archive bit.  I've never seen one of those, most allow full, and both
types of incremental, your method, and my method.  Since I don't use a back up 
application per say, I always have control of turning the archive bit on or
off, so I dictate exactly how it will be done.  For non-critical back-ups,
such as 99% of home users and most business situations, my method is probably
the most common method, and makes the most sense.

 LE> And in fact, for safety's sake, you need a second "full"
 LE> backup tape. 

I don't believe in tape back-ups at all, unless you need off site storage,
which few home users require.  Tapes have been a horrible mess for the home
user using standard cheap tape drives, and all would be better off purchasing
another HD to do their back-ups on, and all that is needed is a free scheduler 
and a decent archiver, such as RAR, and very minimal batch writing skills.

 LE> You alternate between them. That way if the
 LE> drive eats the tape, you still have *last week's* full
 LE> backup, which along with the incremental backups since then,
 LE> will allow you to recreate the system. 

Drives eating tapes, tapes not recording correctly, massive dust problems,
tape drives dying a quick death have been the joke of home tape systems IMO,
and experience.  I've lost 3 tape drives since 1990, and not ONE hard drive. I 
would have to lose two hard drives simultaneously for me to get in trouble,
and that is a very remote possiblity.  Additionally, I can restore any file
almost instantly stored on a random access HD, but it takes forever to load a
tape and search for a file with serial access.  

                                              Jack 
--- timEd/2-B11
* Origin: Jack's Free Lunch 4OS2 USR 56k Pgh Pa (412)492-0822 (1:129/171)

SOURCE: echoes via The OS/2 BBS

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.