SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-HELP Mailing List Archives

Return to [ 05 | April | 2006 ]

>> Next Message >>


Date: Wed, 5 Apr 2006 01:01:08 PST8
From: Benedict G. Archer <bga0@sbcglobal.net >
Reply-To: scoug-help@scoug.com
To: scoug-help@scoug.com
Subject: SCOUG-Help: BACKAGAIN/2000 differential backups

In <31298-01345@sneakemail.com>, on 04/04/2006
at 07:49 PM, "Bob" <2lvvuss02@sneakemail.com> said:

>** Reply to message from "Steven Levine steve53@earthlink.net" on Tue, 4
>Apr 2006 17:41:24 PST8

>> >Okay. Just did a test differential backup again, and yes it looks like a
>> >full backup with all files and all archive bits set.
>>
>> Just for sanity, did you check the volume and make sure that there were
>> files on the volume without the archive bit set?

>As I said in an earlier message on this thread a "differential" backup
>does not reset the archive bit.

>In BackAgain there are two methods to do change backup, one is
>"differential" and the other is "incremental".

>Does anyone read my messages? ;-)

Bob, I did read yours and everyone's posts, and understood the logic of the various types of backups, but had the sense of the A flag reversed in my head which made some of what I was saying confusing or worse. The recent failure turned out to not require a major restore. I had messed up the scsi adaptor bios (don't yell at me if my terminology isn't right--mixed up the boot channels on an Adaptec two channel 7899), and was getting messages that the boot sector on boot drive was corrupted and couldn't find an OS. Boot manager was showing a wierd CD device that I don't have. This all happened when I was trying to install the eCS beta and couldn't get the install to go beyond a certain point. Never did solve that. Spent a few days getting things working and not sure just what was wrong, but did recover without having to restore from archives. But the experience scared me and got me onto putting my backup scheme in order.

Because Ray had brought up disadvantages of tapes versus HDs, I did the tests backing up to an empty 17Gb logical, JFS formatted partition on an otherwise empty SCSI HD (where I was intending to install ecs beta). Backing up to a HD is about 8 times faster than backing up to the Travan tape. But the problem seems independent of the media as I saw the same things backing up to the HD as to the tape.

I find that virtually all files have the A flag on. For the following tests I used the attrib command and cleared the A flag on a bunch of files.

Some tests:

1. Just to make sure I had the sense of the A flag right I opened a text file whos A flag was NOT set with epm and saved it. This action caused the A flag to be set.

2. Did a COPY backup and checked catalogs and files. Files were archived whether A flag was set or not and the A flag was not affected by the backup as expected.

3. Did a FULL back up and found that it behaved exactly like a COPY backup, i.e., all files archived (in the catalog) and no A flags changed. Here's where there seems to be a problem. Shouldn't files whos A flags were set have been unset (cleared) by BA/2 when archived? Repeated this experiment a few times both from defined backup parameter sets and from with CLBACK from the command line with consistent results.

4. Did a DIFF backup and found that only files with the A flag set were included in the catalog and A flag not affected. This is as expected (I think).

5. Did a INCR backup and found that it was just like a DIFF backup. The A flags of the files backed up were not changed. This seems wrong too. Shouldn't the A flags of files archived have been unset?

So, when I first posted a query I thought the problem was that the DIFF backup was backing up files it shouldn't. Now it seems rather that the FULL backup (and INCR) is not clearing the A flag. Or, if I said that wrong, marking backed up files as being archived.

I came upon the problem testing my defined backup parameter sets. Did a full backup and then immediatly did a DIFF backup expecting that the diff backup would have little or nothing in it. But it had everything in it that the full archive did, and everyhing in both had set A flags. Maybe I'm not doing something right when I make a full backup?

Thanks again,
Ben

--
-----------------------------------------------------------
Benedict G. Archer
-----------------------------------------------------------

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================


>> Next Message >>

Return to [ 05 | April | 2006 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.