Invalid restore date on French system

[rik-lv]

HCL Product Version Which version of the relevant HCL product is in use. Domino 12.0.2 french lang pack on Windows server 2019 French

Describe the bug Hello, I'm not sure it's a bug, may be something to configure but I have an issue on Windows servers in French when I'm trying to restore from third party (Veeam). If I pick up any date in the Dominobackup database, the script ends with an error.

Error Message Exception lors de l'appel de ®ParseExact¯ avec ®3¯ argument(s): ®La chaŒne n'a pas ‚t‚ reconnue en tant que DateTime valide.¯ Au caractŠre C:\dominobackup\DominoRestore.ps1:203git : 1

• $OrigDominoBackupTime = [datetime]::ParseExact($RestoreDate.Trim() + ...

• 
  + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
  + FullyQualifiedErrorId : FormatException

Error: Invalid restore date specified 1

To Reproduce Steps to reproduce the behavior:

1. Open Dominobackup db
2. 3rd party restore on a file
3. Submit restore
4. Wait for a while before getting the error

Additional context Works fine with a Domino server in English

[Daniel-Nashed]

That's going to be difficult to troubleshoot. We can't help with French error messages. But there is a way to customize the date format in the advanced configuration.

It might not be a Veeam specific issue either. Looks like PowerShell handles dates with French locale differently.

The error says that the data cannot be parsed in the PowerShell function. I don't know what the French settings require.

There are multiple ways you could address this:

• Pass the data in a different format with the 3rd party restore date formula
• Change the PowerShell script to English Locale

This does not sound like a search in the Veeam repository is not working in PowerShell. It's already the data conversion in PowerShell which is failing.

You might also want to dump the date in the variable $RestoreDate to see it is passed correctly. It could be even the other way round that the server is passing the wrong date format. This is hard to tell, without running a French environment.

[rik-lv]

Hello, Thank you for your response. With the 3rd party date formula found in your Webina (https://www.openntf.org/Public/presentations.nsf/0/0A1A95B76ADA6B62862587D500702853/$FILE/OpenNTF-2022-Jan.pdf), the mount operation succeeded and I can see the content of the backup in c:\VeeamFLR I have another issue with the restore operation but I think I just have to review the configuration files. It ends with searching for backup tag after mounting [dominobackup_20230110223116.tag]

----- Search Results ----- TARGET : D:\HCL\Domino\Data\restore\database.nsf.DAD FOUND_FILE_PATH : [] FOUND_NOTESDATA : [] ----- Search Results -----

SOURCE: [] Thank you again !

[Daniel-Nashed]

what did you change to make it work? how is the date now? what did it expect?

Without the logs I cannot say if it found the mount. But if you see it mounted on the Veeam server side, this should be working.

Next you have to check where it is mounted and if the script looks into the right volume. Also check if you have more than one volume in the backup.

If there is more than one volume in the backup, you might need to modify the restore mount to only mount the Domino volume or ensure all is mounted and in the right path is searched.

I have seen before that admins took a backup of multiple volumes and the restore mount was wrong.

[rik-lv]

Hello,

Like you have suggested, I have added this date formula in the advanced tab of the configuration document. X:=@If (RestoreDateTime=""; @Now;RestoreDateTime); Y:=@Text(@Year(X));M:=@Text(@Month(X));D:=@Text(@Day(X));H:=@Text(@Hour(X));N:=@Text(@Minute(X));S:=@Text(@Second(X)); @Repeat("0";4-@Length(Y))+Y + @Repeat("0";2-@Length(M))+M + @Repeat("0";2-@Length(D))+D +@Repeat("0";2-@Length(H))+H + @Repeat("0";2-@Length(N))+N + @Repeat("0";2-@Length(S))+S

I have added more logs about the failed restore.

Thank you !

restore_logs.txt restore_db.cmd.txt

[Daniel-Nashed]

the backup is mounted and the logs show exactly where and what is mounted. I can't tell you what happens, because I don't know your backup details. It's really hard to tell from here. I can only give you tips what to look for.

Keep it mounted and remove the unmount for a test and search for the data directory tag file. If the data is there, the next step is to check why the find command does not find the file.

The backup is identified by the tag file.

In theory what can also happen. If the date it wrong it might have found a wrong backup. You will find out by looking into the mounted backup.

I still don't understand what date format you got out of the box and what caused it. But but that the mount works. I still want to understand what is going wrong to help others in future and document it.

[rik-lv]

Hello,

I have another issue with restore process.

The Veeam job is linked with another job doing a tap dedup (secondary target) and the restore process failed with this error in the log:

3/02/2023 16:11:21 Mounting backup restore point: b8d98e62-de25-4182-8a27-d8bc265b3629 Backup Time Local: 23/02/2023 00:04:19 Backup Time UTC: 22/02/2023 23:04:19 Publish-VBRBackupContent : Failed to process restore point b8d98e62-de25-4182-8a27-d8bc265b3629. Job type VmTapeBackup is not supported. Nom du paramŠtreÿ: RestorePoint At C:\dominobackup\dominorestore.ps1:253 char:23

• ... reSession = Publish-VBRBackupContent -RestorePoint $RestorePoint -Tar ...

• 
  + CategoryInfo          : InvalidArgument: (:) [Publish-VBRBackupContent], 
  ArgumentException
  + FullyQualifiedErrorId : PublishVBRBackupContentErrorId,Veeam.Backup.Powe 
  rShell.Cmdlets.PublishVBRBackupContent

23/02/2023 16:11:22 Mount operation finished ( 1,1 seconds )

Thank you for your help.

[Daniel-Nashed]

This does not sound like a Domino integration issue. Please check with Veeam what the underlying problem problem could be. We cannot provide general support for Veeam. We can only help with Domino Backup Veeam integration topics.

I am keeping this open. Please report back what Veeam comes back with.

[rik-lv]

Hello.

I've asked the Veeam support but they told me that they don't provide help on custom scripts.

But I have another Domino server with Veeam and jobs with secondary target in backup jobs and it works on this one ! I just have to specify the time of restore in GMT, not in current time zone.

There is only one last issue, the restore process creates a file with .dad extension and it seems that the restore process is trying to find a file with .nsf extension. [1048:0002-1AE0] 27/02/2023 13:33:40 Restore: Working on [D:\HCL\Domino\Data\restore\jdoe.nsf] [1048:0002-1AE0] 27/02/2023 13:33:40 Restore: Error opening Database [D:\HCL\Domino\Data\restore\jdoe.nsf] : File does not exist [1048:0002-1AE0] 27/02/2023 13:33:40 Restore: Error restoring database [mail\jdoe.nsf] -> [restore\jdoe.nsf] : File does not exist [1048:0002-1AE0] 27/02/2023 13:33:40 Restore: Finished

Is there something I forgot in the configuration ? Thank you

[Daniel-Nashed]

The script is looking for the .nsf file and will copy it as a .dad. The restore server task is working on it and removes the .dad extension.

In your case it looks like the script mounts the wrong backup (when I look into the last logs).

Please don't open support tickets at HCL support for problems like this in parallel. The primary support is using this GitHub project. Support would also send tickets to the team working on the GitHub project.

The logs can be extended adding echo statements. and also on the Powershell script you can add any type of log statements.

Modifying the script should not be too complicated to see in more detail what the problem could be.

It looks like it is mounting the wrong backup. You are mixing multiple problems and I don't know what is solved nor what you really did and what is still open.

Also your last log does not help, because it is just showing the Domino side. The log from restore would be important, too.

[rik-lv]

Hello, Sorry for the duplicate, I'm going to close the HCL case. I've attached the latest restore log from the second Domino server. Thank you for your help. restore_log_20230228_01.txt

[Daniel-Nashed]

You seem to use the 3RDPARTY mode of the restore. The 3rd party restore is intended for Domino aware backup applications, where only the restore front-end of the Domino backup functionality is used.

Veeam integration is a direct integration, where the backup is fully integrated. Since Domino 12.0.2 the integration is implemented using VSS Writer mode.

1. Veeam initiates a backup which causes the VSS Windows back-end to initiate a snapshot
2. The new backupvss server task brings databases into backup mode and later on merges changes into the new snaphot

For a restore you pick databases from the inventor on in dominobackup.nsf. For a 3rd party restore operation you select a database manually and a restore date. There is no inventory involved. This would be example a configuration with IBM Spectrum Protect, where the full backup is performed by their backup agent (earlier called TDP)

The integration scripts on the Veeam side are designed for direct integration. Not for a 3rd party restore integration.

We simplified the configuration with Domino 12.0.2 for the Veeam integration. The backup part is a native VSS implementation. And for the restore case you should follow the new instructions for Windows --> https://opensource.hcltechsw.com/domino-backup/backup-providers/veeam/install_vss_writer/

You have all the components in place already. But you are triggering them in the wrong way from what it looks like.

[rik-lv]

Hi Daniel, You're absolutely right. I was so focused on the 3rd party integration that I didn't understand how integrated the scripts were. It works perfectly now. Thank you very much !

[Daniel-Nashed]

Thanks for you feedback and great it works now. If you see anything that needs to be improved in the documentation, let me know.