~ubuntu-branches/ubuntu/karmic/cedar-backup2/karmic

« back to all changes in this revision

Viewing changes to doc/manual/manual.txt

  • Committer: Bazaar Package Importer
  • Author(s): Kenneth J. Pronovici
  • Date: 2006-12-18 22:59:17 UTC
  • mfrom: (1.1.5 upstream)
  • Revision ID: james.westby@ubuntu.com-20061218225917-gwos76xdo3jewj6i
Tags: 2.9.0-1
* New upstream release.
  - Provide way to configure dev=/dev/cdrw and the like (closes: #403546).
  - Fix, clean up and reorganize parts of user manual (closes: #403448, #403662).

Show diffs side-by-side

added added

removed removed

Lines of Context:
96
96
 
97
97
    Setting up a Pool of One
98
98
 
99
 
        Step 1: Make sure email works.
100
 
        Step 2: Configure your CD-R or CD-RW drive.
101
 
        Step 3: Configure your backup user.
102
 
        Step 4: Create your backup tree.
103
 
        Step 5: Modify the backup cron jobs.
 
99
        Step 1: Decide when you will run your backup.
 
100
        Step 2: Make sure email works.
 
101
        Step 3: Configure your CD-R or CD-RW drive.
 
102
        Step 4: Configure your backup user.
 
103
        Step 5: Create your backup tree.
104
104
        Step 6: Create the Cedar Backup configuration file.
105
105
        Step 7: Validate the Cedar Backup configuration file.
106
106
        Step 8: Test your backup.
 
107
        Step 9: Modify the backup cron jobs.
107
108
 
108
109
    Setting up a Client Peer Node
109
110
 
110
 
        Step 1: Make sure email works.
111
 
        Step 2: Configure the master in your backup pool.
112
 
        Step 3: Configure your backup user.
113
 
        Step 4: Create your backup tree.
114
 
        Step 5: Modify the backup cron jobs.
 
111
        Step 1: Decide when you will run your backup.
 
112
        Step 2: Make sure email works.
 
113
        Step 3: Configure the master in your backup pool.
 
114
        Step 4: Configure your backup user.
 
115
        Step 5: Create your backup tree.
115
116
        Step 6: Create the Cedar Backup configuration file.
116
117
        Step 7: Validate the Cedar Backup configuration file.
117
118
        Step 8: Test your backup.
 
119
        Step 9: Modify the backup cron jobs.
118
120
 
119
121
    Setting up a Master Peer Node
120
122
 
121
 
        Step 1: Make sure email works.
122
 
        Step 2: Configure your CD-R or CD-RW drive.
123
 
        Step 3: Configure your backup user.
124
 
        Step 4: Create your backup tree.
125
 
        Step 5: Modify the backup cron jobs.
 
123
        Step 1: Decide when you will run your backup.
 
124
        Step 2: Make sure email works.
 
125
        Step 3: Configure your CD-R or CD-RW drive.
 
126
        Step 4: Configure your backup user.
 
127
        Step 5: Create your backup tree.
126
128
        Step 6: Create the Cedar Backup configuration file.
127
129
        Step 7: Validate the Cedar Backup configuration file.
128
130
        Step 8: Test connectivity to client machines.
129
131
        Step 9: Test your backup.
130
 
 
131
 
    Configuring your SCSI Device
132
 
 
133
 
        SCSI Required
 
132
        Step 10: Modify the backup cron jobs.
 
133
 
 
134
    Configuring your Writer Device
 
135
 
 
136
        SCSI Devices
 
137
        Non-SCSI Devices
134
138
        Linux Notes
135
139
        Mac OS X Notes
136
140
 
1140
1144
 
1141
1145
Setting up a Pool of One
1142
1146
 
1143
 
    Step 1: Make sure email works.
1144
 
    Step 2: Configure your CD-R or CD-RW drive.
1145
 
    Step 3: Configure your backup user.
1146
 
    Step 4: Create your backup tree.
1147
 
    Step 5: Modify the backup cron jobs.
 
1147
    Step 1: Decide when you will run your backup.
 
1148
    Step 2: Make sure email works.
 
1149
    Step 3: Configure your CD-R or CD-RW drive.
 
1150
    Step 4: Configure your backup user.
 
1151
    Step 5: Create your backup tree.
1148
1152
    Step 6: Create the Cedar Backup configuration file.
1149
1153
    Step 7: Validate the Cedar Backup configuration file.
1150
1154
    Step 8: Test your backup.
 
1155
    Step 9: Modify the backup cron jobs.
1151
1156
 
1152
1157
Setting up a Client Peer Node
1153
1158
 
1154
 
    Step 1: Make sure email works.
1155
 
    Step 2: Configure the master in your backup pool.
1156
 
    Step 3: Configure your backup user.
1157
 
    Step 4: Create your backup tree.
1158
 
    Step 5: Modify the backup cron jobs.
 
1159
    Step 1: Decide when you will run your backup.
 
1160
    Step 2: Make sure email works.
 
1161
    Step 3: Configure the master in your backup pool.
 
1162
    Step 4: Configure your backup user.
 
1163
    Step 5: Create your backup tree.
1159
1164
    Step 6: Create the Cedar Backup configuration file.
1160
1165
    Step 7: Validate the Cedar Backup configuration file.
1161
1166
    Step 8: Test your backup.
 
1167
    Step 9: Modify the backup cron jobs.
1162
1168
 
1163
1169
Setting up a Master Peer Node
1164
1170
 
1165
 
    Step 1: Make sure email works.
1166
 
    Step 2: Configure your CD-R or CD-RW drive.
1167
 
    Step 3: Configure your backup user.
1168
 
    Step 4: Create your backup tree.
1169
 
    Step 5: Modify the backup cron jobs.
 
1171
    Step 1: Decide when you will run your backup.
 
1172
    Step 2: Make sure email works.
 
1173
    Step 3: Configure your CD-R or CD-RW drive.
 
1174
    Step 4: Configure your backup user.
 
1175
    Step 5: Create your backup tree.
1170
1176
    Step 6: Create the Cedar Backup configuration file.
1171
1177
    Step 7: Validate the Cedar Backup configuration file.
1172
1178
    Step 8: Test connectivity to client machines.
1173
1179
    Step 9: Test your backup.
1174
 
 
1175
 
Configuring your SCSI Device
1176
 
 
1177
 
    SCSI Required
 
1180
    Step 10: Modify the backup cron jobs.
 
1181
 
 
1182
Configuring your Writer Device
 
1183
 
 
1184
    SCSI Devices
 
1185
    Non-SCSI Devices
1178
1186
    Linux Notes
1179
1187
    Mac OS X Notes
1180
1188
 
1215
1223
Debian system than on a system where you install from source.
1216
1224
 
1217
1225
The configuration instructions below have been generalized so they should work
1218
 
well regardless of what platfomr you are running (i.e. RedHat, Gentoo, FreeBSD,
 
1226
well regardless of what platform you are running (i.e. RedHat, Gentoo, FreeBSD,
1219
1227
etc.). If instructions vary for a particular platform, you will find a note
1220
1228
related to that platform.
1221
1229
 
1339
1347
 
1340
1348
    Dump a Python stack trace instead of swallowing exceptions. This forces
1341
1349
    Cedar Backup to dump the entire Python stack trace associated with an
1342
 
    error, rather than just progating last message it received back up to the
 
1350
    error, rather than just propagating last message it received back up to the
1343
1351
    user interface. Under some circumstances, this is useful information to
1344
1352
    include along with a bug report.
1345
1353
 
1665
1673
    their own custom functionality with standard Cedar Backup actions or with
1666
1674
    arbitrary extensions.
1667
1675
 
1668
 
    This section is optional, and can be repeatd as many times as necessary.
 
1676
    This section is optional, and can be repeated as many times as necessary.
1669
1677
 
1670
1678
    This subsection must contain the following two fields:
1671
1679
 
1793
1801
    were explicitly excluded in configuration.
1794
1802
 
1795
1803
    The ignore file provides a way for individual users (who might not have
1796
 
    access to Cedar backup configuration) to control which of their own
 
1804
    access to Cedar Backup configuration) to control which of their own
1797
1805
    directories get backed up. For instance, users with a ~/tmp directory might
1798
1806
    not want it backed up. If they create an ignore file in their directory
1799
1807
    (e.g. ~/tmp/.cbignore), then Cedar Backup will ignore it.
1968
1976
        backup as if it were explicitly excluded in configuration.
1969
1977
 
1970
1978
        The ignore file provides a way for individual users (who might not have
1971
 
        access to Cedar backup configuration) to control which of their own
 
1979
        access to Cedar Backup configuration) to control which of their own
1972
1980
        directories get backed up. For instance, users with a ~/tmp directory
1973
1981
        might not want it backed up. If they create an ignore file in their
1974
1982
        directory (e.g. ~/tmp/.cbignore), then Cedar Backup will ignore it.
2080
2088
    This field is always required. The directory must contain enough free space
2081
2089
    to stage all of the files collected from all of the various machines in a
2082
2090
    backup pool. Many administrators set up purging to keep staging directories
2083
 
    around for a week or more, which require even more space.
 
2091
    around for a week or more, which requires even more space.
2084
2092
 
2085
2093
    Restrictions: Must be an absolute path
2086
2094
 
2270
2278
 
2271
2279
target_scsi_id
2272
2280
 
2273
 
    SCSI id for writer device
2274
 
 
2275
 
    In order to execute the store action, your CD-R or CD-RW drive must either
2276
 
    be a SCSI device or must be configured to act like a SCSI device from the
2277
 
    perspective of the cdrecord and mkisofs commands. This value configures the
2278
 
    SCSI id that will be used to write to your device.
 
2281
    SCSI id for the writer device.
 
2282
 
 
2283
    This value is optional. If you have configured your CD writer hardware to
 
2284
    work through the normal filesystem device path, then you can leave this
 
2285
    parameter unset. Cedar Backup will just use the target device (above) when
 
2286
    talking to cdrecord.
 
2287
 
 
2288
    Otherwise, if you have SCSI CD writer hardware or you have configured your
 
2289
    non-SCSI hardware to operate like a SCSI device, then you need to provide
 
2290
    Cedar Backup with a SCSI id it can use when talking with cdrecord.
2279
2291
 
2280
2292
    For the purposes of Cedar Backup, a valid SCSI identifier must either be in
2281
 
    the form ?scsibus,target,lun?, ?ATA:scsibus,target,lun?, or
2282
 
    ?ATAPI:scsibus,target,lun?. For example, ?1,6,2?, ?ATA:0,0,0? and
2283
 
    ?ATAPI:0,1,0? are all valid identifiers.
2284
 
 
2285
 
    Technically, Mac OS X identifiers are also accepted, but the syntax is not
2286
 
    documented here because the store action is not supported for that
2287
 
    platform. See the section called ?Configuring your SCSI Device? for more
2288
 
    information on SCSI devices and how they are configured.
2289
 
 
2290
 
    Restrictions: Must be a valid SCSI identifier.
 
2293
    the standard SCSI identifier form scsibus,target,lun or in the
 
2294
    specialized-method form <method>:scsibus,target,lun.
 
2295
 
 
2296
    An example of a standard SCSI identifier is 1,6,2. Today, the two most
 
2297
    common examples of the specialized-method form are ATA:scsibus,target,lun
 
2298
    and ATAPI:scsibus,target,lun, but you may occassionally see other values
 
2299
    (like OLDATAPI in some forks of cdrecord).
 
2300
 
 
2301
    See the section called ?Configuring your Writer Device? for more
 
2302
    information on writer devices and how they are configured.
 
2303
 
 
2304
    Restrictions: If set, must be a valid SCSI identifier.
2291
2305
 
2292
2306
drive_speed
2293
2307
 
2430
2444
The collect action has index 100, the stage index has action 200, the store
2431
2445
action has index 300 and the purge action has index 400.
2432
2446
 
2433
 
For instance, imagine that a third-party developer provided a Cedar Backup
2434
 
extension to back up a certain kind of database repository, and you wanted to
2435
 
map that extension to the ?database? command-line action. You have been told
2436
 
that this function is called ?foo.bar()?. You think of this backup as a
2437
 
?collect? kind of action, so you want it to be performed after collect but
2438
 
before stage and purge if more than one action is specified on the command
2439
 
line.
 
2447
Warning
 
2448
 
 
2449
Extended actions should always be configured to run before the standard action
 
2450
they are associated with. This is because of the way indicator files are used
 
2451
in Cedar Backup. For instance, the staging process considers the collect action
 
2452
to be complete for a peer if the file cback.collect can be found in that peer's
 
2453
collect directory.
 
2454
 
 
2455
If you were to run the standard collect action before your other collect-like
 
2456
actions, the indicator file would be written after the collect action completes
 
2457
but before all of the other actions even run. Because of this, there's a chance
 
2458
the stage process might back up the collect directory before the entire set of
 
2459
collect-like actions have completed ? and you would get no warning about this
 
2460
in your email!
 
2461
 
 
2462
So, imagine that a third-party developer provided a Cedar Backup extension to
 
2463
back up a certain kind of database repository, and you wanted to map that
 
2464
extension to the ?database? command-line action. You have been told that this
 
2465
function is called ?foo.bar()?. You think of this backup as a ?collect? kind of
 
2466
action, so you want it to be performed after collect but before stage and purge
 
2467
if more than one action is specified on the command line.
2440
2468
 
2441
2469
To configure this extension, you would list an action with a name ?database?, a
2442
 
module ?foo?, a function name ?bar? and an index of ?101?.
 
2470
module ?foo?, a function name ?bar? and an index of ?99?.
2443
2471
 
2444
2472
This is how the hypothetical action would be configured:
2445
2473
 
2448
2476
      <name>database</name>
2449
2477
      <module>foo</module>
2450
2478
      <function>bar</function>
2451
 
      <index>101</index>
 
2479
      <index>99</index>
2452
2480
   </action>
2453
2481
</extensions>
2454
2482
 
2511
2539
staging directory), you can do that. You'll just have to modify the procedure
2512
2540
below based on information in the remainder of the manual.
2513
2541
 
