Re: SAV not picking up fresh file in IFS for incremental backup

Patrik:

IBM is fully aware of all the issues (although I don't think too many folks
want IBM spending money on them, or the LUG, CAAC, ISV, and other advisory
councils would be pushing that, and I agree IBM should not spend any time
on it) so I don't look to see any changes. As for the waste of tape, most
of us in the consulting world remind customers that tape is really cheap,
losing objects that are critical is not. If the DR plans for multiple
restore operations that's fine, but that elongates the recovery time
objective, and most customers would rather trade an extra couple inches of
tape for the time to get the system back.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Fri, Apr 15, 2022 at 10:27 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Jim,

thanks for your valuable input!


Am 15.04.2022 um 16:30 schrieb Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx>:

It appears you are relying on the last save parameter to determine if a

file should be saved or not.

Correct.

I think you are running into a problem 99% of us ignore when saving

objects in the IFS, that is 1) Save while active does not really work, and
2) object history dates are not always updated as you would expect them to
be.

Hm. I don't care about save while active, because the only "active" (as in
opened read-write by some job) files here are STG files for my IPCS, and
web server logs. IPCS files will be saved with Save 21 on monthly base
which is sufficient, and the web server logs aren't important.

What exactly are those object history dates you refer to?

I've yet to find a save of the IFS or QDLS that actually honored those

parameters to the extent that it worked as advertised or expected.

So you suggest this is a long standing issue which apparently was never
resolved?

Generally we just save the entire thing (with the omits you have in

place obviously stopping those directories) and be done with it.

This is one possible approach. But I'd love to not go that way, because
(for me) things rarely change in all-but-QSYS.LIB. It seems s a waste of
tape (and drive) wear to save gigabytes of data again and again when just a
few megabytes have actually changed.

I understand the object attributes are what you expect them to be, and

on the face of it, it should work, (Even at V4R5) but alas, in my
experience they never really have.

And nobody did check back with IBM to make them aware?

Incremental saves of the IFS also complicate recovery efforts, although

I'm not sure you are as concerned about that aspect of the endeavor, maybe
so, but a hobbyist machine does not have the same requirements a full
production server might have.

I terms of backup and restore, I'm all but a hobbyist. :-) I have
experienced the pain of data loss once in the past time and since then, a
reasonably solid, and automated backup strategy is a must. The more I use a
machine, the more important is regular backup and easy (!) restore. Some
friends think I'm overdoing but when they face a complicated and
labor-intensive restore from some "shirt-sleeved" backup themselves, they
finally understand my mantra that backup isn't done for peace of mind, but
should be done in a way so that restores are carried out most easily with
the least amount of thinking necessary to get it right, on the fist try.
this goes especially with Windows, when those friends tell me that
reinstalling all those programs, setting preferences, re-entering
passwords, etc. isn't *that* hard. Maybe it's not that hard but it's
duplication of work they have done before and they will sit one day to get
their system back to an usable state.
I will stop ranting now. :-)

That being said, the only complication for IFS restores I see is that the
deletion of objects is effectively undone. But this is not something
happening just with the IFS and incremental saves. Frequent full saves are
a good compensation.

Besides this inconvenience of old data popping up, I expect that restoring
incremental saves overwrites already existing older objects, and also
updates their metadata, such as changes in authority, or owner. Which
additional complications do you see?

Of all parts of the system the IFS is the area where IBM i is the

weakest, hence why so many companies rely on Windows or Linux (my chosen
route) to perform most of the file serving etc.

I see. I'm very aware that IFS performance isn't what I'd expect from a
similarly old machine with "true" hierarchical file systems. But I think I
could expect that if there is a OS included tool providing backup services
that it works as documented, maybe?

I won't debate why the IFS is the way it is, there are architectural

reasons IBM has for all of that, I just accept it, deal with it and move on.

Well put. Thanks!

:wq! PoC



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com