I use UPS but being large tapes with a lot of space and backing up gigabytes and gigabytes there is no UPS that can handle the situation. It cuts hours and when the UPS runs out after hours it continues copying. your solution is correct and i have seen it. but I consider it impractical for LTO tapes, that's why I sent a FEEDBACK to the development team already. imagine with your solution how many tars you could have thousands on a medium that is not like a disk. above all the backup programs are based on tar, therefore they all have the same serious flaw. I consider that tar should be updated and that it should have a tool that repairs the tar and allows you to continue adding files to the tar. if not tar it does not serve to tar
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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
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