2514
 
Step 1: Make sure email works.
 
2542
Step 1: Decide when you will run your backup.
 
2543
 
 
2544
There are four parts to a Cedar Backup run: collect, stage, store and purge.
 
2545
The usual way of setting off these steps is through a set of cron jobs.
 
2546
Although you won't create your cron jobs just yet, you should decide now when
 
2547
you will run your backup so you are prepared for later.
 
2548
 
 
2549
Backing up large directories and creating ISO CD images can be intensive
 
2550
operations, and could slow your computer down significantly. Choose a backup
 
2551
time that will not interfere with normal use of your computer. Usually, you
 
2552
will want the backup to occur every day, but it is possible to configure cron
 
2553
to execute the backup only one day per week, three days per week, etc.
 
2554
 
 
2555
Warning
 
2556
 
 
2557
Because of the way Cedar Backup works, you must ensure that your backup always
 
2558
runs son the first day of your configured week. This is because Cedar Backup
 
2559
will only clear incremental backup information and re-initialize your media
 
2560
when running on the first day of the week. If you skip running Cedar Backup on
 
2561
the first day of the week, your backups will likely be ?confused? until the
 
2562
next week begins, or until you re-run the backup using the --full flag.
 
2563
 
 
2564
Step 2: Make sure email works.
2515
2565
 
