Conference cookie::archive_backup

>"The following postional qualifiers are applied to each include_spec parameter.
>You can specify up to eight separate include_spec parameters per save request."

>The qualifiers in question are for example /BEFORE, /SINCE, /DATE_SAFETY, etc.

>Does this mean one can specify to ABS SAVE whos include specifications have
>different postional qualifiers such as;

>$ ABS SAVE -
> _$ $1$DUA1:[000000...]*.*;*/DATE_SELECTION=MODIFICATION/SINCE=1-JAN-1997, -
>_$ $1$DUA2:[000000...]*.*;*/DATE_SELECTION=LAST_ACCESS/BEFORE=1-JAN-1997/DELETE

>where DUA1's files are not deleted while DUA2's are?
    
    Yes, that is exactly what this means.  Each separate include specification
    can use a set of qualifiers that apply only to that specification (file
    name, disk name).  

    For each include spec that you did not specify any positional
    qualifers, those particular files or disks would be saved using 
    the default qualifiers supplies by ABS. See the documentation for the
    default settings.
    
      
>How does one specify a ABS SAVE that will perform the same thing as a VMS
>BACKUP/MODIFIED/SINCE=BACKUP?
    
    I don't believe that you can do this as a "global" qualifier for the
    entire save request. You would have to specify this for each 
    include spec (file name, disk name) if you did not want to accept the
    default settings.
    
>What are the equivilant BACKUP qualifiers the to ABS SAVE /FULL and /INCREMENTAL
>qualifiers?

    The equivalent OpenVMS BACKUP qualifiers /IMAGE/RECORD for the Full
    Backup.
    
    For the equivalent incremental, you would create the backup with
    the qualifiers /MODIFIED/SINCE=BACKUP/RECORD
    
    Note that these BACKUP qualifiers apply only to OpenVMS systems, and
    not to UNIX or NT clients.
    
    Does this help?
    
    Deb Copeland
    Documentation

\Deb Copeland,

>Does this help?

Yes, thanks!

However when I asked;

>How does one specify a ABS SAVE that will perform the same thing as a VMS
>BACKUP/MODIFIED/SINCE=BACKUP?

I did not mean global per say, however, your comments on equivilant qualifiers
(ABS SAVE /INCREMENTAL = BACKUP /MODIFIED/SINCE=BACKUP/RECORD) answered my
question.  Again Thanks!

\David

If ABS SAVE/INCREMENTAL DUA1:[000000...]*.*;*/SINCE=YESTERDAY is used will the
files saved be those who's modified date is after the each file's backup date or
after yesterday's date?

\David

    
    Actually, the way that ABS handle incremental does not use
    backup/record or
    backup/modify/since=backup
    qualifiers by default.
    
    ABS remembers the date/time of backup and its level (full or
    incremental level) in the catalog and issue :
    
    backup/since="date_time_of_last_full_or_incre"/modif
    
    It does not use backup recording date on the file in the backup command
    by default.
    
    However, you can specify "INCREMENTAL" datamovement type and specify 
    in "object selction criteria" screen of GUI "last backup" - (You can
    get here from the "Include and exclude file specification" window.)
    
    The above action will result in backup/since=backup switch to be
    generated.  However, if you do it this way, you are not letting ABS
    handle the incremental backup.  You are responsible for what file will
    go into the incremental backup.  Thus it is not recommened.
    
    The recommended way is to chose some repetitive scheduling (like weekly
    full and daily inc) and let ABS figure out which files should be in
    incremental backup.
    
    Masami
    

I understand what most of the defaults are for ABS save requests, however,
I'm attempting to automatically translate SLS system backup SBK files into
the closest possible ABS save request.  This requires the use of ABS' CLI
not the GUI.  I'm attempting to understand which ABS SAVE qualifiers take
precedence over others.

If INCREMENTAL and FULL "datamovement type"/"nonpositional qualifiers" use
the equivalent to "backup/since="date_time_of_last_full_or_incre"/modif"
will the use of the positional qualifer SINCE=TODAY override the
"date_time_of_last_full_or_incre" for any include specifications it's
used on?

\Thanks, David

    David,
    
    If you have the ABS V2.1 documentation set, the Release Notes contain
    a section that translates SBK parameters to ABS commands/qualifiers.
    
    If you don't have the docs, copy them from the following location:
    
    COOKIE::AIM$PUBLIC:[ARCHIVE_BACKUP.V21.DOCUMENTS]
    
            
    >If INCREMENTAL and FULL "datamovement type"/"nonpositional qualifiers"
    >use the equivalent to "backup/since="date_time_of_last_full_or_incre"
    >/modif" will the use of the positional qualifer SINCE=TODAY override the
    >"date_time_of_last_full_or_incre" for any include specifications it's
    >used on?
    
    I believe the answer to this is yes.  Positional qualifiers take
    precedence.  However, instead of converting your SBK one-for-one, you
    should be using the scheduling option
    /INTERVAL=DAILY_FULL_WEEKLY.  1 full backup, six incrementals per week.
    ABS does not recommend creating incremental save requests, as stated in
    the documentation.  You should allow ABS to determined which backup is
    needed.  
    
    Deb Copeland

    
    re: .4
    
    Yes, it does.  You can examine the "template" file called
    abs$templates:vms_backup-2.incremental_archive_template. The
    qulifier appear later in the series of qulifiers takes precedence.
    
    I thought SLS managed FULL/INCREMENTAL in the same way ABS manages
    it (based on the date/time recorded by ABS/SLS, the product determines
    which set of files go into the incremental).
    
    Thanks,
    Masami