1748140 Members
4091 Online
108758 Solutions
New Discussion юеВ

Re: backup teaser

 
Willem Grooters
Honored Contributor

backup teaser

Given the following structure:

dev:[A.B] contains directories C,D and E
dev:[A.F] contains directories G, H and I
dev:[J.K] contains directories L, M and N

I want to backup parts of the strcuture: [A.B,C], [A.F.G] and {J.K.L], but in such a way that the top diretories ([A] ans [J]) are excluded. Backup should just contain [.B.C], [.F,G] and [.J.L].
This saveset is to be restored on dev2:[X] and dev2:[Y] to where this strcuture is to be copied.

My feeling is you'll need two savesets: one based on [A] and one based on [J]. But perhaps, the experts can specify a way to do it in one saveset 9and this: one BACKUP zommand) to create the backup, and one to restore it.
Willem Grooters
OpenVMS Developer & System Manager
8 REPLIES 8
Jan van den Ende
Honored Contributor

Re: backup teaser

Willem,

I have had similar requirements, and solved them somewhat along this line:

$ define a_root dev:[a.]/trans=conc
$ define j_root dev:[j.]/trans=conc
$ define tmp_root a_root:,j_root: ! colons obligatory!
$ set def tmp_root:[000000]
$ backup [b.c...],[f.g...],[k.l...] [/any extra quals]

The concealed root definition conceals the top directories [a] and [j], and so excludes them from reference in the saveset.
The searchlist tmp_root combines the two roots into one input spec, allowing for one saveset.

Be aware of potential trouble on restore if there arise collisions if eg in your example B = K !!!

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Jan van den Ende
Honored Contributor

Re: backup teaser

Willem,

upon re-reding your question I do not fully understand the restore part.

Do you want ONE saveset, to restore twice to the same device to two different top dirs, or do you want some part restored to dev2:[x...] and another to dev2:[y...] ?

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Willem Grooters
Honored Contributor

Re: backup teaser

I already thought about creating the backup and came up with the same solution. The pain is in restoring the same basic structure on a different location, so I would get:

dev1:[A.B.C] --> dev2:[X.B.C]
dev1:[A.F.G] --> dev2:[X.F.G]
dev1:[J.K.L] --> dev2:[Y.K.L]

With 2 backup statements (using /SELECT or /EXCLUDE qualifiers) it's no problem, but can this be done in one?

(I could complicate matters even more, but this is hard enough)
Willem Grooters
OpenVMS Developer & System Manager
Jan van den Ende
Honored Contributor

Re: backup teaser

Willem,

ok, that clarifies.

So, do NOT use /trans=conc in input preparation, then A.DIR and J.DIR show up in the saveset.

Before restore, create dev2:[x] and dev2:[y]

Now (temporarily!)
$ SET FILE dev2:[000000]x.dir /enter=a.dir
and analoguous y=b
Restore saveset to dev2:[*...]
and $ set file/remove a.dir (and b.dir)

Workings should be obvious :-)

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Jan van den Ende
Honored Contributor

Re: backup teaser

slight correction:

In previous answer I used b.dir twice
That should have been j.dir

extra note: on ODS5 disks a.dir and A.DIR should NOT be used interchangably (but hey, 25 years of getting used do not fade so quickly!)

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: backup teaser

I'd be tempted to write up a little DCL that looked first for a tag in the directories I wanted (like I dropped a little .COM that grabbed the directory?) and that invoked those or zipped those directories, and I'd then zip the zips.

I'm sure you have a DCL directory-processing loop in your toolbox, or can code one up in a few minutes.

You could also use BACKUP for this, but I've reached the point where I use zip as much or more than BACKUP.

The other option (if you want to stay with BACKUP) is to list out what you want on the BACKUP command line, or to invoke BACKUP with a @filelist as a parameter. To bypass the /SELECT stuff with an explicit list.

If you want to get sneaky, you could tag the files you want with a specific record date, and use that to select the files with BACKUP with a record date in the right range.
John Gillings
Honored Contributor

Re: backup teaser

Willem,

I seem to remember that you cannot exclude the directory path from a backup saveset. That is, you can exclude the CONTENT of directory A, but not directory A itself.

Jan's idea of using concealed devices should help you exclude the top level directory (since BACKUP can't "see" it, it won't be saved). Indeed, you can even make it look like a single device by moving the search list:

$ DEFINE/TRANS=(CONC,TERM) MYDEV dev:[a.],dev:[j.]

That makes the save easier, but there's no way to specify two destinations in the restore half.

A messier way which might work would be to allow A and J to be included in the saveset and restore them to dev2:[A] and dev2:[J], but have X and Y as aliases on DEV2. If there are real A and J directories on the target device you can get around that by adding a concealed device layer. So:

dev2:[restore.a] aliased to dev2:[X] and dev2:[restore.j] aliased to dev2:[Y]. On restore, create a concealed device:

$ DEFINE/TRANS=(CONC,TERM) restdev dev2:[restore.]

so your restore is

$ BACKUP saveset/save/SELECT=[000000...]*.*;* restdev:[000000...]*.*;*


That said, for my money, you'd be better off just doing this in multiple steps. It's easier for others to follow and more likely to be reliable.

Is there a reason you want to avoid multiple savesets?
A crucible of informative mistakes
Willem Grooters
Honored Contributor

Re: backup teaser

@John:
The files form a DBMS-like database used in (near-)real-time process control applications. The database software and many of these applications were originally written on PDP (RSX), and ported to VAX-VMS about 15 years ago. The database files are located in structures like I described.
One of the applications (less time-critical) can be re-located on another VAX in case the original system breaks down and cannot be restored within a few hours. I want this system's database copied to the secondary machine on regular intervals with as little imperfections as possible: theer is already a BACKUP/IGNORE=INTERLOCK on moments known to have least traffic on the database. It can be copied to the other system over the network and stored (and processed) on the secondary system. For this, I would like to have one file.

@Hoff:
I know I could use ZIP but the problem remains the same. On the other hand: ZIP (on VMS) cannot process files locked by other processes, and these files will be. So ZIP to create a saveset is out of the question. However, I could zip the BACKUP saveset to decrease it's size.

Willem Grooters
OpenVMS Developer & System Manager