OPERATIONAL DEFECT DATABASE
...
...
BugZero found this defect 316 days ago.
When performing a Linux File Level Restore, using a helper appliance, to restore the database for eDirectory on OES 2023 and higher, the most recent state of the database found within the restore point lacks changes made just before the backup job ran.
This happens because the writes made by eDirectory to the underlying XFS filesystem are cached in memory before being written to disk, and the backup operation only captures data on the disk.
To resolve this issue, enable the Application-Aware Processing feature in the backup job for the Open Enterprise Server (OES) 2023 or later VM. Then, use a pre-freeze script to execute the sync command (see example below). This command will prompt the OS to immediately flush any cached writes to the disk. Implementing this as part of the pre-freeze ensures that the cached writes are on the disk when the backup job begins processing the VM's disk(s). Example Pre-Freeze Sync Script
An alternative solution involves modifying the XFS filesystem settings to prompt the filesystem to flush changes to the disk more frequently. By default, this action is performed every 3000 centiseconds, which is the equivalent to 30 seconds. However, it can be configured to as low as 100 centiseconds, or 1 second. It's important to note that increasing the frequency of flushing changes to the disk may negatively impact performance, depending on the capabilities of the underlying storage system. For additional details, please refer to the XFS documentation for the setting: fs.xfs.xfssyncd_centisecs
