iskinner has asked for the wisdom of the Perl Monks concerning the following question:

Using the search feature, I found this thread.
Disaster Recovery

I was hoping to follow up on the suggestions in that thread about creating a local repository that could be backed-up and restored.

Could somebody with experience with Active State on Windows Perl features provide some more details or links to information on how one might go about creating a local repository and/or the .exe file that could be used to restore a server with all the modules in a recovery situation.

Thank You
Ian

Replies are listed 'Best First'.
Re: Disaster Recovery follow up.
by JavaFan (Canon) on Aug 12, 2009 at 01:11 UTC
    Losing a single server isn't what typically is called a "disaster". That's business as usual. Your datacenter being flooded, or a plane crashed into it (why are many datacenters build near airports?), that's a disaster. Then there's no "local" left. Not only is your hardware gone, some of your most valuable employees may be gone as well.
[reply]
Re: Disaster Recovery follow up.
by ssandv (Hermit) on Aug 11, 2009 at 16:15 UTC
    Disaster Recovery

    Please have a look at Markup in the Monastery. Following the instructions there on how to format your post will make it easier for others to read and understand what you write, which makes it much more likely you'll get useful feedback on the actual subject matter.
[reply]
Re: Disaster Recovery follow up.
by Marshall (Canon) on Aug 12, 2009 at 05:59 UTC
    I am striking this post because some Monks have objected to it as "being off topic".

    Recovering from a "disaster" is beyond the scope of Perl.

    Simply put: Perl is just not going to help.

    The "care and feeding" of a server farm is beyond what I can explain here. I would hire some pros to do this and its not that expensive as this is a very competitive market.

    A Windows server is gonna crash at least once per month ( Hey, at least due to the monthly "re-boot" from Redmond, WA) and probably a lot more often than that!

    Keeping a Windows server farm "alive" and "on-line" is a job for Pros. I think you would be lucky if a Windows server only dies 20x per year. This has nothing to do with Active State or Perl.

    Update: My Win XP machine just crashed and yes I consider a "mandatory re-boot" as a crash. I've had *nix boxes run for a year without re-boot. A Windows server will die more than 20x per year. These Windows boxes are finicky. Don't try to muck with a bunch of them by yourself. This has nothing at all to do with Perl.

    JavaFan has got it right.

[reply]

      Apparently the intent of my question did not come across well!

      I am asking for help or guidance on how one can easily capture all the various Perl modules installed through the Active Perl PPM interface so that they can be restored to a new box, if the current one becomes completely unavailable. That is how the State of California defines "Disaster Recovery"

      The thread I referenced in my first post, spoke of creating a local repository and|or executable file that would contain the modules. This repository or file could then be stored for back up and used for recovery. What I have not yet found is some basic instructions on how one actually does either one of these options.

      TIA Ian.

[reply]
        Hi Ian, I did get some messages that indicate that some folks are interested in this even if a bit "off topic".

        One place for you to start with with PPM (the Perl Package Manager) for ActiveState. There is a GUI version that starts by default if you just type >PPM. Type >PPM help at command line to get some help.

        I just did a <PPM list on my machine. This produces a listing of all installed pages, version and location on the machine (site, Perl), etc.

        I have 223 installed packages (aside from what comes with the AS distribution). I suppose in theory if you have that list, you can automate the re-installation of these packages. There of course, some "gottchas". Examples

        1. I had to do some manual steps to get SSLeay installed right (some DLL's had to be moved/copied around)
        2. Other manual steps to do things like associate .pl,etc extension as "runnable" in Windows.
        and the list goes on...and on...

        A "solid" disaster recovery strategy will require a lot of work and testing. The most important part is the actual code that you have written! Great backup and OFF SITE backup of the data is critical if you want to survive fire, etc.

        If you are "re-creating" a machine without a backup, this can take a LOT longer than you think!

        I sometimes build custom machines for other folks. When I get the hardware all installed and working, then I start a .doc of the SW installation and config process. Somewhere about 100 steps is typical. Usually I can't get it "perfect" on the first attempt (for some complex hardware there are performance and feature trade offs even for low level drivers). So I modify my 6-8 page "installation" doc. Then wipe HD and run down checklist all over again. Usually this takes 10-12 hours to do all the steps, even with this exact script, experience of having done it before, etc. I test machine. Make a super disaster, set of DVD's. Then I wipe HD and use my custom recovery DVD's (takes like 30 min as an easy thing vs 10 hours of careful work). That's what happens just so I can make sure that I re-create the machine as delivered as "the last resort". I rely upon data backups to go from there to a "working system" in disasters.

        I am saying not to underestimate the time that you've spent installing and configuring SW gizmo X! Lots of folks don't realize how long this takes in total as they do an hour here or there. Solve some frustration that took them 3-4 hours last year, etc. I would concentrate on getting reliable full backups of SW and critical data. You want to be in a 30 min situation instead of a 10 hour deal.

        I would be curious as to how you do with the hint above that shows how to list installed packages.

[reply]

Back to Seekers of Perl Wisdom