Solaris

I just want to backup whatever file system is in the root disks, just in case those fail. I use

Code:

solaris 10

---------- Post updated at 01:50 PM ---------- Previous update was at 01:49 PM ----------

its solaris 10

Code:

ufs

Solaris 10, yes, and is the root filesystem ufs or zfs?

---------- Post updated at 12:37 PM ---------- Previous update was at 11:51 AM ----------

Right then, I get the question; there could be many answers and every professional could have a different opinion. You asked for ideas to be shared so here goes.

The scenario I've faced many times is that I have a very big system with lots of non-root filesystems and tons of storage. Minimum down time is critical but suddenly the system won't boot. I just want to get the system on its feet so that I can take a look around.

Backup:
1. Create a NFS share on a remote system and mount it
2. Pick a fairly quiescent time and 'fssnap' the root filesystem (to freeze it temporarily) sending the journal ('backing_store' switch on fssnap) to one of your other local filesystems.
3. Run 'ufsdump' to backup the whole filesystem to the NFS storage.
4. Make a note of your ip interface name (eg, e1000g0 or whatever)
5. Make a note of all the VTOC's

Note that you need to gauge the frequency of doing the backup because, in the event of a recovery, new users, groups, security changes and patches will be mssing.

Recovery:
Suddenly the system won't boot so.....
1. Boot from CD into single user:

Code:

boot cdrom -s

2. Use 'format' to check disk visibility and check slicing of disks.
3. After confirming that local recovery (eg, fsck, etc) will not fix the issue, 'newfs' the root disk slice. Root filesystem is now empty.
4. Mount the new empty root filesystem under /a
5. Use 'ifconfig' to manually 'plumb', 'address' and 'up' your network interface.
6. Check that you can ping the NFS node holding your ufsdump(s)
7. Mount the remote NFS storage under /mnt
8. Change directory to the top of your hard disk (empty) root
9. 'ufsrestore' the backup from the NFS storage to the root hard disk
10. 'sync' and 'umount' the NFS storage and the root hard disk and do an orderly shutdown.
11. System should now boot.

Note that if your /usr filesystem is separate from the root filesystem you should consider backing up that for emergency recovery too since without being able to mount /usr the recovered system will probably go into maintenance if it cannot mount /usr

As I say, all professionals have their own opinion and you may well get a torrent of alternatives posted to this thread. You may also have further question about what I have written above. Feel free to ask.

You could, of course, use 'flarcreate' to create a flash of just your root disk filesystem and that is certainly a good option. The above is just the method that I have used on Solaris 10 with ufs. You can, of course, test your recovery procedure by using a dummy root slice elsewhere on the system (not the real one).

Hope that helps.

Thanks a lot for your input. I will investigate the

Code:

flarcreate

command.
As an example, the above is what I want to backup, in order to recover if the root disk fail:

Code:

bash-3.00# df -h
Filesystem             size   used  avail capacity  Mounted on
/dev/dsk/c1t0d0s0      9.8G   493M   9.3G     5%    /
/devices                 0K     0K     0K     0%    /devices
ctfs                     0K     0K     0K     0%    /system/contract
proc                     0K     0K     0K     0%    /proc
mnttab                   0K     0K     0K     0%    /etc/mnttab
swap                    15G   1.7M    15G     1%    /etc/svc/volatile
objfs                    0K     0K     0K     0%    /system/object
sharefs                  0K     0K     0K     0%    /etc/dfs/sharetab
/dev/dsk/c1t0d0s3      9.8G   3.6G   6.1G    38%    /usr
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1
                       9.8G   493M   9.3G     5%    /platform/sun4u-us3/lib/libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
                       9.8G   493M   9.3G     5%    /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
fd                       0K     0K     0K     0%    /dev/fd
/dev/dsk/c1t0d0s4      9.8G   108M   9.6G     2%    /var
/dev/dsk/c1t0d0s5       49G    80M    49G     1%    /tmp
swap                    15G    56K    15G     1%    /var/run
/dev/dsk/c1t0d0s6      9.8G    38M   9.7G     1%    /opt
bash-3.00#

ufsdump will take a complete backup of the slice, everything, exactly as it is facilitating an exact recovery to that position, so includes the likes of /platform, /dev, et al.

Full recovery of the hard disk root filesystem slice will make the O/S bootable (except for the note I made about /usr). The system will then be bootable so you can look at all the non-root (non-O/S) stuff to decide whether non-root's are repairable or also need to be recovered.

Your post shows that your /usr is, indeed, separate, so you should ufsdump that too. In the event of an emergency recovery, ufsrestore the root slice first and then, if it goes into maintenance, ufsrestore the /usr slice too.

So is this a single disk server then? It would seem so.

It might be worth taking a partition map too to aid your recovery if you have to slice a replacement disk. If you run format you will probably get a list of one disk, c1t0s0. Select it, then go for Partition, then Print. This detail can be useful for ensuring your restore will fit the space you might need to reallocate following a completely failed drive.

Keep it with your dump files on another server, and whilst you are at it, keep more than one copy and refresh them regularly.

Some questions that remain:-If so, then the dump files of server A will get included in the dump of server B and written back to server A, then the next backup of server A will get the image of server B including the images of server A, so these would grow exponentially.

Have you got a server or pair available just to hold the dumps of all the others? Although it was a little flippant, my suggestion is still to buy a tape drive. That way, you can get your copies off-site in case you lose the building to fire/flood/engineering/power cut etc.


Robin

@rbatte1.....I was assuming there was no tape on this one system not that there was no tape on the site.

@fretagi.......what is the site backup strategy?

For this particular server which I am still building it, I will have all its file systems on a NetApp, and it will host a oracle database. A full backup of the database will be required at the end of each month, but I am not sure about the end of the week.