VXA Tape Forensic copy
Hello everyone )
I have 10 VXA Tapes to make a forensic copy of.
i'm planning to use DD for the acquisition of these tapes, but since it's the first time i have to deadl with such media, are there things i need to take particular care of?
for example, if i make a dd image of the tape, can i then use dd to write the content back to a new tape?
can i access the content of the image to extract the data out of it?
is it possible to mount a dd image of the tape in loopback to check the content? or (as i think) it's not possible?
i've also read a topik about tape forensics on this forum and someone explained something about block-size that must be the same for both the source and the destination, but i can't find informations about these tapes block size anywhere, is there a way to obtain such information?
sorry but i'm really a n00b in these kind of stuff and i need some monkey-proof help )
thnx in advice.
sorry for my bad english.
Tape cat is a pretty good piece of forensic software to image tape, I've used it before and had no problems.
Just make sure you put the tape into a read only mode
Hope this is of help
I looked around for some software and it looks like that DD is the best choiche for me right now.
first of all becouse except of the tape model, i dunno anything about the content, how it was produced, wich software was used for the backups and such.
and since i'm in a hurry, the best choiche is to make a 11 copy of the tape to an image file and work on it, couse i can't keep these tapes any longer.
by googling around a bit i found this article
wich says something interesting about determining the source block size
Now let's say we have an unknown tape to examine. If we are unsure of the block size used on the tape, we could use the ibs/obs flags to find the correct size. Finding the correct size speeds up the copying process - sometimes dramatically!
dd if=/dev/st0 ibs=128 of=/dev/case10img1 obs=1 count=1
The above usage will attempt to take 1 block with size of 128 from 'st0' and create 'case10img1' output with a block size of 1. The 'count' flag is used so that only 1 block is read. We do this because we want to limit DD to just the 1 block. If we did not set a count size DD would continue on and a whole lot of time would be wasted! What this example attempts to show is that by setting the input block size to 128 we can effectively find what the real block size is (unless, of course, it is 128!). With 512 as the standard block size, assuming 128 is virtually a failproof way to find the real block size. The output of the above command would most likely be an 'error' message (which was our intent) with the real block size revealed (say 1024, for example).
would this work?
sorry again for my bad english )
DD will prob not help.
A tape is usually split intoa number fo tapefiles, sometimes just one but normally (even for a tape with one backup session) multiple files. The block size can vary between tape files and even from block to block
DD will get the first file if it is a fixed block size but after that you need to start screwing around with mt to reposition the tape.
so there's no way to use dd to make an image of the tape?
what do you suggest to do.
You can absolutely use 'dd' to acquire a tape. What you need is the block size of the tape, and that is what that very old article mentioned )
As Paul has mentioned, tapes can have various block sizes and you will need to spend time working with that tape more than you would if you used an automated tool or sent the tapes off to a commercial company to process them for you (such as eMag).
ok thnx )
the only thing i did wrong was thinking the block size of the tape was always the same for the whole tape, once it's been identified..
but it looks like the block size may vary between parts of the tape.. so i think it will be more time consuming then expected.
It may vary - the likelihood is that it will be the same.
What you may not get is a single image file that you are used to - every volume could have 2 or more tape files.
You can use DD along with MT but it is time consuing and at the end of it you will have either one, or more likely serveral, 'image' files.
EnCase will not understand them
Hello…. again ^^
i went through some tests and man… what a bad luck.
i tried to access data on these tapes using linux with mt, dd, tapecat
no luck (
errors in detecting the tape, input/output errors, even mt wasn't able to perform actions like rewind the tape and such.
i tried using mediamerge PC for accessing these tapes, i had some luck here and was able tor ead the header of a single file on a tape, and detected it was made using backup exec.
so i decided to try using backup exec to extract these files, and all tapes resulted as empty.
what should i do?
do you have anything to suggest me? or i can just confirm that these tapes are damaged?
wich may be true since when i received them, their state wasn't that good at the appearence.
looks like they were archived in a damnly dusty place.
the problem is that even the exact tool used to perform the backup operations wasn't able to rebuild the content or even make a catalog.
hope someone can help me out.