I am doing some tape backups with:
mt eom
tar cv Projects*
Note: $TAPE variable is set to /dev/nsa0
I would like to verify that backup has been properly done, via md5sum. Therefore I could do:
tar cvf test.tar Projects*
And I would like to compare with the tar stored in the tape.
However, I do not know how could I extract the whole tar file in the tape into a backupInTape.tar file so I can do:
md5sum test.tar
md5sum backupInTape.tar
This is what I have tried to do something like that (at the right location in the tape, verified with tar tv):
tar xv > backupInTape.tar
But it still extracts everything.
I am using FreeBSD 12.1
You could get the data from tape with the dd command, EG:
dd if="$TAPE" of=data-from-tape.tar bs=126
Check your 'tar' command's default blocksize, and replace the 126 with it. I believe Gnu tar uses 126, but other tar's may still default to 20 or something. With some tape drives, the blocksize matters a lot.
Also, see https://serverfault.com/questions/293605/check-integrity-of-tar-gz-backup
Also, Gnu tar can --diff to confirm that a tar archive is correct, byte for byte.
Related
Sometimes, when I download a PDF file, such as one of my statements from my bank's website, and then, at a later time, download the same file again, both files differ.
How can I see how they differ?
I've tried:
diff file-1.pdf file-2.pdf
But that just prints:
Binary files file-1.pdf and file-2.pdf differ
Try:
diff -a file-1.pdf file-2.pdf | less
Or:
git diff -a file-1.pdf file-2.pdf
Example of diff's output:
1869,1870c1869,1870
< /CreationDate (D:20220504152530-00'00')
< /ModDate (D:20220504152530-00'00')
---
> /CreationDate (D:20220509154833-00'00')
> /ModDate (D:20220509154833-00'00')
Notes:
For either diff or git-diff, the -a, --text option "treat[s] all files as text". (See man diff or man git-diff.)
I use less in case diff -a outputs any binary data. (See this question and this comment.)
You must add the --no-index option after git diff -a when you run the command in a working tree controlled by Git and both files are inside that working tree. (See man git-diff.)
To view a PDF file's data as text, do less file.pdf.
I was given this file:
hashes.txt
experthead:e10adc3949ba59abbe56e057f20f883e
interestec:25f9e794323b453885f5181f1b624d0b
ortspoon:d8578edf8458ce06fbc5bb76a58c5ca4
reallychel:5f4dcc3b5aa765d61d8327deb882cf99
simmson56:96e79218965eb72c92a549dd5a330112
bookma:25d55ad283aa400af464c76d713c07ad
popularkiya7:e99a18c428cb38d5f260853678922e03
eatingcake1994:fcea920f7412b5da7be0cf42b8c93759
heroanhart:7c6a180b36896a0a8c02787eeafb0e4c
edi_tesla89:6c569aabbf7775ef8fc570e228c16b98
liveltekah:3f230640b78d7e71ac5514e57935eb69
blikimore:917eb5e9d6d6bca820922a0c6f7cc28b
johnwick007:f6a0cb102c62879d397b12b62c092c06
flamesbria2001:9b3b269ad0a208090309f091b3aba9db
oranolio:16ced47d3fc931483e24933665cded6d
spuffyffet:1f5c5683982d7c3814d4d9e6d749b21e
moodie:8d763385e0476ae208f21bc63956f748
nabox:defebde7b6ab6f24d5824682a16c3ae4
bandalls:bdda5f03128bcbdfa78d8934529048cf
I thought I had to separate them, for example I put the experthead, interestec, etc. in one file named wordtext.txt and e10adc3949ba59abbe56e057f20f883e, etc in another file called hash.txt.
I then ran this:
hashcat -m 0 -a 0 /Users/myname/Desktop/hash.txt /Users/myname/Desktop/wordtext.txt -O
but I couldn't get anything. And then I googled e10adc3949ba59abbe56e057f20f883e and the output was 123456 so now I don't know how to approach this problem.
Just leave the hashes (erase the plaintext) on the txt file, hashcat will sort them out by itself. What I do is: hashcat.exe -m 0 -a 0 hashFile.txt dict.txt --show
The file appears to be in username:hash format. By default, hashcat assumes that only hashes are in the target file.
You can change this behavior with hashcat's --username option.
You don't need to place the -O at the end. It should work perfectly without it, but you do need hashcat.exe in the beginning.
I want to generate some trace file from disk IO, but the problem is I need the actual input data along with timestamp, logical address and access block size, etc.
I've been trying to solve the problem by using the "blktrace | blkparse" with "iozone" on the ubuntu VirtualBox environment, but it seems not working.
There is an option in blkparse for setting the output format to show the packet data, -f "%P", but it dose not print anything.
below is the command that i use:
$> sudo blktrace -a issue -d /dev/sda -o - | blkparse -i - -o ./temp/blktrace.sda.iozone -f "%-12C\t\t%p\t%d\t%S:%n:%N\t\t%P\n"
$> iozone -w -e -s 16M -f ./mnt/iozone.dummy -i 0
In the printing format "%-12C\t\t%p\t%d\t%S:%n:%N\t\t%P\n", all other things are printed well, but the "%P" is not printed at all.
Is there anyone who knows why the packet data is not displayed?
OR anyone who knows other way to get the disk IO packet data with actual input value?
As far as I know blktrace does not capture the actual data. It just capture the metadata. One way to capture real data is to write your own kernel module. Some students at FIU.edu did that in this paper:
"I/O deduplication: Utilizing content similarity to ..."
I would ask this question in linux-btrace mailing list as well:
http://vger.kernel.org/majordomo-info.html
Hallo.
I have a big video file. ffmpeg, tcprobe and other tool say, it is an h264-stream in an AVI-container.
Now i'd like to cut out small chunks form the video.
Problem: The index of the video seam corrupted/destroyed. I kind of fixed this via mplayer -forceidx -saveidx <IndexFile> <BigVideoFile>. The Problem here is, that I'm now stuck with mplayer/mencoder which can use this index file via -loadidx <IndexFile>. I have tried correcting the index like described in man aviindex (mplayer -frames 0 -saveidx mpidx broken.avi ; aviindex -i mpidx -o tcindex ; avimerge -x tcindex -i broken.avi -o fixed.avi), but this didn't fix my video - meaning that most tools i've tested couldn't search in the video file.
Problem: I cut out parts of the video via following command: mencoder -loadidx in.idx -ss 8578 -endpos 20 -oac faac -ovc x264 -sws 9 -lavfopts format=mp4 -x264encopts <LotsOfOpts> -of lavf -vf scale=800:-10,harddup in.avi -o out.mp4. Now here the problem is, that some videos are corrupted at the beginning. I think this is because the fact, that i do not necessarily cut at keyframe.
Questions:
What is the best way to fix the index of an avi "inline" so that every tool can again work as expected with it?
How can i split at the keyframes? Is there an mencoder-option for this?
Are Keyframes coming in a frequency? How to find out this frequency? (So with a bit of math it should be possible to calculate the next keyframe and cut there)
Is ther perhaps some completely other way to split this movie? Doing it by hand is no option, i've to cut out 1000+ chunks ...
Thanks a lot!
https://spreadsheets.google.com/ccc?key=0AjWmZ0umsuZHdHNzZVhuMTkxTHdYbUdCQzF3cE51Snc&hl=en lists the various options available for splitting accurately.
I would attempt to use avidemux to repair the file before doing anything. You may also have better results using an MP4 Based Container than AVI.
As for ensuring your specified intervals are right at the keyframe, I would suggest encoding with FFMPEG with the: -g 1 option before using the split below to ensure every frame is in fact a keyframe. FFMPEG refers to keyframs as GOP or Groups of Pictures instead.
ffmpeg -i input.avi -g 1 -vcodec copy -acodec copy out.avi
Then multiple splits (with FFMPEG) :
ffmpeg -i input.avi -ss 00:00:10 -t 00:00:30 out1.avi -ss 00:00:35 -t 00:00:30 out2.avi
Some more options to try:
x264 Mapping FFMPEG encoding in linux
Is it possible to use AIX's mksysb and savevg to create a bootable tape with the rootvg and then append all the other VGs?
Answering my own question:
To backup, use a script similar to this one:
tctl -f/dev/rmt0 rewind
/usr/bin/mksysb -p -v /dev/rmt0.1
/usr/bin/savevg -p -v -f/dev/rmt0.1 vg01
/usr/bin/savevg -p -v -f/dev/rmt0.1 vg02
/usr/bin/savevg -p -v -f/dev/rmt0.1 vg03
...etc...
tctl -f/dev/rmt0 rewind
Notes:
- mksysb backs up rootvg and creates a bootable tape.
- using "rmt0.1" prevents auto-rewind after operations.
Also, mkszfile and mkvgdata were used previously to create the "image.data" and various "vgdata" and map files. I did this because my system runs all disks mirrored and I wanted the possibility of restoring with only half the number of disks present. All my image.dat, vgdata and map files were done unmirrored to allow more flexibility during restore.
To restore, the procedures are:
For rootvg, boot from tape and follow the on-screen prompt (a normal mksysb restore).
For the other volume groups, it goes like this:
tctl -f/dev/rmt0.1 rewind
tctl -f/dev/rmt0.1 fsf 4
restvg -f/dev/rmt0.1 hdisk[n]
"fsf 4" will place the tape at the first saved VG following the mksysb backup. Use "fsf 5" for the 2nd, "fsf 6" for the 3rd, and so on.
If restvg complains about missing disks, you can add the "-n" flag to forego the "exact map" default parameter.
If you need to recuperate single files, you can do it like this:
tctl -f/dev/rmt0 rewind
restore -x -d -v -s4 -f/dev/rmt0.1 ./[path]/[file]
"-s4" is rootvg, replace with "-s5" for 1st VG following, "-s6" for 2nd, etc. The files are restored in your current folder.
This technique gives you a single tape that can be used to restore any single file or folder; and also be used to completely rebuild your system from scratch.
First, use savevg to backup any extra volume groups to a file system on the rootvg:
savevg -f /tmp/vgname
Compress it if it will be too large, or use the -i option to exclude files. The easiest way is to exclude all files on the volume group and restore those off of the regular backup device. Once that is done, create your normal mksysb.
For DR purposes, restore the system using the mksysb, then use restvg to restore the volume groups out of your backup files. Restore any extra files that may have been excluded, and you're running again.