On Fri, 10 May 1996 18:10:34 EDT "Steven P. Roder" <[log in to unmask]> said: >The problem here is that VM:backup detects changes to the data as it is >being dumped, so it rewinds the tapes, and even remounts tapes, if >needed, and trys again, for a configurable number of times, after which >the disk or filespace is either skipped, or dumped physically, This is seriously brain dead. Since tapes are at best almost as fast as the disks, your chances of succeeding in making that kind of backup on a large active minidisk are close to zero. With the 500-1500 cyl disks that were mentioned, this algorithm is just a sophisticated way to do CP SLEEP 180 MIN, and then make a physical backup, which does *not* have better integrity. Not only do you waste a lot of time, but the resulting backup has sub-optimal integrity, compared to what could have been achieved with file-level retries. >Our filestores are in SFS, which exacerbates the problem, since the >dumps are a bit slower. But with SFS the file wouldn't change during the backup (that is, SFS will shadow the file so that the copy you see retains integrity). Of course, if VMBACKUP queries SFS explicitly for new changes, that's another story. Also, on a notebook SFS directory, only a handful of files will be changing during the backup operation. Anyway, this is a completely idiotic algorithm. What good is a DDR-like backup of a very active minidisk? The files that don't change will be ok (unless the directory data is corrupt in the dump, which *can* happen, although it is very unlikely), and the files that change will give you an error 3 reading file or will contain garbage, and the only way to know which files were affected is to review them manually. A file level backup with file level retries (which could be grouped for small files, for better performance) could have at least identified the corrupt files for your verification. Eric