]>
Commit | Line | Data |
---|---|---|
d37187a4 SP |
1 | Dump/Restore Ultra-Mini-FAQ |
2 | ||
c79a759f SP |
3 | Document v1.1 |
4 | ||
5 | Disclaimer: I am not an expert in dump/restore. In | |
6 | fact, I'm a newbie. But I've been picking things up as | |
7 | I implement it here and I wanted to pass some of those | |
8 | things along in the form of a very basic FAQ. | |
d37187a4 SP |
9 | |
10 | -Patrick Walsh | |
11 | ||
12 | 1) Introduction/ Non-rewinding device | |
13 | 2) Dump command line | |
14 | 3) Sending 2 or more filesystems to a tape | |
15 | 4) Compressing dumps on the fly | |
16 | 5) The "nodump" file and directory attribute. | |
17 | 6) Restoring your dumps (including compressed). | |
c79a759f SP |
18 | 7) How to confirm a backup (highly recommended) |
19 | 8) What are the best buffer size options? | |
20 | 9) Experiencing bread, lseek, lseek2 errors. | |
21 | 10) Example backup script | |
d37187a4 SP |
22 | |
23 | 1) Introduction/ Non-rewinding device | |
24 | ||
25 | You use dump to backup to a file or a tape device. If | |
c79a759f SP |
26 | you're backing up to a tape device, then the first |
27 | thing you need to understand is that there are two | |
28 | devices that refer to your tape drive. There is the | |
29 | "rewinding" device and the "non-rewinding" device. | |
d37187a4 SP |
30 | |
31 | I wish I could tell you an easy way to figure out what | |
32 | your device names are, but I don't know one. On my | |
33 | local box I had a /dev/tape device that linked to | |
34 | /dev/st0. It turns out that /dev/st0 is my "rewinding" | |
35 | tape drive. If I write to this device it will always | |
36 | rewind before starting to write. This means that if | |
37 | you try to dump two filesystems, only the second one | |
38 | will be stored. If your tape device is /dev/st0, like | |
39 | mine, then your non-rewinding tape device is probably | |
40 | /dev/nst0. | |
41 | ||
42 | Anyway, through the rest of this I will refer to $TAPE | |
43 | and $RWTAPE. $TAPE is the non-rewinding device (in my | |
c79a759f SP |
44 | case /dev/nst0) and $RWTAPE is the rewinding tape (in |
45 | my case /dev/st0 and /dev/tape). $FS is the filesystem | |
46 | you are backing up, such as /dev/hda1. | |
d37187a4 SP |
47 | |
48 | 2) What options should I use? | |
49 | ||
50 | Use the man page to figure out what options to send | |
51 | to dump. I use "dump 0uanf $TAPE $FS". | |
52 | ||
53 | u=update /etc/dumpdates after a successful dump | |
c79a759f SP |
54 | a=auto-size -- bypass all tape length calculations |
55 | and write until eof | |
d37187a4 SP |
56 | n=notify 'operators' group when dump needs attention |
57 | f=backup to file or device specified, or - for stdout | |
58 | ||
c79a759f | 59 | 3) You want to send two or more filesystems to tape. |
d37187a4 | 60 | |
c79a759f SP |
61 | OK, rewind using the mt command, then dump multiple |
62 | times to the non-rewinding device, and you're done: | |
d37187a4 SP |
63 | |
64 | mt -f $TAPE rewind | |
65 | dump 0uanf $TAPE $FS1 | |
66 | dump 0uanf $TAPE $FS2 | |
67 | etc. | |
68 | ||
c79a759f SP |
69 | Check the man page of mt if you want to know how to |
70 | eject the tape or retension it or anything. | |
d37187a4 SP |
71 | |
72 | 4) You want to compress your dumps on the fly. No | |
73 | problem. Send your backup to STDOUT and manipulate it | |
c79a759f SP |
74 | from there. It's easier if you're sending your output |
75 | to the hard drive: | |
d37187a4 SP |
76 | |
77 | dump 0uanf - $FS | gzip -c > /backup/outfile.dump.gz | |
78 | ||
c79a759f SP |
79 | You want that to be written to the tape on the fly? |
80 | Try this: | |
d37187a4 SP |
81 | |
82 | mt -f $TAPE rewind | |
83 | dump 0uanf - $FS |gzip -c |dd if=- of=$TAPE | |
84 | ||
85 | [ You can also use the -z or -J options of dump in the | |
86 | recent versions to enable internal compression - stelian ] | |
87 | ||
88 | 5) You read the man page and you're wondering what the | |
89 | heck a "nodump" flag is. For example, how can you get | |
90 | dump to stop backing up /tmp or ~/.netscape/cache. You | |
91 | have two options: either exclude the inode in your dump | |
92 | command, or flag the files and directories with the | |
93 | "nodump" flag. To flag /tmp, for example, do this: | |
94 | ||
95 | chattr -R +d /tmp | |
96 | ||
97 | Want more details? Try 'man chattr' and 'man lsattr'. | |
98 | ||
99 | 6) You want to know how to restore your backup. | |
100 | ||
c79a759f SP |
101 | Read the restore man page. But barring that, the easy |
102 | way is to use restore in interactive mode. If you have | |
103 | three filesystems on one tape and you want to restore | |
104 | files from the second one, you need to do this: | |
d37187a4 SP |
105 | |
106 | mt -f $TAPE rewind | |
107 | mt -f $TAPE fsf 1 # skip forward one file | |
108 | restore -if $TAPE | |
109 | ||
c79a759f SP |
110 | OK, suppose now that you used the commands in section 4 |
111 | to compress the dump file before it was written to | |
112 | disk. Use this command: | |
d37187a4 SP |
113 | |
114 | mt -f $TAPE rewind | |
115 | mt -f $TAPE fsf 1 | |
116 | dd if=$TAPE of=- |gzip -dc |restore -rf - | |
117 | ||
c79a759f SP |
118 | Obviously if you dumped to a file instead of a tape it |
119 | is much easier: | |
d37187a4 SP |
120 | |
121 | gzip -dc $filename |restore -rf - | |
122 | ||
123 | 7) How to confirm your backup | |
124 | ||
c79a759f SP |
125 | Check out the restore man page and read up on the -C |
126 | option. | |
127 | ||
128 | 8) What are the best buffer size options? | |
129 | ||
130 | Bernhard R. Erdmann answered this question on the | |
131 | dump-users mailing list. His excellent response | |
132 | follows: | |
133 | ||
134 | >> While I was doing google searches, there seems to be | |
135 | >> an issue regarding the default buffer size writing | |
136 | >> to tape. According to some, the default buffer size | |
137 | >> of 512 can harm modern drives. I have a Seagate | |
138 | >> DDS3 unit and am wondering what the best mt/dump | |
139 | >> options are. I am using datacompression in | |
140 | >> hardware. Should I go with a large buffer (mt | |
141 | >> setblk 10240) or variable (mt setblk 0). If I | |
142 | >> change these sizes, does dump need to know about it? | |
143 | > | |
144 | >Dump/restore uses a default blocksize of 10 KB. You | |
145 | >can change it with the "-b" option or use dd for | |
146 | >(re-)blocking. | |
147 | > | |
148 | >dump 0ab 32 / | |
149 | >dump 0af - / | dd obs=32k of=$TAPE | |
150 | >ssh host "/sbin/dump 0af - /" | dd obs=32k of=$TAPE | |
151 | >restore rb 32 | |
152 | >dd ibs=32k if=$TAPE | restore rf - | |
153 | >ssh host "dd if=/dev/nst0 ibs=32k" | restore rf - | |
154 | > | |
155 | >Personally, I'd stick with variable blocksize on the | |
156 | >drive and use 32 KB as the application's blocksize as | |
157 | >Amanda uses that size, too. | |
158 | > | |
159 | >Rumours told using 64 KB or 128 KB blocksize yields to | |
160 | >increase performance (maybe on the mtx list from an | |
161 | >Arkeia developer) didn't had any effects in my own | |
162 | >tests with blocksizes ranging from 10 to 64 KB some | |
163 | >months ago on a DDS-2 drive. | |
164 | > | |
165 | >Regarding tape drive performance at different block | |
166 | >sizes you may want to read | |
167 | >http://www.rs6000.ibm.com/support/micro/tapewhdr.html#Header_133 | |
168 | > | |
169 | >- Block size, can effect the time for backup/restore. | |
170 | >Using large blocksizes may improve performance. Using | |
171 | >small block sizes can increase system overhead but | |
172 | >before changing to a large blocksize it is necessary | |
173 | >to be sure the user application supports the larger | |
174 | >blocksize chosen. | |
175 | >- Very long restore times due to blocksize. If a | |
176 | >backup is done with a fixed block length then the | |
177 | >restore should be done with the same fixed block | |
178 | >length. If a backup is done with a fixed block length | |
179 | >and the restore is done with variable block length, | |
180 | >the restore may work successfully but it may take many | |
181 | >more hours to restore than it took to back up the | |
182 | >data. The reason for this is that when AIX reads fixed | |
183 | >block length data in variable block mode, a check | |
184 | >condition is issued by the tape drive on every read. | |
185 | >AIX must interpret every check condition and determine | |
186 | >the proper action to take. This often will put the | |
187 | >tape drive into a mode of reading that will require | |
188 | >the tape drive to stop tape motion, rewind the tape | |
189 | >some distance, then start reading again. This will | |
190 | >reduce the life expectancy of the tape and increase | |
191 | >the time it takes to backup data. | |
192 | ||
193 | 9) Experiencing bread, lseek, and lseek2 errors. | |
194 | ||
195 | These errors are caused by inodes being changed | |
196 | during the backup. This is normal because dump and | |
197 | the Linux kernel are both acessing the filesystem | |
198 | and there is no consistence checking. By "calming" | |
199 | the system (killing unnecessary processes), you | |
200 | decrease the likelihood of having these | |
201 | errors. Read up on the bug on Sourcefourge: | |
202 | ||
203 | http://sourceforge.net/tracker/index.php?func=detail&aid=204909&group_id=1306&atid=101306 | |
204 | ||
205 | Note that the only "real" solution to this problem | |
206 | is to dump a unmounted filesystem or use a filesystem | |
207 | snapshot feature (like in LVM). | |
208 | ||
209 | 10) That about sums up my knowledge on the matter, but | |
210 | I feel better having written something for other peopleto look at so it doesn't take them quite so long to | |
211 | learn the things I did. I've included my backup script | |
212 | below. There are much better ones floating around, so | |
213 | go find someone else's and use theirs if mine won't | |
214 | work for you or you don't understand it. | |
d37187a4 SP |
215 | |
216 | ||
217 | #!/bin/csh | |
218 | # System backup script for NARNIA | |
219 | ||
220 | # This is a script that will backup the entire hard drive | |
221 | # to the NT server (not my choice) \\fs1. | |
222 | # | |
223 | # On each Sunday night, a full backup will be made | |
224 | # of the hard drive and each day of the week thereafter an incremental | |
225 | # backup will be made that captures only those changes since the night | |
226 | # before. | |
227 | # Each full backup will be sent to the local tape as well as to the | |
228 | # NT machine. | |
229 | # | |
230 | # The files will be stored in partition-specific files with integer | |
231 | # endings that specify the day of the week they were saved. Files | |
232 | # with zero on the end will always be full backups. | |
233 | ||
234 | # Dump options: | |
235 | # a=auto-size -- bypass all tape length calculations and write until eof | |
236 | # f=write the backup to file or device specified or - for stdout | |
237 | # n=notify operators group when dump needs attention | |
238 | # u=update /etc/dumpdates after a successful dump | |
239 | ||
240 | # Set variables that control the script. | |
241 | setenv MOUNTPOINT '/root/fs1backup' | |
242 | setenv OUTDIR '/root/fs1backup/narnia' | |
243 | setenv TAPE '/dev/nst0' # non-rewinding tape | |
244 | ||
245 | # Auto-set variable that determines level of backup. | |
246 | setenv DAY `date +'%w'` | |
247 | ||
248 | # Mount the backup partition to /root/fs1backup | |
249 | /usr/bin/smbmount \\\\fs1\\backup $MOUNTPOINT -o | |
250 | "username=uname,password=pword" | |
251 | ||
252 | # Delete files created on this day last week | |
253 | rm -f $OUTDIR/*$DAY.dump.gz | |
254 | ||
255 | # Do the actual backing up, one filesystem at a time. | |
256 | ||
257 | # /dev/hda1 = /boot | |
258 | /sbin/dump $DAY'uanf' - /dev/hda1 | gzip -c >$OUTDIR/boot-$DAY.dump.gz | |
259 | ||
260 | # /dev/hda2 = / | |
261 | /sbin/dump $DAY'uanf' - /dev/hda2 | gzip -c >$OUTDIR/root-$DAY.dump.gz | |
262 | ||
263 | # /dev/hda3 = /usr | |
264 | /sbin/dump $DAY'uanf' - /dev/hda3 | gzip -c >$OUTDIR/usr-$DAY.dump.gz | |
265 | ||
266 | # /dev/hdb2 = /u1 | |
267 | /sbin/dump $DAY'uanf' - /dev/hdb2 | gzip -c >$OUTDIR/u1-$DAY.dump.gz | |
268 | ||
269 | ||
270 | # OK, presumably everything is now backed up to \\fs1. On level 0 | |
271 | # dumps, lets backup to the local drive too. | |
272 | if ($DAY == 0) then | |
273 | mt -f $TAPE retension | |
274 | foreach i ($OUTDIR/*0.dump.gz) | |
275 | dd if=$i of=$TAPE | |
276 | end | |
277 | mt -f $TAPE rewind | |
278 | endif | |
279 | ||
280 | ||
281 | # Unmount the backup partition, not needed outside of script | |
282 | umount /root/fs1backup | |
283 | ||
284 | # Explicitly free up the temporary variables | |
285 | unsetenv DAY | |
286 | unsetenv MOUNTPOINT | |
287 | unsetenv OUTDIR | |
288 | unsetenv TAPE | |
289 | ||
290 | ||
291 | # RESTORE DIRECTIONS: | |
292 | # If from tape: | |
293 | # dd if=$TAPE of=- | gzip -dc | restore -rf - | |
294 | # or dd if=$TAPE |gzip -dc |restore -rf - | |
295 | # | |
296 | # Note: must queue tape to proper position first. This | |
297 | # is done by first rewinding then advancing to the proper | |
298 | # file. The order that files are written to tape is | |
299 | # *probably* 0=/boot 1=/ 2=/usr 3=/u1 | |
300 | # | |
301 | # Use mt to skip between them: | |
302 | # mt -f $TAPE rewind | |
303 | # restore -if $TAPE #now restoring /boot, probably | |
304 | # mt -f $TAPE fsf 1 | |
305 | # restore -if $TAPE #now restoring / | |
306 | # mt -f $TAPE fsf 1 | |
307 | # restore -if $TAPE #now restoring /usr | |
308 | # #etc. | |
309 | # | |
310 | # Otherwise: | |
311 | # gzip -dc $filename | restore -rf - | |
312 | ||
c79a759f SP |
313 | |
314 |