Hello Stefan, i assume the only solution will be 1. rename the DC node which is storing the TSM4VE data 2. create a new DC node using the old node name, and reestablish the proxy relationships 3. do a full-backup for all VMs
Regards Uwe -----Ursprüngliche Nachricht----- Von: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> Im Auftrag von Stefan Folkerts Gesendet: Mittwoch, 19. Juni 2019 11:26 An: ADSM-L@VM.MARIST.EDU Betreff: Re: [ADSM-L] Living in the future, wanting to go back (date issue on Spectrum Protect server) Thanks Michael, we are opening a pmr @IBM to see what they will say about it. On Tue, Jun 18, 2019 at 5:01 PM Michael Prix <mich...@prix.one> wrote: > Hello Stefan, > > as far as I know the only possibility is to restore the latest good > backup. > Until some versions ago it was not even possible to start the instance > sucessfully until the time of the last shutdown was reached. I tried > these tests with the 6.x and 7.x versions once or twice and always > ended with a total unusable installation afterwards. ACCEPT DATE isn't > what it has been on 5.x. > > -- > Michael Prix > > On Tue, 2019-06-18 at 08:51 +0200, Stefan Folkerts wrote: > > Hi all, > > > > I've got a new one. > > A customer of ours has set the date of the SP server to December 2019. > > As you may know, it's currently not December. :-) They accepted the > > date change in SP with an accept date. > > Now the issue is when they move the date back to what it actually is > > they get this error: > > > > ERROR ANS4174E Full VM backup of VMware Virtual Machine '<VMNAME>' > > failed with RC=45 mode=Incremental Forever - Full, target node > > name='<DC NODE > > NAME>', data mover node name='<DM NAME>' > > ERROR ANS0328E (RC45) The specified objects failed the merge test. > > > > I fully understand why they get this error and it was fixed by > going...back > > to the future (sorry, had to do it). > > > > So i'm thinking, how do we fix this? > > I was thinking about a script that would change the date each day > > but I don't expect that this is the best solution to this issue, > > renaming all filespaces in VE and then doing new full backups is another > > possibility. > > > > Any other thoughts? > > > > Regards, > > Stefan >
