Re: Want ability to restore from failed upgrade.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 23, 2005, at 3:30 PM, Chris W. Parker wrote:

Jason Dixon <mailto:jason@xxxxxxxxxxxxxx>
    on Wednesday, February 23, 2005 12:05 PM said:

Stop right there.  Yes, you should have backups.  But don't rely on
those solely as your backup in case of upgrade failure.  Your focus
should be on building a test system and performing the upgrade there.
Document and test everything.  Then proceed with your production
system upgrade, referring to your documentation and, in the worst case
scenario, restoring from the backups.

Yes great idea!

But this would require that I have another computer available with an
exact copy of my current filesystem on the live server would it not? And
that's what I don't know how to do. If I could configure an identical
system to what I've got running live that would be awesome because then
as you pointed out I could test everything and take notes and then just
restore if something went wrong and start over.


But I don't know how to make a copy of an fs nor do I know if this is
even necessary for a test system. I'd think that would it be only
because if I built a new system from scratch, using the same versions of
software that is on my live server, it would *still* be configured
different than my live server (i.e. configuration file changes long
forgotten about that would not be present on the test system).


What angle should I come at this from?

Your concern appears to be with your application upgrades, as it should be. Ideally, you would create the second system *as* the production replacement. However, assuming you don't have the hardware to allow that, then you should just build an identical system (with regards to the existing legacy applications), then perform the planned upgrade for each part of the system. Once that is complete, and the steps are fully documented (and repeatable), then proceed with the upgrade on the production system.


--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net


-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux