Tim Woodall

Blocking-Logic after writing dumpfile to tape

I believe this is now resolved in the 0.4b49-wip branch. I can write a compressed dump to file with -b 512, dd it to tape with bs=20K, and then successfully restore. QFA will not work in this configuration and I've hopefully prevented restore from running with a QFA file in this case. All of my tape testing has been done with mhvtl. I do not have a real tape drive to test with.

Blocking-Logic after writing dumpfile to tape

Hmmm, the problem is that the compression depends on the tape returning a block the same size as was written. The readtape_comprtape function reads a huge block and I think it needs the tape to return a block that was the length that was written. (I say think because I haven't actually tested this theory, only looked at the code) There is, possibly, a workaround, to make your idea work. When reading from the tape, use rmt (to localhost if necessary) with the -l option that tells restore that rmt...

Multiple errors when restoring level 1 dump

From the attached log: entry type: NODE inode number: 0 flags: TMPNAME abort? [yn] n restore: ./vstevko/.kde/socket-cordoba/kdeinit__0: No such file or directory restore: ./vstevko/.kde/socket-cordoba/kdeinit-:0: No such file or directory restore: ./vstevko/.kde/socket-cordoba/kdesud_:0: No such file or directory restore: ./vstevko/tmp/orbit-vstevko/linc-198a-0-71c35f8b53089: No such file or directory expected next file 1048947, got 1048946

I'm 90% sure this was down to sockets. In the 0.4b48 I changed (again) how sockets work. But the git log, in part, had this: Back in 2003 sockets were excluded from verify. Then in 2010 it was realized that they needed to be restored to avoid problems with incremental backups when an inode was reused. At that time a file was created. Then in 2012 that was amended to create a socket device. This bug was reported in 2007 which is before the 2010 change.

dump takes over 8 hours after a NTFS Flash drive removed from an running qemu-kvm w7 vm