On Sat, Feb 18, 2012 at 4:22 AM, David Cushing
<david.cush...@fundtech.com> wrote:
> I’m looking for suggestions on capturing backups.  Web searches have not
> been overly fruitful.  Most discussion expects to shut down the zone and
> clone it.  I will not be able to shut down the zones.
> The backups don’t need to be 100% perfect.  I can fix issues from open files
> / work in progress.  This is not a production database scenario.  The
> biggest concern is full loss of the LUN.  Secondary concern is stray users
> deleting or corrupting their folders.
> There are separate zpools for GZ and NGZ.  All zones share a single ZFS file
> system but I intend on reconfiguring to have one file system per zone.
> Zones are full root.

Since you seem to be running Solaris 10, I'll only cover that.

You have an easy way to get a crash-consistent image: zfs snapshots.
With all the zones in one filesystem, you can prepare for the backup

zfs snapshot <fsname>@<snapname>

You can have the backup software back up from <fs
mountpoint>/.zfs/snapshots/<snapname>.  That is, if you have
tank/zones mounted at /zones, you would do:

zfs snapshot tank/zones@backup

Then you would have the backup software back up from

Netbackup allows you to automatically run scripts before and after
backups.  You could have the pre-backup script create the snapshot and
the post-backup script could rename (zfs rename tank/zones@backup
tank/zones/backup-`date ++%Y%m%d-%H%M`) or destroy the snapshot.

FWIW, if you are seeing netbackup hang, you could probably use pfiles
and/or truss on the netbackup process to see what it is trying to
read.  If the file is a pipe (see mkfifo), you should configure
netbackup to skip that file.

Mike Gerdts
zones-discuss mailing list

Reply via email to