| 1 | .TH bkpadmin 8 "28 November 2011" "distorted.org.uk backup" |
| 2 | .SH NAME |
| 3 | bkpadmin \- backup archive administration |
| 4 | .SH SYNOPSIS |
| 5 | .B bkpadmin |
| 6 | .I command |
| 7 | .RI [ argument ...] |
| 8 | .PP |
| 9 | Commands recognized: |
| 10 | .PP |
| 11 | .B help |
| 12 | .br |
| 13 | .B initvol |
| 14 | .I tag |
| 15 | .I device |
| 16 | .br |
| 17 | .B mount |
| 18 | .RI [ tag ] |
| 19 | .br |
| 20 | .B umount |
| 21 | .br |
| 22 | .B initmeta |
| 23 | .br |
| 24 | .B chkmeta |
| 25 | .br |
| 26 | .B prep |
| 27 | .I asset |
| 28 | .I level |
| 29 | .RI [ date |
| 30 | .I time |
| 31 | .IR tz ] |
| 32 | .br |
| 33 | .B abort |
| 34 | .I asset |
| 35 | .br |
| 36 | .B fail |
| 37 | .I asset |
| 38 | .br |
| 39 | .B level |
| 40 | .I asset |
| 41 | .br |
| 42 | .B hash |
| 43 | .I asset |
| 44 | .I file |
| 45 | .I hash |
| 46 | .br |
| 47 | .B commit |
| 48 | .I asset |
| 49 | .br |
| 50 | .B check |
| 51 | .I asset |
| 52 | .I label |
| 53 | .br |
| 54 | .B catalogue |
| 55 | .I asset |
| 56 | .br |
| 57 | .B outdated |
| 58 | .I asset |
| 59 | .br |
| 60 | .B test |
| 61 | .I command |
| 62 | .RI [ argument ...] |
| 63 | .SH DESCRIPTION |
| 64 | The |
| 65 | .B bkpadmin |
| 66 | command assists with the maintenance of disk backup volumes. A backup |
| 67 | volume contains a hierarchy of backed up data, as follows. The volume |
| 68 | stores data for a number of client |
| 69 | .IR hosts . |
| 70 | Each host has a number of |
| 71 | .I assets |
| 72 | which need to be backed up. Each time an asset is backed up, the backup |
| 73 | files are collected together and assigned a |
| 74 | .IR label . |
| 75 | .PP |
| 76 | The |
| 77 | .I host |
| 78 | names don't actually need to correspond to actual hosts, though that's |
| 79 | the intent. Rather, they correspond to mutually untrusting sources of |
| 80 | backup data. Each host is represented locally by a user named |
| 81 | .BI bkp- host \fR. |
| 82 | |
| 83 | |
| 84 | |
| 85 | .SH BUGS |
| 86 | There's far too much local policy embedded in here: LVM volume naming, |
| 87 | user naming, key management, and so on. Splitting this out would be a |
| 88 | really good idea, though probably not for the faint of heart. |