This functionality can be put into a reusable tool.
As issue #8 touches upon, we need to decide where to store these backups, how long between backups, etc.
It's also a good idea for us to periodically test the backups to make sure we can restore from them.
A particular challenge comes from the data mappings of a user being on the AimLogin database. A solution is to create backups of both at the same time, and ensure they're stored together.
It'd be worth seeing if we can prevent the databases from perform any action until the backups are complete, as there's a possibility of: LivestockDb is backed up, AimLoginDB is modified, AimLoginDb is backed up, the backups are now out of sync.
Ties in a bit to issue #8.
This functionality can be put into a reusable tool.
As issue #8 touches upon, we need to decide where to store these backups, how long between backups, etc.
It's also a good idea for us to periodically test the backups to make sure we can restore from them.
A particular challenge comes from the data mappings of a user being on the AimLogin database. A solution is to create backups of both at the same time, and ensure they're stored together.
It'd be worth seeing if we can prevent the databases from perform any action until the backups are complete, as there's a possibility of: LivestockDb is backed up, AimLoginDB is modified, AimLoginDb is backed up, the backups are now out of sync.