DevOps, CI/CD and Automation

I'd assume it would be the same as any other server. The usual problems have to do with file changes due to open applications. If you're running oracle in a zone, you have to deal with oracle.

Just backing up the filesystem from the global zone will grab all the data. Assuming it's quiescent, you should be fine.
Probably the same as any other. I haven't looked specifically at the zone configuration files, but if the global filesystem space is returned, the non-global zone files will return also.

I would imagine that you could alternatively back up each zone as a separate machine, with a backup client that saw only the non-global space. That might make some things easier (like restoring data to a separate machine, rather than being forced to restore the entire set of zones in one go), and some things harder (would take up more space on tape if you're otherwise sharing OS files).

I should try a test on this...

--
Darren

And I did. I had a test system with 2 non-global zones. I backed up from the global zone via Legato Networker. I blew away the system and restored from tape.

As expected, since the data in the zones along with the zone configuration are both visible from the global zone, backing it up that way was fine and everything came back after a restore.

There might be some problems with some specific things, but I haven't found them yet. On the whole, the test was successful.

Doing backup/restore of a single non-global zone via a client in the zone might be a bit tricky with the read-only filesystems. You'd have to get the zone to a point that the backup/restore client could run, then the restore could only be of "local" filesystems.

Good Luck!
--
Darren

Okay, I just realized there's one other caveat here. Some backup technologies might not deal well with the loopback mounts that would be common with zones.

'ufsdump' should be okay, and my test showed Legato networker 6.x to be fine.

Other things like 'tar' and 'cpio' I haven't tested, but they might happily back up data via the loopback mount, leading to duplication of data and potential disk issues on restore.

I haven't tried anything other than Networker yet, but it's something to be aware of.
--
Darren

FYI, I tried both ways to backup/restore a non-global zone : NetWorker and ufsdump. With ufsdump, everything went OK and the non-global booted successfully.

I tried the same thing with NetWorker, but after the restore, when I wanted to boot the zone, I've got the following error : /proc missing. And that's true since the /proc filesystem wasn't taken in backup althought I took a full backup of my server.

What did you do to make your NetWorker restore work ??

I didn't do anything special. /proc isn't a disk filesystem, so I wouldn't expect it to be on the backup. Instead it should be referenced in the /etc/vfstab and should be mounted at boot by the startup scripts.

One thing I did do was not restore over a running system. I booted the machine from a separate disk, newfs'd the original disk, then restored there. When I booted from that partition, everything came up.

Restoring a zone with NetWorker is working. I don't know what happened with my first attempt, but on the second one, all the files was taken is backup and the restore was easy.

Sorry for the first post ...

jeff

G'Day Folks,

There are problems with tar/ufsdump descending down lofs mounts. I now have a section demonstrating zone backup methods that work on,

http://www.brendangregg.com/zones.html

no worries,

Brendan Gregg
[Sydney, Australia]

Thanks. I'm really surprised by the fact that ufsdump has problems here. I wouldn't have thought that it would be confused by an lofs mount, since it's normally reading the bits from the underlying device.

However, I've tried a networker 6.1.3 client. When run on the global zone, it will not descend the lofs mounts, so you don't have to exclude them.

I gave /export/home/zone1 and /export/home/zone2 as savesets. One zone running, one installed. Both backed up about 73MB.

Now if I had a way of keeping 'du' from following lofs mounts, that would be handy...

# mminfo -s <server> -r 'savetime,totalsize,name'
  date         total name
 04/14/05   73546004 /export/home/zone1
 04/14/05   74753880 /export/home/zone2
# cd /export/home
# du -dsk *
78233   zone1
3212767 zone2

--
Darren

G'Day Darren,

Yes - I was suprised by ufsdump decending down these lofs mounts too.

# zoneadm list -cv
  ID NAME             STATUS         PATH                          
   0 global           running        /                             
  10 smallzone        running        /export/smallzone             
# 
# ufsdump 0f smallzone.ufsdump /export/smallzone
  DUMP: Date of this level 0 dump: Fri Apr 15 09:04:08 2005
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rdsk/c0t0d0s0 (lambda:/) to smallzone.ufsdump.
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Writing 32 Kilobyte records
  DUMP: Estimated 6491746 blocks (3169.80MB).
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]

