[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Corrupcion in Tar Archive with use LTO tape

From: Jakob Bohm
Subject: Re: Corrupcion in Tar Archive with use LTO tape
Date: Thu, 24 Dec 2020 07:08:34 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1

On 22/12/2020 22:37, alvarg wrote:
I explain my topic I am using tar to backup data on LTO 4 tapes, but when there are unexpected power outages, the tar gets corrupted when it comes back and it is useless to store new data in the .tar file. Any GNU / linux program that fixes this? o tar has a repair option, with the increased space of LTO tapes it is vital that tars on tapes are not corrupted by something so common that it can be a power outage
As someone doing the same thing: tar archives are not supposed to get files added to completed archives.  If power is lost during a backup run (tar to tape), expect the following:

1. Some of the data/files logically added to the archive didn't make it from the tar process to the magnetic surface of the tape.  Those data/files will need to be backed up again.

2. The partial tar file written to tape has no valid end marker because of #1

3. The tape drive has left itself and the tape in a somewhat unknown state, upon powering up, it may or may not decide to rewind, but let's hope it doesn't.

4. If you have hours to waste, you could rewind the tape and read the partial archive to determine where exactly it ends both as a tape position and as a set of data actually written.

5. As you are now (already) at the physical tape position after the archive, you could use the mt tool to write a sequence to end the old archive, and start a new one.  I suggest first doing a dd of 2 to 10 tape blocks (I happen to use -b200 so 102400 bytes/block) from /dev/zero to tape to provide a likely end-of-archive for the old archive, should the future restore read past the failure point. Then adding a "file mark" to allow positioning the tape to the new point upon restore.
  # dd bs=$((200*512)) if=/dev/zero of=/dev/nst0 count=10
  # mt -f /dev/nst0 weof

6. Finally, start a fresh tar archive containing just the files that were not backed up yet.

This would result in a tape with two half backups that would need to be restored separately using two tar invocations and a tape seek to the file mark.

My own favorite solution is to just switch tapes and do a fresh backup, then hope no restore is needed until everything is backed up again.  Having a big UPS also helps make the situation more rare, though that does nothing for failures in the PDU, cabling, software etc.


Jakob Bohm, CIO, Partner, WiseMo A/S.
Transformervej 29, 2860 Soborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]