If NW 19.x backups manually to a virgin media, it will apply the longest retention date!

so this is the very first backup of said client (or is it even a backup server)? Is that occurring when there is no client configurations yet, as I thought that earlier behavior was to use the longest retention related to that client when not specifying any settings (like for example he group in nw8 and before, that might have a retention set on client level for the client definition that was using that group) that NW looks for the longest retention specified within the nw client definitions for that client.

So is that the default behavior if there is no retention set anywhere for this client, hence it will be forced to use this long retention period?

In fact it is the NW server himself with a fresh installation.

So the client is configured with the standard parameters.

When I have a fresh installation I usually define a backup device & media and run a small manual backup as my first one. This is when I discovered this behavior.

noticed that it actually mentions the behavior in the nw19.7 admin guide wrg to "Year 2038 Readiness", due to which Dell would regard this still as a works as designed? Whether it is a wise decision to do so, I won't go into at the moment, but it's behavior is mentioned. At least to me it sounds exactly as the behavior described. I see it mentioned from nw19.3 (which introduced the ~292 billion years forever retention) admin guide onwards in retrospect.

Limitations of the Year 2038 Readiness
The limitations are as follows:
● The maximum browse and retention time is limited to 136 years from the current date of execution for the respective action.
For example, if the current year when the action is executed is 2020, then the maximum retention time is 2156 (2020 + 136) and if the current year when the action is executed is 2021, then the maximum retention time is 2157 (2021 + 136).
● Starting from NetWorker 19.3, the special value of forever time is updated from 19th Jan 2038 to ~292 billion years.
● The forever time from older NetWorker versions is not automatically converted to the new forever time. Refer to the section
Querying save sets for old and new forever retention time for information on querying and updating the forever time to the new value.
NOTE: For the newer backups with the NetWorker 19.7 server with forever as the retention time, update to the new 64-bit value is automatic.
● NMC displays the year in the two-digit YY format, while the NetWorker UI displays the year in four-digit YYYY format.
● When a command line save is initiated from the client and when the client has a resource created on the server and is not associated to any policy, then the default browse and retention time is set to 11:11:11 AM, 29th Feb, 2152 (GMT).

Thank you so much, Barry for passing on this information - of course nobody would have thought about it. And in fact, this has already been mentioned in the NW Admin Guide since NW 19.3.0.

However - and this is not intended to offend you - this statement is hard for me to accept as a solution.

In fact, this behavior has obviously been around for years - just for curiosity I verified that it has already been the same before the 'year 2038 support' has been implemented. Please have a look at the screenshot below. I just did not verify it for years.

In 'good old times' the first a NW did after making NW ready was to run a manual backup to test that the minimal functionality was working. But of course there was no policy implemented at that time.

The obvious conclusion:

A 'bug' is not any more a 'bug' if it has been documented as 'feature limitation' somewhere in the universe of the product documentation. So the unknown bug until NW 19.2.x now became 'legalized' with NW 19.3.0+. This is not funny.

I am glad that my other big issue (scanning a disk device on a DD is much slower than on a local attached disk device) has not made its way into the NW documents .... yet.

"Just give me a reason
Just a little bit's enough
Just a second, we're not broken, just bent
And we can learn to love again ..."

Please Dell EMC - wake up.

I am not that easily offended, internet and all, heheh.

Will not be the first nor the last time that something, in this case a earlier apparent hardcoded undisclosed option/behavior, might he turned into a virtue or feature.

You might recall that the nw nwrecover existed for unix systems at the time, similar like the gui that nowadays only exists on windows.

At first it stopped working with an error, before some time later being stated in later releases as being deprecated. Instead of actually fixing the issue, they simply removed the whole gui altogether (them ux people only use cli anyways, you know).

Too often I heard "that is a feature", whereas I would like to call it what it actually was, a stupid decision/option to begin with...

But the product is foremost ented on adding new functionality, not actually fixing things or improving actual day2day operational issues, that should make life easier.

Still waiting for an official way to create an overview for clients, their configuration settings, what policy/workflow/action the client definition belongs to, to see a simple thing like when the backup start is and even if it is autostart enabled. The same overview should then also show what the client override setting is and what the scheduleis that is set on both client as well on backup action level, to even know what schedule is used.

You know things customers and auditors would like to see. No such option in the nmc nor nwui, to all that in one view. You'd have to click all over the place.

Nsradmin still does not offer any output format that returns just all settings on one line instead of using the "field: value;" syntax with "\" to continue on the next line or ending in a comma and continuing. Got a concat of multiple perl/sed statements to reformat it myself, but always running into issues of constructs that break my reformatting attempt. Not unless run succesful on al nw servers, I'd be confident it actually works.

With nw9 and up this then to be combined with nsrpolicy output matching the protection group in both and then putting that on one line together for all client definitions

Nothing of that kind created in the last 2 decades by neither nw product owner legato, nor emc nor dell. Which should be a basic option for accountability/reportability. Using vproxy based backups using VC tags fir dynamic vm selection makes this even impossible as only when hitting preview in nmc, it will actually show the vm's to which the tag applies. So onw can report about what is in backup but not was is even configured to get it ib backup?

But now I am rambling now...

Ow yeah, still have to find the time to try scanning in a boostdevice to see how bad things might be in our case?

Edit few typo's