Left space on tape ?

czezz · 07-16-2008, 02:01 PM

How can I see how much more space is left on a tape ?
Everynight my system execute:

Code:

ufsdump 0ucf /dev/rmt/0n /opt

Backup is not very big - about 700 MB and rising every day.
But some day space on tape will be exceeded...
Need to find some how, how much is left.

Mr. C. · 07-16-2008, 02:30 PM

Some tapes / tape units have an end of media marker, and the unit can automatically advance to the end of the tape to calculate storage capacity. See

man mt

for your system, and documentation for your drive and media.

marozsas · 07-16-2008, 03:15 PM

Sure there is an eom, but no way to directly get how much space there is from some point to the end of tape.
The easiest way is to calculate the difference (size_of_tape - total_size_of_data_written).

Anyway, I must advise you to not rely in one single tape to have several instances of a full backups in a single tape as you are doing.
If this tape goes bad you will lost all full backps on it at once !

Do NOT use non-rewind devices and start each backup session in a different tape.
If you make daily backups, use at least 2 tapes and alternate the tapes 1 and 2.
Depending on how critical is the data you can use a tape per day or even more.

Otherwise, you may have a false sense of protection.

Did you ever have checked if the tape contents is good for restore ? It is very common to write data to a tape that you can't read it back. So, another advice is to test the media just after the backup session ends.

cheers,

choogendyk · 07-16-2008, 10:28 PM

hmm. So, that tape is just sitting in the drive indefinitely. You're using the no-rewind device. Assuming that no one or thing has touched the tape. If the system rebooted and the device reset and rewound (bit of a power bump last night, say), then your ufsdump would overwrite the tape and all the previous dumps would be lost.

Sounds pretty risky. I would at least put in some logic and checking. Use `mt status` to see where you are and either `mt fsf <n>` or `mt eom` to ensure that the tape is actually positioned to the end and you know where that is.

I also second the comment not to rely on a single tape this way.

czezz · 07-17-2008, 01:14 AM

Guys, this is not prod. system and what I have been doing is only for my education... so dont really care for safty of backup for now.

What I am worried now is what all of u mentioned - that I am using /dev/rmt/0n

Indeed. Some time ago I created topic:
http://www.linuxquestions.org/questi...n-tape-647175/

I asked there how to put files on a tape and not to overwrite them.
When I was doing this:

Code:

# ufsdump 0ucf /dev/rmt/0 /dev/md/rdsk/d1
# mt -f /dev/rmt/0 fsf
# ufsdump 0ucf /dev/rmt/0 /dev/md/rdsk/d2

I got always only ufsdump of the /dev/md/rdsk/d2 on tape. So it overwritten. mt -f /dev/rmt/0 fsf just doesnt work

The only way to put more than one backup on a tape is to use /dev/rmt/0n.
But what choogendyk noticed is that after reboot, tape will start from the beginning - that is a little bit crappy for me :/

So, may you please advice me how to put more than one backup on a tape ?
(Lets just dont care for now that puting all week backup on 1 tape is not a safe solution).

kebabbert · 07-17-2008, 03:19 AM

Later you should try to restore a system. It is very common that companies do backup, and when they try to restore, nothing works. They missed something.

czezz · 07-17-2008, 03:36 AM

kebabbert - im asking about overwrite issue not restore.
(If I do backup with /dev/rmt/0n I can restore each day by day - no problem with restore)

karthik_kce · 07-17-2008, 08:06 AM

Hi Guys,

Even I used to take backups in the tape drive.. But at no point of time, I am able to calculate the remaining space in the tape drive..

#mt status

don't give me detailed information...

#ufsrestore -i

just displays the file but not its sizes..

Can you guys help me how to calculate the remaining space in the tape drive.

choogendyk · 07-17-2008, 09:24 AM

OK, a bunch of things.

`mt status` cannot tell you what is on the tape. It only tells what file number you are at. You have to look at the output of the ufsdump. There should be a line like:

DUMP: 71314 blocks (34.82MB) on 1 volume at 447 KB/sec

(that's from a DDS tape, so the performance is crummy by current standards).

Then, as marozsas said, add up all the data written to the tape and subtract it from the size of the tape. This may even be harder than it sounds. You have to take into account compression. If you are using hardware compression, then all bets are off. You will be guessing. But at least you will have a rational guess. You'll have to have some idea as to how compressible your data is. And you may just run off the end of the tape anyway.

/dev/rmt/0n is cool. Use it. That's what I have always done. Otherwise, the tape will rewind in response to everything that you do to it. An fsf will immediately be followed by a rewind, which is useless.

If you don't care about previous backups, then just issue a rewind before the day's backups.

If you want to stack as many backups as possible on the tape, and be meticulous about knowing the tape is where you want it to be, then issue a rewind followed by an eom. So, e.g.

Code:

$ mt -f /dev/rmt/0n rewind
$ mt -f /dev/rmt/0n eom
$ ufsdump 0ucf /dev/rmt/0cn /dev/md/rdisk/d1
$ ufsdump 0ucf /dev/rmt/0cn /dev/md/rdisk/d2

The "c" (in 0cn, if you were to use that) will give you hardware compression. That's good, but doesn't help your calculations, as I already mentioned. If you are doing typical unix/linux sort of stuff that has lots of text files, it may compress 2:1 or even better. But throw in some dense, non-compressible files, such as images or already compressed source stuff like tiff files or, say, gcc-huge.tar.gz, and you may not get much compression, or, worse yet, some hardware compression algorithms will actually increase the size because of the added table space required for the compression.

Because of that issue, you'll have to go by experience and intelligent guessing.

Keep a log of the sizes of your backups from the ufsdump output, and do the best you can with it. DDS/3 claims 12G/24G (12G native capacity, 24G with compression). My experience with them was typically 14-18G, depending. I never got anywhere near 24G.

HTH

choogendyk · 07-17-2008, 09:36 AM

With regard to the use of /dev/rmt/0cn (with c for compression), I should note that some drives will recognize how a tape has been used and will only use it that way. So, if you wrote a tape without compression, and then try to write to it with compression, the drive may silently do as it pleases regardless of what you said.

I don't know if that is true of DDS. I've heard people on lists go through contortions with more modern higher capacity drives trying to force them. I believe erasing the tape and writing it may have been the solution. But, that's a whole 'nother topic. Could be found by searching some of the backup lists archives. I think I saw it discussed at length on the Bacula list.