Originally posted by: Wouter Liefting
Technically there is no issue with creating an mksysb while the system is active. The mksysb tool just reads files as they are on disk, and that can be done in parallel with other user tasks.
However, what you're backing up are the files in their current state. If a user does a moderately complex task which touches several files over time, and which leaves these files in an intermediate, potentially corrupt state in the meantime, then you are backing up the files in that corrupt state.
This is typically not an issue with regular users who only do vi and such, but can become a major issue if your system is running a database. In that case you need to consult the DB owner and see what can be done about it. There are a few solutions:
- The DB is not backed up as part of the mksysb but uses its own tools to make a consistent backup
- The DB is stopped temporarily while the mksysb is being made - this ensures the files are in a consistent state.
- The DB is put in some kind of direct I/O state, which ensures that the DB files on disk are kept in a consistent state while the backup process runs. This typically leads to degraded DB performance, as write caching cannot be used anymore.
Fortunately proper AIX installations do not put the DB files in the rootvg, so mksysb won't touch them. But even if your rootvg contains user/application data, most backup schemes use a two-stage approach. The mksysb is just to back up the OS, and another process, possibly based on TSM or similar, is used to backup the user/application data. When doing a restore, the mksysb restore gives you a working OS, after which you restore the user/application data. So the fact that your mksysb holds potentially corrupt user/application data is of no consequence.
#AIX-Forum