2516
2566
Cedar Backup relies on email for problem notification. This notification works
2517
2567
through the magic of cron. Cron will email any output from each job it executes
2526
2576
forward to some other user, so you do not need to check the root user's mail in
2527
2577
order to see Cedar Backup errors.
2528
2578
 
2529
 
Step 2: Configure your CD-R or CD-RW drive.
2530
 
 
2531
 
Your CD-R or CD-RW drive must either be a SCSI device or must be configured to
2532
 
act like a SCSI device from the perspective of the cdrecord and mkisofs
2533
 
commands. Regardless of what kind of drive you have, make sure you know its
2534
 
SCSI address and its filesystem device name. The SCSI address will be used to
2535
 
write to media, and the device name will be used when Cedar Backup needs to
2536
 
mount the media (for instance, when a validation check must be run).
2537
 
 
2538
 
See the section called ?Configuring your SCSI Device? for more information on
2539
 
SCSI devices and how they are configured.
 
2579
Step 3: Configure your CD-R or CD-RW drive.
 
2580
 
 
2581
Before using Cedar Backup, your writer device must be properly configured. If
 
2582
you have configured your CD writer hardware to work through the normal
 
2583
filesystem device path, then you just need to know the path to the device on
 
2584
disk (something like /dev/cdrw). Cedar Backup will use the this device path
 
2585
both when talking to cdrecord and when doing filesystem operations like running
 
2586
media validation.
 
2587
 
 
2588
Your other option is to configure your writer hardware like a SCSI device
 
2589
(either because it is a SCSI device or because you are using some sort of
 
2590
interface that makes it look like one). In this case, Cedar Backup will use the
 
2591
SCSI id when talking to cdrecord and the device path when running filesystem
 
2592
operations.
 
2593
 
 
2594
See the section called ?Configuring your Writer Device? for more information on
 
2595
writer devices and how they are configured.
2540
2596
 
2541
2597
Note
2542
2598
 
2543
2599
There is no need to set up your CD-R or CD-RW device if you have decided not to
2544
2600
execute the store action.
2545
2601
 
2546
 
Step 3: Configure your backup user.
 
2602
Step 4: Configure your backup user.
2547
2603
 
2548
2604
Choose a user to be used for backups. Some platforms may come with a ?ready
2549
2605
made? backup user. For other platforms, you may have to create a user yourself.
2556
2612
Standard Debian systems come with a user named backup. You may choose to stay
2557
2613
with this user or create another one.
2558
2614
 
2559
 
Step 4: Create your backup tree.
 
2615
Step 5: Create your backup tree.
2560
2616
 
2561
2617
Cedar Backup requires a backup directory tree on disk. This directory tree must
2562
2618
be roughly three times as big as the amount of data that will be backed up on a
2592
2648
package. If you would prefer, you can create the backup directory structure
2593
2649
within some existing Debian directory such as /var/backups or /var/tmp.
2594
2650
 
2595
 
