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
midrange.com
