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
El jue., 24 dic. 2020 3:08, Jakob Bohm <jb-gnumli...@wisemo.com> escribió: > 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 > > >
