Backup volume to subdirectory

[Norm Hansen]

Can the backup command copy an entire volume, preserving directory structure, to another volume in a subdirectory?

The context is disk to disk backups on an outside (NFS mounted) device. Each backup should be kept for n days, so shoving it into a date-named subdirectory seems reasonable, but the backup command won't cooperate for me.

$ backup/log/ignore=inter dsa1:[000000...] dnfs3:[0514...]
does not preserve directory tree. It creates directories, but not subdirectories, so dsa1:[live.data]file.dat;1 ends up turning into
dnfs3:[0514.live]
dnfs3:[0514.data]file.dat;1

$ backup/log/ignore=inter dsa1:[000000...] dnfs3:[*...]
preserves the directory tree, but it isn't in a subdirectory, so the next backup will have a bunch of name conflicts.

Don't want to do an /image, since it won't write to a directory.

I'm sure I could throw together some DCL to get the top level directories and do
$ backup/ignore=inter dsa1:[dir1...] dnfs3:[0514.dir1...] /log
$ backup/ignore=inter dsa1:[dir2...] dnfs3:[0514.dir2...] /log
etc.
but it seems that there must be a way to do it that I'm just missing.

Anyone got an idea?

[Robert Gezelter]

Norm,

I would suggest writing the Save Set to the NFS volume. The Save Set encapsulates the entire volume and directory structure.

An NFS device cannot accommodate ACLs and other structures, so the best way is to write a Save Set and possibly ZIP'ing it to save space.

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> [...] disk to disk backups [...]

Do you want individual files on the remote
disk, or BACKUP save sets? (Save sets might
be easier.)

[Norm Hansen]

In relation to save sets...

I was planning to avoid them, for a couple of reasons; perhaps you can correct my thinking:

1) The device is involved in a de-duplication scheme to reduce eventual size of the backup. The backup vendor recommends against compression, since that introduces randomization that the de-duplication cannot see through. Not sure whether a save set would yield similar problems. Haven't gotten far enough along to test the proposition one way or the other.

2) The backup scheme is two-tiered. The files are being backed up to a staging location that the (VMS-unaware) backup system can see and then make its own backup. If they are all separate files, the backup administrator would at least be able to see the particular files I need restored instead of having to pull the whole save set back to the staging location (meaning, slightly quicker).


I am aware, and concerned, about losing file attributes in the process. Would not the same concern apply to the save set itself, though?

[RBrown_1]

As I recall, you need to create a concealed logical name for your backup destination.

$ define dnfs3:[0514] dest/tran=conc
$ backup/log dsa1:[*...] dest:[*...]

[Robert Gezelter]

Norm,

First, the contents of the BACKUP Save Set (uncompressed/unencrypted) would probably not affect the de-duplication scheme). There is a CRC (optional) on every block, but I would not consider that an issue.

The loss of attributes, ACLs, and other elements is a significant shortcoming. Getting these correct for arbitrary files on a restore can be a very tedious and error prone activity.

Fixing the attributes of the Save Set is far easier, since the procedures that created them are well known (when compared to arbitrary assemblages of files).

Whether de-duplication has a higher yield than compression is a good question. YMMV (your mileage may vary) applies here. I have seen data streams that would benefit from one and not the other, and vice versa. On a technical level, there is no guaranteed winner.

On the other question (directory structure, file attributes, and access control), the save set approach is, IMHO, a far superior alternative.

If staging bandwidth and performance is a concern, then the answer may lie in creating a larger number of less embracive save sets.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Norm,

The trick with getting BACKUP to replicate a directory structure is to keep the wildcards identical on input and output specifications. If you're moving whole trees up or down, define rooted devices to make them appear to be at the same level.

So

BACKUP source:[000000...]*.*;* dest:[000000...]*.*;*

I also find it useful to at least start with BACKUP/LOG, check that the files are going where you want, then ^Y, delete the destination files and rerun with /NOLOG.

As you've noticed, [*...] is not the same as [000000...]

[P Muralidhar Kini]

Hi Norm,

I remember having a similar requirement sometime back and faced some problem while using the BACKUP command.

Check the attachement for the commands that i have tried.

* Backup Command 1
BACKUP $3$DKA300:[000000.MURALI...]*.*;* $3$DKA500:[000000.TEMP...]*.*;* /log

Copies the source to destination but does not restore the directory structure.
Looks like directory within a directory structure is not maintained but
file within a directory structure is maintained

* Backup Command 2
backup $3$DKA300:[000000.MURALI*...]*.*;* $3$DKA500:[000000.TEMP...]*.*;* /log

This tricks the backup to copy the source to destination and preserve the
directory structure.
Note that the source spec has "MURALI*", so if there are any directories in
the source with say "MURALI1" or "MURALI2" then they also might get selected
and copied to destination.

I have tried this on V73-2.

Regards,
Murali

[P Muralidhar Kini]

Hi Norm,

>> $ backup/log/ignore=inter dsa1:[000000...] dnfs3:[0514...]
>> does not preserve directory tree. It creates directories, but not
>> subdirectories,
Having a wildcard in the source specification is what might trick backup in
giving you what you want.

Try the following command and let me know whether it solves your problem
$ backup/log/ignore=inter dsa1:[*...]*.*;* dnfs3:[0514...]*.*;*

This should preserve the directory structure.

Regards,
Murali

[RBrown_1 · Accepted solution]

Earlier, I said:

$ define dnfs3:[0514] dest/tran=conc

This should have been:

$ define dest dnfs3:[0514.] /tran=conc

(For those keeping score at home, I had the logical and equivalence names reversed, AND I left out the dot "." in the equivalence name. :-( )

Once this logical name is defined, then this BACKUP command will do what you have asked for:

$ backup dsa1:[*...] dest:[*...]

(Add other backup qualifiers as desired.)

Sorry for the inconvenience.