Step 5: Modify the backup cron jobs.
2596
 
 
2597
 
There are four parts to a Cedar Backup run: collect, stage, store and purge.
2598
 
The usual way of setting off these steps is through a cron job. For more
2599
 
information on using cron, see the manpage for crontab(5).
2600
 
 
2601
 
Backing up large directories and creating ISO CD images can be intensive
2602
 
operations, and could slow your computer down significantly. Choose a backup
2603
 
time that will not interfere with normal use of your computer. Usually, you
2604
 
will want the backup to occur every day, but it is possible to configure cron
2605
 
to execute the backup only one day per week, three days per week, etc.
 
2651
Step 6: Create the Cedar Backup configuration file.
 
2652
 
 
2653
Following the instructions in the section called ?Configuration File Format?
 
2654
(above) create a configuration file for your machine. Since you are working
 
2655
with a pool of one, you must configure all four action-specific sections:
 
2656
collect, stage, store and purge.
 
2657
 
 
2658
The usual location for the Cedar Backup config file is /etc/cback.conf. If you
 
2659
change the location, make sure you edit your cronjobs (below) to point the
 
2660
cback script at the correct config file (using the --config option).
2606
2661
 
2607
2662
Warning
2608
2663
 
2609
 
Because of the way Cedar Backup works, you must ensure that your backup always
2610
 
run on the first day of your configured week. This is because Cedar Backup will
2611
 
only clear incremental backup information and re-initialize your media when
2612
 
running on the first day of the week. If you skip running Cedar Backup on the
2613
 
first day of the week, your backups will likely be ?confused? until either the
2614
 
next week, or until you re-run the backup using the --full flag.
 
2664
Configuration files should always be writable only by root (or by the file
 
2665
owner, if the owner is not root).
 
2666
 
 
2667
If you intend to place confidental information into the Cedar Backup
 
2668
configuration file, make sure that you set the filesystem permissions on the
 
2669
file appropriately. For instance, if you configure any extensions that require
 
2670
passwords or other similar information, you should make the file readable only
 
2671
to root or to the file owner (if the owner is not root).
 
2672
 
 
2673
Step 7: Validate the Cedar Backup configuration file.
 
2674
 
 
2675
Use the command cback validate to validate your configuration file. This
 
2676
command checks that the configuration file can be found and parsed, and also
 
2677
checks for typical configuration problems, such as invalid CD-R/CD-RW device
 
2678
entries.
 
2679
 
 
2680
Note: the most common cause of configuration problems is in not closing XML
 
2681
tags properly. Any XML tag that is ?opened? must be ?closed? appropriately.
 
2682
 
 
2683
Step 8: Test your backup.
 
2684
 
 
2685
Place a valid CD-R or CD-RW disc in your drive, and then use the command cback
 
2686
--full all. You should execute this command as root. If the command completes
 
2687
with no output, then the backup was run successfully.
 
2688
 
 
2689
Just to be sure that everything worked properly, check the logfile (/var/log/
 
2690
cback.log) for errors and also mount the CD-R or CD-RW disc to be sure it can
 
2691
be read.
 
2692
 
 
2693
If Cedar Backup ever completes ?normally? but the disc that is created is not
 
2694
usable, please report this as a bug. ^[28] To be safe, always enable the
 
2695
consistency check option in the store configuration section.
 
2696
 
 
2697
Step 9: Modify the backup cron jobs.
2615
2698
 
2616
2699
Since Cedar Backup should be run as root, one way to configure the cron job is
2617
2700
to add a line like this to your /etc/crontab file:
2632
2715
 
2633
2716
Note
2634
2717
 
 
2718
For general information about using cron, see the manpage for crontab(5).
 
2719
 
2635
2720
On a Debian system, execution of daily backups is controlled by the file /etc/
2636
2721
cron.d/cedar-backup2. As installed, this file contains several different
2637
2722
settings, all commented out. Uncomment the ?Single machine (pool of one)? entry
2638
2723
in the file, and change the line so that the backup goes off when you want it
2639
2724
to.
2640
2725
 
2641
 
Step 6: Create the Cedar Backup configuration file.
2642
 
 
2643
 
Following the instructions in the section called ?Configuration File Format?
2644
 
(above) create a configuration file for your machine. Since you are working
2645
 
with a pool of one, you must configure all four action-specific sections:
2646
 
collect, stage, store and purge.
2647
 
 
2648
 
The usual location for the Cedar Backup config file is /etc/cback.conf. If you
2649
 
change the location, make sure you edit your cronjobs (step 5) to point the
2650
 
cback script at the correct config file (using the --config option).
2651
 
 
2652
 
Warning
2653
 
 
2654
 
Configuration files should always be writable only by root (or by the file
2655
 
owner, if the owner is not root).
2656
 
 
2657
 
If you intend to place confidental information into the Cedar Backup
2658
 
configuration file, make sure that you set the filesystem permissions on the
2659
 
file appropriately. For instance, if you configure any extensions that require
2660
 
passwords or other similar information, you should make the file readable only
2661
 
to root or to the file owner (if the owner is not root).
2662
 
 
2663
 
Step 7: Validate the Cedar Backup configuration file.
2664
 
 
2665
 
Use the command cback validate to validate your configuration file. This
2666
 
command checks that the configuration file can be found and parsed, and also
2667
 
checks for typical configuration problems, such as invalid CD-R/CD-RW device
2668
 
entries.
2669
 
 
2670
 
Note: the most common cause of configuration problems is in not closing XML
2671
 
tags properly. Any XML tag that is ?opened? must be ?closed? appropriately.
2672
 
 
2673
 
Step 8: Test your backup.
2674
 
 
2675
 
Place a valid CD-R or CD-RW disc in your drive, and then use the command cback
2676
 
--full all. You should execute this command as root. If the command completes
2677
 
with no output, then the backup was run successfully.
2678
 
 
2679
 
Just to be sure that everything worked properly, check the logfile (/var/log/
2680
 
cback.log) for errors and also mount the CD-R or CD-RW disc to be sure it can
2681
 
be read.
2682
 
 
2683
 
If Cedar Backup ever completes ?normally? but the disc that is created is not
2684
 
