In the manufacturing of a device each one has to get a unique identifier. So far so good, one can have a file containing the last used ID on a shared drive, or a network-based service managing and assigning IDs so that the uploading of the ID into the device will not be limited to a single workstation.
However, in the case of a total system crash and restoration from backup, one can have a few devices with the same ID, if some devices were manufactured after the backup was made. One could have each workstation save the biggest used ID, and check whether it’s not larger than the one they got from the network, but it might happen that the workstation with the last produced device is not turned on after the crash. One might require workers to write down the last used ID after their shifts, but this doesn’t sound to be fool-proof either.
Is there a best practice besides having multiple services managing the IDs, with at least one of them off-site?
The IDs are large enough (32 bits) compared to the number of devices to be produced to allow for small gaps, but not large enough to go the true RNG way. This way, one can increase the largest ID by a number significantly larger than the amount being produced per day, but how can one keep this “company practice” enforced for possibly decades?
3
Split your 32 bits.
Under normal operation, you count normally using all 32 bit.
When a crash actually happens, you use only the most significant, e.g., 8 bits of the backup, increment that part by two and start from there.
All you need to make sure now is that you backup often enough.
More specifically, often enough to ensure you didn’t use up the whole lower significant part (24 bit in this example) in between backups.
1