I want to make full system backup. Thi is disk layout:
I have also tape with 300 G space so space is not a problem.
I think that the most reasonable way is to use UFSDUMP.
This is no problem for me to maka dump for /opt and /export/home.
Simply umount them and execute:
ufsdump 0ucf /dev/rmt/0 /export/home

But how to umount /usr /var and /(root) slice ? It is imposible.
How can I backup them ? What are the most common ways ?
(all I need to 1 tape)

What I found about / (root) slice is that before backing up system must go to single user mode (init -s) then execute But I am still not usre what to do with /usr and /var ?

Go in single user (or at least stop all applications) and then use snapshots (man fssnap) for all of your filesystems.

Well... what I am afraid of fssnap is this:

It happans to me frequently and I got no idea what is wrong
For sure it is not a reason of "xntpd" - which is turned off.

BTW.
Can I go with system to Single User Mode and then make snapshots for all my fs ?
then bring system back to init 3 and after all make ufsdumps of all snapshots ?

Well, in 99% of the cases the culprit is xntpd, I would double check. If not, that might be another real-time process staying there. You can also try mounting /usr read-only.
No, you need to have at least one non "snapshotted" filesystem where to store the changelogs during the backups.

While it is recommended by Sun, and in principle is true, that you should go to single user, very few Solaris sysadmins ever do that. On production systems, they just can't afford to take it down to single user every night or every week to do backups. The basic idea is that you want your system to be fairly quiet. If there is lots of disk reading and writing activity, database stuff, and applications with stuff in memory that periodically gets written out, then the odds are higher that something about the ufsdump will be inconsistent. While most systems are never totally quiet, using an fssnap snapshot greatly reduces the window of exposure, and in practice sysadmins seldom if ever run into problems doing recoveries from their dumps.

Of course, be sure to test your backups to make sure you can recover from them and that you know how to do it.

I wrote a fairly lengthy script that does backups for Solaris using fssnap and ufsdump that runs off a configuration script so that it is easy to manage. I suppose I should post it somewhere so that others could make use of it. However, I finally switched to using Amanda. After you've done a certain amount of scripting, and have a certain number of systems you have to backup, you reach a point where a more serious application makes a lot of sense. I took my backup script and adapted it into a wrapper for Amanda so that it would do fssnaps before doing its ufsdumps. That wrapper is posted and documented on the Amanda wiki at zmanda.com.

So, if you wanted to try adopting Amanda, it's all available there for you. Or you could just read through the script and its comments to see how I did it. It gets slightly complex when you script it and try to take into account all the various issues that might come up. It does shut down xntpd before doing an fssnap of the root partition, for example, and then starts it up again after taking the snapshot. It also makes sure that the snapshot is on a different partition from the one being snapshotted.

You can find the links to Amanda and from there to my wrapper (in the wiki under user documentation under clients) here http://www.linuxquestions.org/bookmarks/tags/backup

I'm on Solaris 9, but I don't think this has changed.

Is it possible that you simply don't need to specify "-F ufs" when you are deleting the snapshot (-d)?

I chose to use

and then I can use ${WHICHSNAP} in the ufsdump command. Note that if you do a `man fssnap` it won't give all the options for ufs, but rather tells you to look at the file system specific man page. So, then you do a `man fssnap_ufs` and you get all the options.

${P} is the partition I am doing the snapshot of. bs= gives the backing store where the original versions of changed files will get stored if there are changes on ${P} before the snapshot is stopped. In my script, I determine the partition where the snapshot is going to get stored, and that is ${SNAPSHOT}. The ${PALPH} is an alphanumeric construction of the partition that is being backed up that can be used for a file name. So, for example, I end up with _usr_local as a name for /usr/local.

When I'm done, I just do a `/usr/lib/fs/ufs/fssnap -d ${P};`

So, anyway, I never need the `-F ufs` because I'm explicitly calling the /usr/lib/fs/ufs/fssnap. I find using full paths to particular executables safer in scripts in general, but I seem to recall there was some other reason here for explicitly using that version. It was a couple of years ago that I wrote that. It's just been working ever since.

Also, note that if you want all these dumps to go to one tape, then you need /dev/rmt/0n for the no-rewind version of the device.

Hey Choogendyk,
it does not really help - take a look:
I will investigate this deeper on monday.

There is another importand thing which you mentioned:
How should I understand that ? What procedure should be executed ? Is it like:
make snapshot of first fs (/) then backup it like this:
then how to backup another snapshot of another fs (lets say /usr which is in /tmp/snaps/2_snap) on same tape ?

Try `fssnap -i` to see what it thinks it has. If it thinks that /usr is an invalid argument, then it must think it has no snapshot for /usr at this point.

Use `mt status` in between or before ufsdump actions to see where you are. Since you are using /dev/rmt/0 (or 0n), it will default to that. The status will tell you what position you are in on the tape. If you use the device 0, it will rewind after doing a ufsdump. If you use the device 0n, it will not rewind. So, the status after doing a dump will tell you that you are at tape position 1, or 2, or something like that, rather than 0.

You can also use `mt rewind`, `mt fsf 1`, etc. to position the tape.

Especially when debugging, or working out procedures, I *always* use informational commands in between doing other things. So, doing `mt status` and `fssnap -i` should be used liberally if you aren't quite sure what is going on.

Interesting. I went onto one of my Solaris systems to check. Discovered a snapshot sitting there that I didn't know was there (using `fssnap -i`). That solved a problem I'd been seeing in my backups and hadn't had time to investigate.

Anyway, after deleting that one, and doing an `fssnap -i` to confirm that there were none. I did an `fssnap -d /usr/local` and got precisely the same error you have been seeing: "fssnap: ioctl: error 22: Invalid argument". So that confirms that the error means you have no such snapshot.