usable, please report this as a bug. ^[28] To be safe, always enable the
2685
 
consistency check option in the store configuration section.
2686
 
 
2687
2726
Setting up a Client Peer Node
2688
2727
 
2689
2728
Cedar Backup has been designed to backup entire ?pools? of machines. In any
2704
2743
Note: all of these configuration steps should be run as the root user, unless
2705
2744
otherwise indicated.
2706
2745
 
2707
 
Step 1: Make sure email works.
 
2746
Step 1: Decide when you will run your backup.
 
2747
 
 
2748
There are four parts to a Cedar Backup run: collect, stage, store and purge.
 
2749
The usual way of setting off these steps is through a set of cron jobs.
 
2750
Although you won't create your cron jobs just yet, you should decide now when
 
2751
you will run your backup so you are prepared for later.
 
2752
 
 
2753
Backing up large directories and creating ISO CD images can be intensive
 
2754
operations, and could slow your computer down significantly. Choose a backup
 
2755
time that will not interfere with normal use of your computer. Usually, you
 
2756
will want the backup to occur every day, but it is possible to configure cron
 
2757
to execute the backup only one day per week, three days per week, etc.
 
2758
 
 
2759
Warning
 
2760
 
 
2761
Because of the way Cedar Backup works, you must ensure that your backup always
 
2762
runs on the first day of your configured week. This is because Cedar Backup
 
2763
will only clear incremental backup information and re-initialize your media
 
2764
when running on the first day of the week. If you skip running Cedar Backup on
 
2765
the first day of the week, your backups will likely be ?confused? until the
 
2766
next week begins, or until you re-run the backup using the --full flag.
 
2767
 
 
2768
Step 2: Make sure email works.
2708
2769
 
2709
2770
Cedar Backup relies on email for problem notification. This notification works
2710
2771
through the magic of cron. Cron will email any output from each job it executes
2719
2780
forward to some other user, so you do not need to check the root user's mail in
2720
2781
order to see Cedar Backup errors.
2721
2782
 
2722
 
Step 2: Configure the master in your backup pool.
 
2783
Step 3: Configure the master in your backup pool.
2723
2784
 
2724
2785
You will not be able to complete the client configuration until at least step 3
2725
2786
of the master's configuration has been completed. In particular, you will need
2734
2795
HgZooYqQ9pw+ZduXgmPcAAv2b5eTm07wRqFt/U84k6bhTzs= user@machine
2735
2796
 
2736
2797
 
2737
 
Step 3: Configure your backup user.
 
2798
Step 4: Configure your backup user.
2738
2799
 
2739
2800
Choose a user to be used for backups. Some platforms may come with a "ready
2740
2801
made" backup user. For other platforms, you may have to create a user yourself.
2777
2838
The important part is that the master must be able to SSH into a client with no
2778
2839
password entry required.
2779
2840
 
2780
 
Step 4: Create your backup tree.
 
2841
Step 5: Create your backup tree.
2781
2842
 
2782
2843
Cedar Backup requires a backup directory tree on disk. This directory tree must
2783
2844
be roughly as big as the amount of data that will be backed up on a nightly
2808
2869
package. If you would prefer, you can create the backup directory structure
2809
2870
within some existing Debian directory such as /var/backups or /var/tmp.
2810
2871
 
2811
 
Step 5: Modify the backup cron jobs.
2812
 
 
2813
 
There are two parts to a Cedar Backup run on a client: collect and purge. The
2814
 
usual way of setting off these steps is through a cron job. For more
2815
 
information on using cron, see the manpage for crontab(5).
2816
 
 
2817
 
Backing up large directories could slow your computer down significantly.
2818
 
Choose a backup time that will not interfere with normal use of your computer.
2819
 
Usually, you will want the backup to go occur every day, but it is possible to
2820
 
configure cron to execute the backup only one day per week, three days per
2821
 
week, etc.
2822
 
 
2823
 
Warning
2824
 
 
2825
 
Because of the way Cedar Backup works, you must ensure that at least your
2826
 
collect action always runs on the first day of your configured week. This is
2827
 
because Cedar Backup will only clear incremental backup information when
2828
 
running on the first day of the week. If you skip running the collect action on
2829
 
the first day of the week, your backups will likely be ?confused? until either
2830
 
the next week, or until you re-run the collect action backup using the --full
2831
 
flag.
2832
 
 
2833
 
Since Cedar Backup should be run as root, you should add a set of lines like
2834
 
this to your /etc/crontab file:
2835
 
 
2836
 
30 00 * * * root  cback collect
2837
 
30 06 * * * root  cback purge
2838
 
 
2839
 
 
2840
 
You should consider adding the --output or -O switch to your cback command-line
2841
 
in cron. This will result in larger logs, but could help diagnose problems when
2842
 
commands like cdrecord or mkisofs fail mysteriously.
2843
 
 
2844
 
You will need to coordinate the collect and purge actions on the client so that
2845
 
the collect action completes before the master attempts to stage, and so that
2846
 
the purge action does not begin until after the master has completed staging.
2847
 
Usually, allowing an hour or two between steps should be sufficient. ^[29]
2848
 
 
2849
 
Note
2850
 
 
2851
 
On a Debian system, execution of daily backups is controlled by the file /etc/
2852
 
cron.d/cedar-backup2. As installed, this file contains several different
2853
 
settings, all commented out. Uncomment the ?Client machine? entries in the
2854
 
file, and change the lines so that the backup goes off when you want it to.
2855
 
 
2856
2872
Step 6: Create the Cedar Backup configuration file.
2857
2873
 
2858
2874
Following the instructions in the section called ?Configuration File Format?
2861
2877
and purge actions.
2862
2878
 
2863
2879
The usual location for the Cedar Backup config file is /etc/cback.conf. If you
2864
 
change the location, make sure you edit your cronjobs (step 5) to point the
 
2880
change the location, make sure you edit your cronjobs (below) to point the
2865
2881
cback script at the correct config file (using the --config option).
2866
2882
 
2867
2883
Warning
2891
2907
output, then the backup was run successfully. Just to be sure that everything
2892
2908
worked properly, check the logfile (/var/log/cback.log) for errors.
2893
2909
 
 
2910
Step 9: Modify the backup cron jobs.
 
