Error recovery (old)

From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)

Jump to: navigation, search
Deprecated
See Getting Started with Amanda instead

In real life, errors happen, and after solving the problems, you want Amanda to resume normal tasks as soon as possible.


Dumps left in the holdingdisk

One of most common problems requiring some help for the operator is when Amanda cannot fit the dumps to the tape. That could be the result of a tape full or IO error, or even the wrong tape or no tape at all in the tape drive.

Amanda then falls back to plan B: "degraded" mode, and saves the dumps on the holdingdisk. Degraded mode means that some level 0 dumps will be changed in incremental dumps to save the precious diskspace). See the reserve parameter in amanda.conf(5) how to tune the amount of holdingdisk space that is reserved for incremental backups in degraded mode. Using this scheme, Amanda can continue making backups while you are on holiday, or while the tapedrive is being repaired.

The dumps on holdingdisk can be put on tape afterwards with the amflush(8) command.

Insert the next tape, and run as the Amanda user:

$ amflush daily

(assuming "daily" is the name of the config).

Amanda will now propose the list of directories (named after the dump date and time). You may flush ALL of them, or some directories only.

Amanda will continue flushing in the background, writing to tape, and you may even log off. You will receive a report by mail when the flush if finished.

With the parameter autoflush true in amanda.conf(5), Amanda will flush all dumps it encounters on the holdingdisk during a normal "amdump" run. This can be handy if the dumps are not big, and you want to avoid wasting a tape for the amflush run.


Some important hosts missing

When the report indicates that some hosts had problems with the dumps, you need to find out what happened on those hosts and fix it.

When the data on those hosts are really important, and you do not want to wait for the next run, you may start a manual dump of only those hosts and/or DLE:

$ amdump daily saturn 'mars*' /home '/data*' '*srv'

This will dump :

  • all the DLE's of host "saturn"
  • all the hosts that begin with "mars", e.g. "mars", or "marshall"; but only the /home partition and all partitions beginning with '/data', like "/data", "/datamore" "/data2", etc.
  • all the DLE's of all hosts with names ending in 'srv' like "filesrv", "printsrv" etc.

All the other DLE's are skipped in this run.

For an explanation of the use of patterns in the expressions for host and diskname, see amanda(8).

Combined with "autoflush true" in amanda.conf such a run of "amdump" will flush the files found in the holdingdisk together the new dumps generated in this run.


Tapes lost or damaged

You may also get some tapes lost, or you notice, e.g. with amcheckdump(8), that a tape is damaged and you are unable to restore files from that tape.

People using vtapes (backups on virtual tapes stored on disk) reported having a diskcrash and loosing many vtapes at once (even on a RAID system).

To recover from these errors, you first need to inform Amanda of the loss. Remove those tapes from the known list of tapes using the amrmtape(8) command. Let's assume the tape labelled Daily-05 got damaged:

$ amrmtape daily Daily-05

By executing this command Amanda will not base any incrementals on the contents of that tape, and adapt its scheduling accordingly. Expect the next dump to be some larger than normal, while Amanda compensates for the missing dumps.

Then label a new tape. You may use the same label:

$ amlabel daily Daily-05

If you insist on a logical sequence of tapelabels, then you may have to edit the tapelist file, and position the tape on the correct spot in the file. Note that if your dumpcycle == tapecycle, then you NEED to feed this tape for the next run (another reason to avoid that condition).

Personal tools