savefs: Cannot retrieve the client resources

Recently, colleague has issue backing up a new client.  The following errors keep coming up.

90088:savefs: Cannot find the NSR group resource named 'Windows'.
90069:savefs: Cannot retrieve the client resources.

From my exp, these are DNS related error.  Check the Command Reference Guide. The 2nd possibility is client is moved to another group during backup.  I know this is not the case.  Check DNS and both forward and reverse lookup are fine.

Eventually, find out this new box is setup to replace another box.  The new box is setup with a different hostname but the alias is the same.  Compare the client instance between the new and the decommissioned one. Find out the alias is entered in the decommissioned client (if you attempt to enter alias on the newly created client, it should give you an error because you cannot have 2 different hosts with the same alias).

All we do is remove the alias that are used by the newly built box from the decommissioned client's aliases field.  Then enter it on the newly created client's aliases field.  Now, backup runs fine without any more issue.

(Another commonly see DNS related savefs error is "nothing to save".  Check and make sure aliases field include the other name if there is more than one aliases or one NIC on the host)

DD4500 Data Movement to archive tier uses all the resources

We have setup a DD4500 for our cloud.  Recently, we see backup running extremely slow with lots of timeout error on NetWorker.  Reboot the backup server, reset jobsdb and tmp do not fix the issue.
Suspect it is something similar to "Cleaning Affects Ingest in 5.2. User Cannot Throttle Down  kb182136".  So contact support and turn out it is the Data movement to a archive tier taking all the resource.

We attempt to change the throttle for Data Movement with help of support but it does not seem to help.  Only option is to upgrade to DDOS 5.4.3.0 or Disable Data Movement.  We suspend the Data movement as a workaround.  Then the backup speed is back to normal.

We finally complete the update of DDOS to DDOS 5.4.3.0, and we no longer see the issue again.