Standalone backup on Alpha? - VMS

This is a discussion on Standalone backup on Alpha? - VMS ; I know that for Alpha you're supposed to use AXPVMS$PCSI_INSTALL_MIN.COM to build a minimum bootable system on some *other* device to boot and run standalone backups. What I'd like to do is just build a minimum bootable root on my ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Standalone backup on Alpha?

  1. Standalone backup on Alpha?

    I know that for Alpha you're supposed to use AXPVMS$PCSI_INSTALL_MIN.COM
    to build a minimum bootable system on some *other* device to boot and
    run standalone backups.

    What I'd like to do is just build a minimum bootable root on my primary
    system disk so I don't have to fuss with a CD just to do backups.

    Anyone ever tried this? Is it feasible?

    /Skip

  2. Re: Standalone backup on Alpha?

    In article , morris@osmium.mv.net (Skipper W. Morris) writes:
    >I know that for Alpha you're supposed to use AXPVMS$PCSI_INSTALL_MIN.COM
    >to build a minimum bootable system on some *other* device to boot and
    >run standalone backups.
    >
    >What I'd like to do is just build a minimum bootable root on my primary
    >system disk so I don't have to fuss with a CD just to do backups.
    >
    >Anyone ever tried this? Is it feasible?


    And what do you do if your system disk fails?

    Regards,
    Christoph Gartmann

    --
    Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
    Immunbiologie
    Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
    D-79011 Freiburg, Germany
    http://www.immunbio.mpg.de/home/menue.html

  3. Re: Standalone backup on Alpha?


    "Christoph Gartmann" wrote in message
    news:ffs3qq$shi$1@news.belwue.de...
    > In article , morris@osmium.mv.net (Skipper W.
    > Morris) writes:
    >>I know that for Alpha you're supposed to use AXPVMS$PCSI_INSTALL_MIN.COM
    >>to build a minimum bootable system on some *other* device to boot and
    >>run standalone backups.
    >>
    >>What I'd like to do is just build a minimum bootable root on my primary
    >>system disk so I don't have to fuss with a CD just to do backups.
    >>
    >>Anyone ever tried this? Is it feasible?

    >
    > And what do you do if your system disk fails?
    >
    > Regards,
    > Christoph Gartmann
    >
    > --
    > Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
    > Immunbiologie
    > Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
    > D-79011 Freiburg, Germany
    > http://www.immunbio.mpg.de/home/menue.html


    Why not just build VMS on a spare disk or, possibly, leave the approriate CD
    in the drive and boot off that? That covers primary system disk failure!

    Regards,

    Roger

    --
    Roger Fraser - CSC Computer Sciences



  4. Re: Standalone backup on Alpha?

    On Oct 25, 7:22 pm, mor...@osmium.mv.net (Skipper W. Morris) wrote:
    > What I'd like to do is just build a minimum bootable root on my primary
    > system disk so I don't have to fuss with a CD just to do backups.


    I know you can do a $BACKUP/IMAGE of the boot CD-ROM onto a disk
    drive, and it becomes bootable. You might want to look at doing that
    and then transferring those files to an alternate root on the system
    disk. I haven't tried it, but there's probably a way to make it
    happen.

    The other thing is to avoid the issue altogether. Move any volatile
    files off the system disk completely. You could then do regular
    backups of that alternate disk, and just a "once-in-a-blue-moon"
    standalone backup of whatever's left on the system disk.


  5. Re: Standalone backup on Alpha?

    On Oct 26, 8:07 am, FrankS wrote:
    > On Oct 25, 7:22 pm, mor...@osmium.mv.net (Skipper W. Morris) wrote:
    >
    > > What I'd like to do is just build a minimum bootable root on my primary
    > > system disk so I don't have to fuss with a CD just to do backups.

    >
    > I know you can do a $BACKUP/IMAGE of the boot CD-ROM onto a disk
    > drive, and it becomes bootable. You might want to look at doing that
    > and then transferring those files to an alternate root on the system
    > disk. I haven't tried it, but there's probably a way to make it
    > happen.
    >
    > The other thing is to avoid the issue altogether. Move any volatile
    > files off the system disk completely. You could then do regular
    > backups of that alternate disk, and just a "once-in-a-blue-moon"
    > standalone backup of whatever's left on the system disk.


    Doesn't that just move the open-for-write files to another disk with
    along with the same problem? If those volatile files are open for
    write -- and they will be -- you've got the same problem whether
    they're on the system disk or another disk. Right?

    AEF



  6. Re: Standalone backup on Alpha?

    In article <1193401214.005745.299290@o80g2000hse.googlegroups. com>, AEF writes:
    >
    > Doesn't that just move the open-for-write files to another disk with
    > along with the same problem? If those volatile files are open for
    > write -- and they will be -- you've got the same problem whether
    > they're on the system disk or another disk. Right?


    The idea of standalone backup, and of building a bootable system
    on a separate drive, and of booting the CD, is that you can idle
    your systems and close all the files on any other disk than the
    system disk and backup all those fully, but not the system disk.

    So you boot off something else, backup the normal system disk, and
    then boot the normal system.

    All of which means downtime for your system, but gets you a
    pristine image of your system disk.

    Depending on your needs, there a several workarounds. You may be
    able to have application down time. You may be able to shadow
    your system disk and temporarily take one copy off line. You may be
    able to get by with a less than perfect image of your system disk.
    You may have multiple system disks in a cluster and dual path them
    solely for backup purposes. You may have an intelligent disk subsystem
    that can snapshot data for you. You may be able to get the downtime
    for one system because your cluster keeps the application up.

    I'm sure there are others.


  7. Re: Standalone backup on Alpha?

    Bob Koehler wrote:

    > You may be
    > able to get by with a less than perfect image of your system disk.


    I've many times runed /image backups online from system
    disks, both for "backup" but also for building a totaly
    new/separate system. I can not recall a single time when
    an online image of the system disk was unusable.

    Of course, it might help if no system manager is doing
    UAF-type of work during the backup...

    Jan-Erik.

  8. Re: Standalone backup on Alpha?

    On Oct 26, 8:37 am, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article <1193401214.005745.299...@o80g2000hse.googlegroups. com>, AEF writes:
    >
    >
    >
    > > Doesn't that just move the open-for-write files to another disk with
    > > along with the same problem? If those volatile files are open for
    > > write -- and they will be -- you've got the same problem whether
    > > they're on the system disk or another disk. Right?

    >
    > The idea of standalone backup, and of building a bootable system
    > on a separate drive, and of booting the CD, is that you can idle
    > your systems and close all the files on any other disk than the
    > system disk and backup all those fully, but not the system disk.
    >
    > So you boot off something else, backup the normal system disk, and
    > then boot the normal system.
    >
    > All of which means downtime for your system, but gets you a
    > pristine image of your system disk.
    >
    > Depending on your needs, there a several workarounds. You may be
    > able to have application down time. You may be able to shadow
    > your system disk and temporarily take one copy off line. You may be


    While this is probably better than a hot backup of the system disk, a
    disk removed from a shadow set is considered "improperly dismounted"
    and may still contain -- but I'd think is much less likely to --
    inconsistincies.

    > able to get by with a less than perfect image of your system disk.


    I've never had a hot system disk backup that didn't boot. But I think
    there is a chance that some inconsistencies may exist between
    SYSUAF.DAT and RIGHTSLIST.DAT, for example, or in the queue files. But
    I don't recall ever having that problem. I suppose you could also end
    up with problems with accounting, audit, and operator files.

    > You may have multiple system disks in a cluster and dual path them
    > solely for backup purposes. You may have an intelligent disk subsystem
    > that can snapshot data for you. You may be able to get the downtime
    > for one system because your cluster keeps the application up.
    >
    > I'm sure there are others.


    AEF


  9. Re: Standalone backup on Alpha?

    OK, different slant:

    What is truly needed to make a bootable disk ?

    Could the following work ?

    create a [SYS0]
    and copy to it:

    [SYS0.SYSEXE],

    and the VMS$COMMON version of:
    [SYSEXE]
    SYS$LDR
    SYSLIB
    SYSMGR

    (so all those would reside directly under [SYS0])

    use WRITEBOOT to make that disk bootable, and then use SYSGEN to make
    that system minimal (no cluster, STARTUP_P1 = MIN, no page/swap files etc) ?

    On Microvax, there was no VMS$COMMON/SYS$COMMON hiearchy, everything was
    directly under SYS0. For Alpha, would there still be that capability to
    find everything under [SYS0] or is there some harcoding that requires
    those directories to reside in [SYS0.SYSCOMMON] AND [VMS$COMMON...]
    (aka, the aliases) ?

  10. Re: Standalone backup on Alpha?

    In article , JF Mezei
    writes:

    > On Microvax, there was no VMS$COMMON/SYS$COMMON hiearchy, everything was
    > directly under SYS0.


    Microvax is hardware; what you are referring to is a software issue.


  11. Re: Standalone backup on Alpha?

    Phillip Helbig---remove CLOTHES to reply wrote:
    > In article , JF Mezei
    > writes:
    >
    >> On Microvax, there was no VMS$COMMON/SYS$COMMON hiearchy, everything was
    >> directly under SYS0.

    >
    > Microvax is hardware; what you are referring to is a software issue.


    Sorry, I had meant MicroVMS.

  12. Re: Standalone backup on Alpha?

    Phillip Helbig---remove CLOTHES to reply wrote:
    > In article , JF Mezei
    > writes:
    >
    >
    >>On Microvax, there was no VMS$COMMON/SYS$COMMON hiearchy, everything was
    >>directly under SYS0.

    >
    >
    > Microvax is hardware; what you are referring to is a software issue.
    >


    Perhaps he meant "MicroVMS". This was a version of VMS intended to run
    on the various MicroVAX machines. I believe it omitted support for
    Unibus, MassBus and other stuff that just didn't exist in the MicroVAX
    world.


  13. Re: Standalone backup on Alpha?

    I do disk to disk backups (on my AlphaServer 800's) using
    backup/data=compress. I am pretty sure that the V8.3 CDrom can't read
    those backup savesets (that format did not exist when 8.3 was released
    AFAIK). So, to be safe, I did this:
    (1) shut down, booted from 8.3 CDrom. [DKA400:]
    (2) did a backup of a second disk (DKA200:, with a lot of free space)
    onto a saveset on third
    disk DKA300: with even more free space (Backup /image /verify)

    (3) did a backup/image/verify of system disk to the second disk (disk
    to disk, wiping out
    the previous contents).
    BACKUP /IMAGE /VERIFY DKA0: DKA200:
    (4) booted from DKA200:, changed label back to previous label; edit
    startup files.
    (5) restored contents of DKA200: from the saveset on DKA300: One or
    two issues around certain system/security files, but it worked fine. I
    obviously did NOT use /IMAGE when I restored the saveset from DKA300.

    Now, if the system disk croaks, I can boot from DKA200: and restore a compressed
    saveset from DKA300: (a 300GB drive which holds a lot of backup
    savesets). to DKA0:

    I've tested this and it works as expected. A small benefit: booting
    from a SCSI disk is
    so much faster than booting the VMS distribution from CDrom. HTH.

    Carl Friedberg

+ Reply to Thread