2911
 
 
2912
Since Cedar Backup should be run as root, you should add a set of lines like
 
2913
this to your /etc/crontab file:
 
2914
 
 
2915
30 00 * * * root  cback collect
 
2916
30 06 * * * root  cback purge
 
2917
 
 
2918
 
 
2919
You should consider adding the --output or -O switch to your cback command-line
 
2920
in cron. This will result in larger logs, but could help diagnose problems when
 
2921
commands like cdrecord or mkisofs fail mysteriously.
 
2922
 
 
2923
You will need to coordinate the collect and purge actions on the client so that
 
2924
the collect action completes before the master attempts to stage, and so that
 
2925
the purge action does not begin until after the master has completed staging.
 
2926
Usually, allowing an hour or two between steps should be sufficient. ^[29]
 
2927
 
 
2928
Note
 
2929
 
 
2930
For general information about using cron, see the manpage for crontab(5).
 
2931
 
 
2932
On a Debian system, execution of daily backups is controlled by the file /etc/
 
2933
cron.d/cedar-backup2. As installed, this file contains several different
 
2934
settings, all commented out. Uncomment the ?Client machine? entries in the
 
2935
file, and change the lines so that the backup goes off when you want it to.
 
2936
 
2894
2937
Setting up a Master Peer Node
2895
2938
 
2896
2939
Cedar Backup has been designed to backup entire ?pools? of machines. In any
2919
2962
staging directory), you can do that. You'll just have to modify the procedure
2920
2963
below based on information in the remainder of the manual.
2921
2964
 
2922
 
Step 1: Make sure email works.
 
2965
Step 1: Decide when you will run your backup.
 
2966
 
 
2967
There are four parts to a Cedar Backup run: collect, stage, store and purge.
 
2968
The usual way of setting off these steps is through a set of cron jobs.
 
2969
Although you won't create your cron jobs just yet, you should decide now when
 
2970
you will run your backup so you are prepared for later.
 
2971
 
 
2972
Keep in mind that you do not necessarily have to run the collect action on the
 
2973
master. See notes further below for more information.
 
2974
 
 
2975
Backing up large directories and creating ISO CD images can be intensive
 
2976
operations, and could slow your computer down significantly. Choose a backup
 
2977
time that will not interfere with normal use of your computer. Usually, you
 
2978
will want the backup to occur every day, but it is possible to configure cron
 
2979
to execute the backup only one day per week, three days per week, etc.
 
2980
 
 
2981
Warning
 
2982
 
 
2983
Because of the way Cedar Backup works, you must ensure that your backup always
 
2984
runs on the first day of your configured week. This is because Cedar Backup
 
2985
will only clear incremental backup information and re-initialize your media
 
2986
when running on the first day of the week. If you skip running Cedar Backup on
 
2987
the first day of the week, your backups will likely be ?confused? until the
 
2988
next week begins, or until you re-run the backup using the --full flag.
 
2989
 
 
2990
Step 2: Make sure email works.
2923
2991
 
2924
2992
Cedar Backup relies on email for problem notification. This notification works
2925
2993
through the magic of cron. Cron will email any output from each job it executes
2934
3002
forward to some other user, so you do not need to check the root user's mail in
2935
3003
order to see Cedar Backup errors.
2936
3004
 
2937
 
Step 2: Configure your CD-R or CD-RW drive.
2938
 
 
2939
 
Your CD-R or CD-RW drive must either be a SCSI device or must be configured to
2940
 
act like a SCSI device from the perspective of the cdrecord and mkisofs
2941
 
commands. Regardless of what kind of drive you have, make sure you know its
2942
 
SCSI address and its filesystem device name. The SCSI address will be used to
2943
 
write to media, and the device name will be used when Cedar Backup needs to
2944
 
mount the media (for instance, when a validation check must be run).
2945
 
 
2946
 
See the section called ?Configuring your SCSI Device? for more information on
2947
 
SCSI devices and how they are configured.
 
3005
Step 3: Configure your CD-R or CD-RW drive.
 
3006
 
 
3007
Before using Cedar Backup, your writer device must be properly configured. If
 
3008
you have configured your CD writer hardware to work through the normal
 
3009
filesystem device path, then you just need to know the path to the device on
 
3010
disk (something like /dev/cdrw). Cedar Backup will use the this device path
 
3011
both when talking to cdrecord and when doing filesystem operations like running
 
3012
media validation.
 
3013
 
 
3014
Your other option is to configure your writer hardware like a SCSI device
 
3015
(either because it is a SCSI device or because you are using some sort of
 
3016
interface that makes it look like one). In this case, Cedar Backup will use the
 
3017
SCSI id when talking to cdrecord and the device path when running filesystem
 
3018
operations.
 
3019
 
 
3020
See the section called ?Configuring your Writer Device? for more information on
 
3021
writer devices and how they are configured.
2948
3022
 
2949
3023
Note
2950
3024
 
2951
3025
There is no need to set up your CD-R or CD-RW device if you have decided not to
2952
3026
execute the store action.
2953
3027
 
2954
 
Step 3: Configure your backup user.
 
3028
Step 4: Configure your backup user.
2955
3029
 
2956
3030
Choose a user to be used for backups. Some platforms may come with a ?ready
2957
3031
made? backup user. For other platforms, you may have to create a user yourself.
2989
3063
The important part is that the master must be able to SSH into a client with no
2990
3064
password entry required.
2991
3065
 
2992
 
Step 4: Create your backup tree.
 
3066
Step 5: Create your backup tree.
2993
3067
 
2994
3068
Cedar Backup requires a backup directory tree on disk. This directory tree must
2995
3069
be roughly large enough hold twice as much data as will be backed up from the
3024
3098
package. If you would prefer, you can create the backup directory structure
3025
3099
within some existing Debian directory such as /var/backups or /var/tmp.
3026
3100
 
3027
 
Step 5: Modify the backup cron jobs.
3028
 
 
3029
 
There are four parts to a Cedar Backup run: collect, stage, store and purge.
3030
 
The usual way of setting off these steps is through a cron job. For more
3031
 
information on using cron, see the manpage for crontab(5).
3032
 
 
3033
 
