SUMMARY: Using Live Upgrade as a Backup Tool

I received a few responses about this. The most helpful was from
Nick Bone (awesome name, man) who pointed out the lumake(1M)
command. This command builds a new BE, but is a step back from
an all-out lucreate(1M). It even has built-in features to run
as an at-job and email the results to a specified address.
However, what I ended up with was a cron job like this,

  # Backup system to alternate disk.
  10 12 * * 0 logadm -p now backup; date; lumake -n disk2 -l
/var/log/backup.err -o /var/log/backup.log; date

To set this up I had earlier used lucreate(1M) to make the initial
"disk2" BE, and created a logadm.conf entry,

  # logadm -w backup /var/log/backup.log /var/log/backup.err

I added the date(1) commands to easily see the start and finish
times in the email cron(1M) kicks out.

I had one response recommending using Flash Archives rather than
Live Upgrade as a backup tool. Unfortunately, flars are not
compatible with systems running non-global zones. LU works with
zones. That was a show-stopper for flars.

On 11/10/2009 at 3:50 PM, "Crist Clark" <Crist.Clark@globalstar.com> wrote:
> I'm a little behind the curve here. I'm just now trying to
> figure out the coolness that is Solaris Live Upgrade (LU).
> The documentation covers doing things like release upgrades
> or applying patch clusters pretty well, but I haven't yet
> seen something on using LU to maintain a backup of the
> current Boot Environment (BE).
>
> What we want is to have known-good snapshot of the running
> BE on the second disk. This goes beyond just mirroring and
> other ways to protect from hardware failure in that it
> protects against higher layer problems (e.g. administrator
> totally hosing the system with an unwise "rm -rf *").
>
> We have long had our own scripts that backup the running
> system onto a second disk in the chassis. It seems like LU
> may be a much better way to do this. The obvious way to use
> LU is to simply do an lucreate(1M) periodically, but that's
> what our existing scripts pretty much do.
>
> What would be great is a way to run the lucreate(1M) once
> and then after that use some other LU tools to update the
> inactive BE to be a copy of the active with something less
> resource intensive than copying all of the data from disk
> 0 to disk 1.
>
> Is there something better than doing a new lucreate(1M)
> each time? Anyone know of some Sun docs for using LU in
> this manner, have their own homegrown methods, or pointers
> to third party info?
>
> Also, what is the right procedure to switch to the backup BE
> under these circumstances. We wouldn't be using luactivate(1M)
> (at least not in the usual manner) since the whole point is
> the live system is corrupted in some manner, possibly dead,
> and we want to revert to the old one.
>
> I will summarize any useful responses. Thanks.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers