Re: [OpenAFS] Error restoring volumes from backup

[Kim Kimball]

Gérald Macinenti wrote: Kim Kimball a écrit : The backup dump command has "-append" as an option. Do you know if this was used when the dumps were created? yes it was used, and as I understand, this is what caused the problem as appending to a dump is only supported for tape devices, not files. Oh, I didn't know that and hadn't tried.  Thanks for the info. So the problem arises each time you want an incremental dump for the same volset or want to backup a new volset on a device which already holds a dump: you *must* use a separate file each time, isn't it? If append dump won't work for files then you must be right.  In fact there's a 'mount script' example in the AFS Admin Reference at AFS Admin Reference (IBM) that indirectly confirms that appends to a file don't work, but I hadn't understood the full implications.  "A value greater than one indicates that the Tape Coordinator cannot access <the target file>" ...  I haven't worked with the script but it is intended to automate the renaming of the target file and may help.  I can't comment on how restores would work with this scheme. Quote Example CFG_device_name File for Dumping to a Backup Data File In this example, the administrator creates the following entry for a backup data file called HSM_device in the /usr/afs/backup/tapeconfig file. It has port offset 20. 1G 0K /dev/HSM_device 20 The administrator includes the following lines in the /usr/afs/backup/CFG_HSM_device file. To review the meaning of each instruction, see the preceding Description section. MOUNT /usr/afs/backup/file FILE YES ASK NO Finally, the administrator writes the following executable routine in the /usr/afs/backup/file file referenced by the MOUNT instruction in the CFG_HSM_device file, to control how the Tape Coordinator handles the file. #! /bin/csh -f set devicefile = $1 set operation = $2 set tries = $3 set tapename = $4 set tapeid = $5 set exit_continue = 0 set exit_abort = 1 set exit_interactive = 2 #-------------------------------------------- if (${tries} > 1) then echo "Too many tries" exit ${exit_interactive} endif if (${operation} == "labeltape") then echo "Won't label a tape/file" exit ${exit_abort} endif if ((${operation} == "dump") |\ (${operation} == "appenddump") |\ (${operation} == "restore") |\ (${operation} == "savedb") |\ (${operation} == "restoredb")) then /bin/rm -f ${devicefile} /bin/ln -s /hsm/${tapename}_${tapeid} ${devicefile} if (${status} != 0) exit ${exit_abort} endif exit ${exit_continue} " Like the example routine for a tape stacker, this routine uses the tries and operation parameters passed to it by the Backup System. The tries parameter tracks how many times the Tape Coordinator has attempted to access the file. A value greater than one indicates that the Tape Coordinator cannot access it, and the routine returns exit code 2 (exit_interactive), which results in a prompt for the operator to load a tape. The operator can use this opportunity to change the name of the backup data file specified in the tapeconfig file. The primary function of this routine is to establish a link between the device file and the file to be dumped or restored. When the Tape Coordinator is executing a backup dump, backup restore, backup savedb, or backup restoredb operation, the routine invokes the UNIX ln -s command to create a symbolic link from the backup data file named in the tapeconfig file to the actual file to use (this is the recommended method). It uses the value of the tapename and tapeid parameters to construct the file name. ENDQUOTE Kim If so I don't find it very confortable to use as you must define differents TC on different ports, one per file, or you have to change the file on behalf of the TC (have a link that points to a different file each time you wants to add something on the same disk)? ps: restoring such appended dumps doesn't work with standard commands but the size of the backup file seems to grow at each backup, so I guess the data must be restorable in a (tricky) way or another. Gerald Macinenti wrote: Carsten Schulz-Key wrote: Gerald Macinenti wrote: When trying to restore a volume for which I have incremental dumps on tape (not a tape but a file on an external disk), I can sucessfully restore the last full dump but increments are not appended, I have the following error in butc output: It seems, you're encountering the following problem: http://www.openafs.org/pipermail/openafs-info/2007-February/025284.html You have to use separate dump files if you want to do incremental dumps :-( ... ok, thank you very much, sad news... Is there any plan to develop an append-to-file feature? Cheers _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info