Note
3034
 
 
3035
 
Keep in mind that you do not necessarily have to run the collect action on the
3036
 
master. See notes further below for more information.
3037
 
 
3038
 
Backing up large directories and creating ISO CD images can be intensive
3039
 
operations, and could slow your computer down significantly. Choose a backup
3040
 
time that will not interfere with normal use of your computer. Usually, you
3041
 
will want the backup to go occur every day, but it is possible to configure
3042
 
cron to execute the backup only one day per week, three days per week, etc.
3043
 
 
3044
 
Warning
3045
 
 
3046
 
Because of the way Cedar Backup works, you must ensure that at least your
3047
 
collect and store actions always run on the first day of your configured week.
3048
 
This is because Cedar Backup will only clear incremental backup information and
3049
 
re-initialize your media when running on the first day of the week. If you skip
3050
 
running Cedar Backup on the first day of the week, your backups will likely be
3051
 
?confused? until either the next week, or until you re-run the collect and
3052
 
store actions using the --full flag.
3053
 
 
3054
 
Since Cedar Backup should be run as root, you should add a set of lines like
3055
 
this to your /etc/crontab file:
3056
 
 
3057
 
30 00 * * * root  cback collect
3058
 
30 02 * * * root  cback stage
3059
 
30 04 * * * root  cback store
3060
 
30 06 * * * root  cback purge
3061
 
 
3062
 
 
3063
 
You should consider adding the --output or -O switch to your cback command-line
3064
 
in cron. This will result in larger logs, but could help diagnose problems when
3065
 
commands like cdrecord or mkisofs fail mysteriously.
3066
 
 
3067
 
You will need to coordinate the collect and purge actions on clients so that
3068
 
their collect actions complete before the master attempts to stage, and so that
3069
 
their purge actions do not begin until after the master has completed staging.
3070
 
Usually, allowing an hour or two between steps should be sufficient. ^[29]
3071
 
 
3072
 
Note
3073
 
 
3074
 
On a Debian system, execution of daily backups is controlled by the file /etc/
3075
 
cron.d/cedar-backup2. As installed, this file contains several different
3076
 
settings, all commented out. Uncomment the ?Master machine? entries in the
3077
 
file, and change the lines so that the backup goes off when you want it to.
3078
 
 
3079
3101
Step 6: Create the Cedar Backup configuration file.
3080
3102
 
3081
3103
Following the instructions in the section called ?Configuration File Format?
3096
3118
collect data on the master itself.
3097
3119
 
3098
3120
The usual location for the Cedar Backup config file is /etc/cback.conf. If you
3099
 
change the location, make sure you edit your cronjobs (step 5) to point the
 
3121
change the location, make sure you edit your cronjobs (below) to point the
3100
3122
cback script at the correct config file (using the --config option).
3101
3123
 
3102
3124
Warning
3157
3179
usable, please report this as a bug. ^[28] To be safe, always enable the
3158
3180
consistency check option in the store configuration section.
3159
3181
 
3160
 
Configuring your SCSI Device
3161
 
 
3162
 
SCSI Required
3163
 
 
3164
 
In order to execute the store action, your CD-R or CD-RW drive must either be a
3165
 
SCSI device or must be configured to act like a SCSI device from the
3166
 
perspective of the cdrecord and mkisofs commands. Regardless of what kind of
3167
 
drive you have, make sure you know its SCSI address and its filesystem device
3168
 
name. The SCSI address will be used to write to media, and the device name will
3169
 
be used when Cedar Backup needs to mount the media (for instance, when a
3170
 
validation check must be run).
 
3182
Step 10: Modify the backup cron jobs.
 
3183
 
 
3184
Since Cedar Backup should be run as root, you should add a set of lines like
 
3185
this to your /etc/crontab file:
 
3186
 
 
3187
30 00 * * * root  cback collect
 
3188
30 02 * * * root  cback stage
 
3189
30 04 * * * root  cback store
 
3190
30 06 * * * root  cback purge
 
3191
 
 
3192
 
 
3193
You should consider adding the --output or -O switch to your cback command-line
 
3194
in cron. This will result in larger logs, but could help diagnose problems when
 
3195
commands like cdrecord or mkisofs fail mysteriously.
 
3196
 
 
3197
You will need to coordinate the collect and purge actions on clients so that
 
3198
their collect actions complete before the master attempts to stage, and so that
 
3199
their purge actions do not begin until after the master has completed staging.
 
3200
Usually, allowing an hour or two between steps should be sufficient. ^[29]
 
3201
 
 
3202
Note
 
3203
 
 
3204
For general information about using cron, see the manpage for crontab(5).
 
3205
 
 
3206
On a Debian system, execution of daily backups is controlled by the file /etc/
 
3207
cron.d/cedar-backup2. As installed, this file contains several different
 
3208
settings, all commented out. Uncomment the ?Master machine? entries in the
 
3209
file, and change the lines so that the backup goes off when you want it to.
 
3210
 
 
3211
Configuring your Writer Device
 
3212
 
 
3213
SCSI Devices
 
3214
 
 
3215
In order to execute the store action for a SCSI writer device, you need to know
 
3216
the device's SCSI address and also its filesystem device name. The SCSI id
 
3217
(<target_scsi_id>) will be used to write to media using cdrecord; and the
 
3218
device name (<target_device>) will be used for other filesystem operations ?
 
3219
for instance, when the media needs to be mounted to run the consistency check.
3171
3220
 
3172
3221
A true SCSI device will always have an address scsibus,target,lun, for instance
3173
3222
1,6,2. This should hold true on most UNIX-like systems including Linux and the
3175
3224
SCSI address represents the location of your writer device on the one or more
3176
3225
SCSI buses that you have available on your system.
3177
3226
 
 
3227
Non-SCSI Devices
 
3228
 
 
3229
On some platforms, it is possible to reference non-SCSI writer devices (like
 
3230
IDE CD writers) using an emulated SCSI id. If you have configured your non-SCSI
 
3231
writer device to have an emulated SCSI id, provide the filesystem device path
 
3232
in <target_device> and the SCSI id in <target_scsi_id>, just like for a real
 
3233
SCSI device.
 
