Mandatory FS for mksysb

UNIX AIX
1

Hi all,

my first post. Be kind to me and to my english writing (i'm french) :slight_smile:

During mksysb backup, some files are moving. I don't know yet which files (i'm starting a new job). For now, i'm wondering which fs are mandatory for a mksysb backup.

Currently, hereafter the content of rootvg :

hd5                 boot       1       2       2    closed/syncd  N/A
hd6                 paging     66      132     2    open/syncd    N/A
hd8                 jfs2log    1       2       2    open/syncd    N/A
hd4                 jfs2       63      126     2    open/syncd    /
hd2                 jfs2       95      190     2    open/syncd    /usr
hd9var              jfs2       25      50      2    open/syncd    /var
hd3                 jfs2       16      32      2    open/syncd    /tmp
hd1                 jfs2       4       8       2    open/syncd    /home
hd10opt             jfs2       26      52      2    open/syncd    /opt
hd11admin           jfs2       4       8       2    open/syncd    /admin
livedump            jfs2       8       16      2    open/syncd    /var/adm/ras/livedump
loglv02             jfslog     1       1       1    closed/syncd  N/A
lvnim02prod00       jfs2       4       8       2    open/syncd    /prod
lvnim02log00        jfs2       63      126     2    open/syncd    /log
lvnim02logNM00      jfs2       62      124     2    open/syncd    /lognmon

Have a nice day
Pat

2

As the MKSYSB backs up just the ROOTVG it is generally thought the filesystems will be the default JFS2. Can you be more specific which files are disappearing? Have you any other VGs defined such as a datavg perhaps which of course will not be backed up by the MKSYSB.

I just had another look at the listing and question where the nim02 files /prod, /log, and /lognmon are? On a different VG perhaps? However if this is a listing of rootvg how can they be? Please let us know whether there are any more VGs defined.

1 Like
3

When i wrote files are moving I mean that somes files are updated during mksysb process. Sorry for the mistake.

No datavg present, only a nimvg :

LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
lvnim02spot         jfs2       40      40      1    open/syncd    /nim/spot
lvnim02lpp          jfs2       196     196     1    open/syncd    /nim/lpp
lvnim02mksysb       jfs2       3200    3200    1    open/syncd    /nim/mksysb
loglv00             jfs2log    1       1       1    open/syncd    N/A
fslv00              jfs2       20      20      1    open/syncd    /aixconfig
fslv02              jfs2       120     120     1    open/syncd    /essai
lvnim02viobacku     jfs2       79      79      1    open/syncd    /nim/viobackup
loglv01             jfslog     1       1       1    closed/syncd  N/A

I guess it would be a good idea to have one or to use /etc/exclude.rootvg file.

4

OK now we can explore which files are changing and why. Which files are being altered? This is generally why the MKSYSB is only performed when there is very little system activity.

5

An mksysb file consists of 4 parts:

  • a boot block (empty if the output is to a file)
  • a minimal OS used to restore the system to bare metal
  • a TOC (empty)
  • the output of a regular savevg rootvg , which is in backup file format

You can exclude certain files/directories by using the "-e" flag and an exclude file (entries there follow the regexps for "grep"), but that is not obligatory. It is to speed up the process and make the image smaller, but you should it apply only once the process as a whole works.

Note that you have to have enough free space in /tmp to hold the boot block (use the bosboot command to find out how big that is) during backup AND restore. You can use the "-X" flag to automatically adjust the size of /tmp .

Note also, that there is a file /image.data , which records the sizes of the various LVs/FSes, which mksysb uses. It is possible to use this file to make FSes smaller in the backup (and hence the restore) than they are on the original system. This file is created by the mkszfile command and can be modified by hand to create certain results. The downside is that you are responsible for having a file which at least works - mksysb doesn't check that. If unsure create it directly prior to the mksysb run either by calling mkszfile by hand or using the "-i" flag of mksysb , which calls this command automatically.

The process of backing up a VG is - like any other backup - a relatively static process. unlike with a database, there is no "transaction log" in a filesystem and hence the backup is prone to inconsistencies if files are changing during backup. This is why it is advisable to have transactional data NOT in the rootvg and take the backup during times of minimal activity.

I hope this helps.

bakunin

1 Like
6

Hi all,

thank you for your help. The adminsys will give me the names of the files which are updated during mksysb process. We already have some names : Tivoli software.

I've suggested the adminsys to have a datavg and he will work on it.
I will come back here when I will have some fresh news.

Thank You :slight_smile: