We are using D3/NT 7.4.6

We run a complete file save every night. The program executes the SAVE
command with the options "STF".

The resulting save (to a pseudo tape device) is around 14GB.

Today I performed an incremental save to a brand new pseudo tape device
(i created the file from scratch) and the resulting incremental was
also 14GB.

It looks like it is saving everything. Has any one else encountered
this or am I doing something wrong?

Cliff

Check to see if 'set-incremental-off' is in any of the boot routines. You
may need to do a 'set-incremental-on' so that changes made to the data are
tracked.



"Cliff" <cponce (AT) easternmetal (DOT) com> wrote

I have always questioned the "benefit" of incremental saves, especially
out to pseudo devices.

What do you hope to save? Time? In my experience an incremental save
takes nearly as long as a full save.

Why are you doing a backup? To avert a disaster, and in the even of a
disater, you want to get your system UP & functioning ASAP.

So, what happens with your incremental save in the picture? You restore
from the last FULL backup, and THEN you get to restore from the
incremental save. At the most critical time of the shooting match, when
you are actually IN THE MIDST OF A DISASTER, youy are consciously
adding to the time taken to get your system functioning again !

You extend your recovery time by the period of time that it takes to
run the incremental, and on a "busy" system, that can be HOURS.

Your system, your call.

The other thing I'd suggest, if you don't already do so, is to add a
"b" option to your save if you make use of B-tree indices. Anyone who
has seen a restore complete, and then sit there for hours while the
B-tree indices are rebuilt will understand why !



Jeffrey Kaufman wrote:

Ross Ferris wrote:
IAWTP.

--
frosty

Ross Ferris wrote:
Twas an awfully long time ago since I've had to rebuild a system from
the save tapes. In the last 15 years I've probably recovered 1 file I
deleted accidently and a handfull of program source items (again
accidentally deleted). Only time I've seen complete saves being read
was conversion to new machines.

On the other hand I've often been in the stituation where a complete
save caused problems with not enough space on the tape, or not enough
time to perform the save.

Yes you are going to add time in a disaster recovery situation. I
reasoned that if a mulfunction requiring a complete restore occurred
the biggest delay was going to be the hardware supplier scrambling for
(a day?) to replace the bad disks, controller, server. A few more hours
on the restore because of incremental saves would not be the biggest
time delay by a long shot. (You figure in these situations your
probably working thru the night to get things done, a lot of time
waiting, waiting, waiting).
And it not like we had much of a choice, it was incremental or having
the saves killed by the sysadmin when they went too long.

It all depends on your hardware, RAID disks make a big difference.
Probably lost three disks over the years but the RAID coped. Rebuilding
the RAID was a hassle once the disk was replaced. Took longer than a
complete save.

If your running on basically a desktop PC, I guess incrementals dont do
much for you.
And your more likely to need to replace the system (anyone had a PC
last more than 6 years?)
On Big Iron, with files approaching 80GB, it was incremental or
nothing.

regards,
Jeremy Thomson

panzerboy (AT) gmail (DOT) com wrote:
The new Linux systems do not have this problem on the pseudo saves of
system. Hardware for the archive system goes away. It's just a (large)
file. (and burnable but not quite 80 GB. Maybe FTP to a file server.

Again the Pseudo tapes are *much* quicker.

RAID drives/controllers are the only way to go. SATA is getting quick.

I don't use workstation HW for servers, but even on my *home box* it is
a quick restore from the Pseudo D3 saves.

Patrick, <;=)

That's horrible. Until you get it resolved, note that both SAVE and FILE-SAVE
seem to honor a select list on MDS, so you can cut a small 'must - have' backup
of say just the DM account and the account with your company phonebook,
so after a disaster you can restore just that and let people log in to those while
sucking all the other accounts off a full save, and certifying all terminals/printers
work again. File-save also seems to honor (XY options, to include dx / dy files
ad-hoc, but retest this and the select list feature on each new D3 release you get.

Stash that bitsy backup on a cdrom or ftp it somewhere. Small is beautiful.
Along those lines, expect over 3:1 compression ratios with typical d3 data, if
you trust that sort of thing. The shrunken backup may enable additional archival
schemes like transmission over the web on a weekly or monthly basis, or
storage on a dvd. Nothing is quite so galling as having your tape drive die and
your boss says it's too expensive to get a new one asap. Or having it be
'mostly dead,' failing often but not totally inert yet, and hear 'we will fix it when it
gets worse.'

Unless you reset the "modified bits" by doing a full save, each incremental
will be at least the same size as the prior one.
Am I missing something here?
In addition - the Windows file size on an over-write will never get smaller.
Hope this helps.

"Cliff" <cponce (AT) easternmetal (DOT) com> wrote

I'd agree with Ross, The value of incremental saves is questionable and the
supposed benefits are few. Not knowing how D3 incrementals work, but I would
assume that the original full save is required first, now what happens if
this errors during a recovery, no doubt you are already under pressure to
get the system back! So if the full backup is required first, why not have
an up todate one and simply restore that.

Believe me when disaster strikes (and it has happened to the company I work
for, remember the oil terminal explosion last Dec. in the UK and disasters
will happen to others at some point.) you have to be comfortable with your
backup strategy as you WILL be expected to get systems backup and running
quickly, we re-built 210 customer machines together with our own in-house
machines within ( I think)7-10days (some within 24hours) of a complete
wipe-out of our data centre, actually our entire head office! Personally I
would always go for a full backup and ensure it's verified! Sourcing
hardware was not the issue in our case, but the time to restore data was!

There are other options (sorry here comes the plug) you can consider to
substantially reduce back & restore times together with the amount of space
they take, for instance Reality customers can now benefit from save &
restore time reductions second to none, for example one user's save used to
take between 3 and 5 hours (depending on fragmentation) now this is down to
around minutes, and it's a save from a known point in time as well, and
that's 50gb of data! Restore times are also comparable to the save times.

So the bottom line is, you have lots of options, which have to be carefully
considered each with their pros and cons, but when it comes down to it the
question is 'what is the risk to the business and how can I reduce this to
an acceptable level?'

There are lots of choices and solutions
Mark
<panzerboy (AT) gmail (DOT) com> wrote

"Cliff" <cponce (AT) easternmetal (DOT) com> wrote

incremental backup only worked for accounts in the vme. {Seen in the
readme2.txt file of the unpacked .exe} If you test with just one account
in the vme, does the incremental seem to work? If so, I guess they never
got around to making it work for the fsi.