3234
 
 
3235
On other platforms, it is possible to reference non-SCSI writer devices
 
3236
directly by filesystem device path rather than through SCSI emulation. On these
 
3237
platforms, you should configure Cedar Backup with a <target_device> value but
 
3238
not a <target_scsi_id> value.
 
3239
 
 
3240
You should note that in some cases, an emulated SCSI id takes the same form as
 
3241
a normal SCSI id (?scsibus,target,lun?), while in other cases you might see a
 
3242
method name prepended to the normal SCSI id.
 
3243
 
3178
3244
Linux Notes
3179
3245
 
3180
3246
On a Linux system, IDE writer devices often have a simulated SCSI address,
3181
3247
which allows SCSI-based software to access the device through an IDE-to-SCSI
3182
3248
interface. Under these circumstances, the first IDE writer device typically has
3183
 
an address 0,0,0. Newer Linux systems (kernel 2.6.x) can also be compiled with
3184
 
support for other kinds of CD drive interfaces. If your kernel supports it, you
3185
 
can address ATA or ATAPI drives without SCSI emulation by prepending an
3186
 
indicator to the simulated device address, for instance ATA:0,0,0 or
3187
 
ATAPI:0,0,0.
3188
 
 
3189
 
A discussion of how to configure your CD writer hardware is outside the scope
3190
 
of this document, but you may want to reference the Linux CDROM HOWTO (http://
 
3249
an address 0,0,0. However, support for the IDE-to-SCSI interface has been
 
3250
deprecated and is not well-supported in newer kernels (kernel 2.6.x and later).
 
3251
 
 
3252
Newer Linux kernels can address ATA or ATAPI drives without SCSI emulation by
 
3253
prepending a ?method? indicator to the simulated device address. For instance,
 
3254
ATA:0,0,0 or ATAPI:0,0,0 are typical values.
 
3255
 
 
3256
However, even this interface is deprecated as of late 2006, so with relatively
 
3257
new kernels you may be better off using the filesystem device path directly
 
3258
rather than relying on any SCSI emulation, as discussed above.
 
3259
 
 
3260
Here are some hints about how to find your Linux hardware. First, try to
 
3261
reference your device using the filesystem device path:
 
3262
 
 
3263
cdrecord -prcap dev=/dev/cdrom
 
3264
 
 
3265
 
 
3266
Running this command on my hardware gives output that looks like this (just the
 
3267
top few lines):
 
3268
 
 
3269
Device type    : Removable CD-ROM
 
3270
Version        : 0
 
3271
Response Format: 2
 
3272
Capabilities   :
 
3273
Vendor_info    : 'LITE-ON '
 
3274
Identification : 'DVDRW SOHW-1673S'
 
3275
Revision       : 'JS02'
 
3276
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
 
3277
 
 
3278
Drive capabilities, per MMC-3 page 2A:
 
3279
 
 
3280
 
 
3281
If this works, and the identifying information at the top of the output looks
 
3282
like your CD writer device, you've probably found a working configuration.
 
3283
Place the device path into <target_device> and leave <target_scsi_id> blank.
 
3284
 
 
3285
If this doesn't work, you should try to find an ATA or ATAPI device:
 
3286
 
 
3287
cdrecord -scanbus dev=ATA
 
3288
cdrecord -scanbus dev=ATAPI
 
3289
 
 
3290
 
 
3291
On my development system, I get a result that looks something like this for
 
3292
ATA:
 
3293
 
 
3294
scsibus1:
 
3295
        1,0,0   100) 'LITE-ON ' 'DVDRW SOHW-1673S' 'JS02' Removable CD-ROM
 
3296
        1,1,0   101) *
 
3297
        1,2,0   102) *
 
3298
        1,3,0   103) *
 
3299
        1,4,0   104) *
 
3300
        1,5,0   105) *
 
3301
        1,6,0   106) *
 
3302
        1,7,0   107) *
 
3303
 
 
3304
 
 
3305
Again, if you get a result that you recognize, you have again probably found a
 
3306
working configuraton. Place the associated device path (in my case, /dev/cdrom)
 
3307
into <target_device> and put the emulated SCSI id (in this case, ATA:1,0,0)
 
3308
into <target_scsi_id>.
 
3309
 
 
3310
Any further discussion of how to configure your CD writer hardware is outside
 
3311
the scope of this document. If you have tried the hints above and still can't
 
3312
get things working, you may want to reference the Linux CDROM HOWTO (http://
3191
3313
www.tldp.org/HOWTO/CDROM-HOWTO) or the ATA RAID HOWTO (http://www.tldp.org/
3192
3314
HOWTO/ATA-RAID-HOWTO/index.html) for more information.
3193
3315
 
3275
3397
      <name>sysinfo</name>
3276
3398
      <module>CedarBackup2.extend.sysinfo</module>
3277
3399
      <function>executeAction</function>
3278
 
      <index>101</index>
 
3400
      <index>99</index>
3279
3401
   </action>
3280
3402
</extensions>
3281
3403
 
3313
3435
      <name>subversion</name>
3314
3436
      <module>CedarBackup2.extend.subversion</module>
3315
3437
      <function>executeAction</function>
3316
 
      <index>101</index>
 
3438
      <index>99</index>
3317
3439
   </action>
3318
3440
</extensions>
3319
3441
 
3484
3606
      <name>mysql</name>
3485
3607
      <module>CedarBackup2.extend.mysql</module>
3486
3608
      <function>executeAction</function>
3487
 
      <index>101</index>
 
3609
      <index>99</index>
3488
3610
   </action>
3489
3611
</extensions>
3490
3612
 
3619
3741
      <name>postgresql</name>
3620
3742
      <module>CedarBackup2.extend.postgresql</module>
3621
3743
      <function>executeAction</function>
3622
 
      <index>101</index>
 
3744
      <index>99</index>
3623
3745
   </action>
3624
3746
</extensions>
3625
3747
 
3733
3855
      <name>mbox</name>
3734
3856
      <module>CedarBackup2.extend.mbox</module>
3735
3857
      <function>executeAction</function>
3736
 
      <index>101</index>
 
3858
      <index>99</index>
3737
3859
   </action>
3738
3860
</extensions>
3739
3861