3169Mb on a lofs shared zone is way too big..
...

Ok, so we know networker 6.1.3 is another solution. :)

Brendan

Can anyone suggest how to get EBS (Legato) to backup the following filesystem in a non-global zone?

The file system is defined in the zone xml file as follows: <filesystem special="/dev/md/dsk/d20" raw="/dev/md/rdsk/d20" directory="/var/spool/MD-Quarantine" type="ufs"/>

The global zone does not see this as a file system at all so I cannot back it up with networker in the global zone (it appears as a metadevice only). Having "All" in the "Save Set" field for the non-global zone client in Networker does not back up the filesystem either.

It appears that Legato is not completely aware of some of the finer points of Solaris zones.

Of course as soon as I posted the question, I found an answer of sorts.

Legato seems to use the "mount point" field to determine what "All" means to it. So the easiest thing to do is to put an entry in the vfstab which does has "mount at boot" set to "no e.g.

/dev/md/dsk/d20 /dev/md/rdsk/d20 /var/spool/MD-Quarantine ufs 2 no logging

cheers
Warren

Just to add some information.

I have a zone which has direct access to a disk partition by specifying
an "fs" resource in the config.

fs:
dir: /export
special: /dev/md/dsk/d22
raw: /dev/md/rdsk/d22
type: ufs
options: [nodevices,logging]

This show in the zone as a ufs mount

zone1# mount -v | grep export

/export on /export type ufs read/write/setuid/nodevices/intr/largefiles/logging/xattr/onerror=panic/dev=1540016 on Tue Oct 11 18:18:46 2005

However runing ufsdump fails

zone1# ufsdump 0f /dev/null /export
DUMP: Cannot obtain block name from `/export'
DUMP: Warning - block 16 is beyond the end of `/export'
DUMP: Warning - super-block on device `/export' is corrupt - run fsck
DUMP: The ENTIRE dump is aborted.

fortunatly ufsdump in the global zone on the raw device or mount point insde the zone works


global# ufsdump 0f /dev/null /dev/md/rdsk/d22
DUMP: Date of this level 0 dump: Tue 18 Oct 2005 10:46:47 BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d22 (global:/export/zone/zone1/root/export) to /dev/null.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 63260 blocks (30.89MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 63230 blocks (30.87MB) on 1 volume at 10687 KB/sec
DUMP: DUMP IS DONE

global# ufsdump 0f /dev/null /export/zone/zone1/root/export
DUMP: Date of this level 0 dump: Tue 18 Oct 2005 11:03:55 BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d22 (global:/export/zone/zone1/root/export) to /dev/null.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 63260 blocks (30.89MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 63230 blocks (30.87MB) on 1 volume at 10879 KB/sec
DUMP: DUMP IS DONE

For what it's worth, I've also successfully restored a non-global zone which was backed up from the global zone using Veritas Netbackup 5.0.

Because I have a legacy database which cannot be quiesced, and because I have a nice 1 hour maintenance window, I've just set up a task to run nightly in the global zone which shuts down and duplicates the zone, which I can stage to tape in my own sweet time.

I'm just about to roll a Solaris 10/SPARC Veritas Netbackup Enterprise server attached to an L25 into production.

Dear Sir,

May I know what is your settings to back up a non-global zone from the global zone via Legato?

1) If I specify Saveset : ALL on the client settings, will this backup the data of the non-global zone.

2) I assume in your testing, you installed the Legato backup agent, on the global zone?

Hope you can share some of your testing experience, so that I can test it out to.

Thanks

Chan

It was a while ago. I think for the test I gave the zoneroot as a saveset explicitly.

I think that 'All' should back them up also, but I don't believe I tested it.

Yes, I installed the client on the global zone.

--
Darren