Disaster recovery.
I've been starting to work on a DRP plan here and I've run into a bit of a catch-22. If the amanda index (and tape in my case) server is lost and all I have left is the tapes. How do I rebuild new index files for my tapes so that I can restore? I can't just restore the last set of index files from the most recent backup because they would reflect the state of the tapes from one day earlier (wouldn't they?). I can't find a tool that I can feed the collection of tapes so that it will rebuild the index files. Is there such a thing. Ean Kingston ([EMAIL PROTECTED]) Analyst Kanetix Ltd. (www.kanetix.com) Phone: (416) 599-9779 x216
Re: building 2.4.4p1 under Solaris 9 with native-built gcc-3.3(fwd)
On Wed, 2003-07-30 at 17:45, Craig Dewick wrote: Further to this issue, I have now tried, for the sake of experimentation (after a few people have contacted me privately suggesting it), setting LD_LIBRARY_PATH. I set it just to have /usr/local/lib in the variable. As I understand things. The LD_LIBRARY_PATH variable is used at run time as an additional search path for loadable modules (.so files). If you have it set while compiling, it will search that path for loadable modules but will not include it in the compiled in path to search for them. Using the -R (or -L) flag with the compiler adds the path to the search list built into the binary at build time. Also, have a look at the crle command. It lets you change the default search path for shared libraries at a system level (instead of having to always set LD_LIBRARY_PATH). -- Ean Kingston [EMAIL PROTECTED]
RE: to compress or not to compress ???
I Have the opposite viewpoint. I prefer hardware compression. It allows me to offload processing required to the tape drive (instead of my computers) Since some of my systems (including the backup server itself) can be slow, this actually speeds things up for me. Also, with hardware compression, I know I can restore the tape without having to worry about finding the right libraries and programs to do the restore. Also (AFAIK) you can't do remote compression with samba which I use for about half of my backups. On the down side, I need more holding disk and I have to guess at my tape capacity. As for both, don't do it. That is a huge waste of cpu and tape. The first compression algorithm will work fine. The second one will waste space with its headers and such since it probably won't be able to get the data any smaller than the software compression program did. If you don't believe me, try to zip a gzip file. See if it gets any smaller. -Original Message- From: Kurt Yoder [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 11:57 AM To: Michael D. Schleif Cc: amanda mailing list Subject: Re: to compress or not to compress ??? Michael D. Schleif said: [1] Should I use hardware compression? There seem to be several schools of thought here. I want to know how Amanda works with hardware compression? What are the advantages of using software compression? What are the disadvantages of using *both* hardware and software compression? I prefer software compression personally: -Amanda can make a more accurate estimate of how much tape is needed. So if you know your tape is 20 GB, and your software-compressed dump files total 21 GB, you know they won't all fit. With hardware compression you just have to guess-timate -Less bandwidth consumed if you do your compression on the client side (eg, before it comes to the tape server) -Less disk space used on your holding disk -If you back up to disks instead of tapes, hardware compression is not even an option The only drawback to software compression that I can see is the greater amount of cpu power consumed. For me, this is not really a problem, since my backups all happen in the wee hours when no-one is on my systems anyway. -- Kurt Yoder Sport Health network administrator
problem with amplot
I'm trying to run amplot and get the following error message: /var/amanda/test/logs$ amplot amdump.1 Displaying graph on the screen, CR for next graph cat: cannot open amdump.1 : MISSING SPACE DECLARATION gnuplot load 'title' ^ Cannot open load file 'title' /opt/amanda/libexec/amplot.gp, line 61: (No such file or directory) So, what should I do to fix this? In case it matters; this is Amanda 2.4.4 built from source on solaris 8 using gcc 3.2.2. Ean Kingston ([EMAIL PROTECTED]) Analyst Kanetix Ltd. (www.kanetix.com) Phone: (416) 599-9779 x216
RE: Diferential Backup
Hi Roberto, I don't believe so. Amanda uses either the vendor supplied dump program, or GNU tar to do the backup. I know GNU tar does not do differential backup and AFAIK none of the vendor supplied dump programs will do differential backup either (I'm pretty sure for Solaris, AIX, *BSD, and Linux derivatives). -Original Message- From: Roberto Samarone Araujo (RSA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 7:31 AM To: [EMAIL PROTECTED] Subject: Diferential Backup Hi, It it possible to use amanda to do diferential backups ? Are there any specific configuration ? Thanks, Roberto Samarone Araujo
RE: Need A sample Tapelist file
-Original Message- From: Gene Heskett [mailto:[EMAIL PROTECTED] On Tuesday 24 June 2003 17:27, Harry Mbang wrote: Hi, I am still trying to get my first successful Amanda backup. Now when I run amcheck, I get an error cannot read/write /usr/local/var/Amanda/gnutar-lists: No such file or directory Indeed there is no such file or directory. My gnutar-lists is located in /var/lib/Amanda. What shall I do? I am also guessing that Amanda is going to want read/write other files and folders in the non-extisting directory. Should I recompile Amanda with some option specifying the default directory for that type files and folders? Thanks in advance for any advice. Harry. It sounds as if you have a mix-n-match install there. If an rpm, it could be /var/lib/amanda. But the default for building a tarball is /usr/local/whatever. Move your tapelists and the rest of your config stuff to /usr/local/etc/amanda and see if that fixes things by running amcheck (as the user who normally runs amanda, it won't run as root), and fixing any other errors (warnings can be ignored) that pop up. Also do an 'rpm -e amanda*' to get rid of the rpms , they have no business surviving on the system if you have built amanda from a tarball. Or you could do what I did and add the config parameter into your amanda.conf file. tapelist /var/amanda/CONFIG-NAME/tapelist # list of used tapes
RE: Diferential Backup
-Original Message- On Wed, 25 Jun 2003 at 9:51am, Ean Kingston wrote I don't believe so. Amanda uses either the vendor supplied dump program, or GNU tar to do the backup. I know GNU tar does not do differential backup and AFAIK none of the vendor supplied dump programs will do differential backup either (I'm pretty sure for Solaris, AIX, *BSD, and Linux derivatives). The terminology here is a bit confusing. If by differential you mean only the bits (not whole files, but bits, like rsync) that have changed, then no, neither tar nor dump do that. But if Roberto meant incremental (as in the files that have changed), then of course amanda does that. Just trying to clarify for the archives. Good point. Since a 'differential backup' is 'just the bits that changed' (like rsync) for other backup software I've used, I assumed that Roberto meant that. Perhaps I should have been clearer.
RE: HP DLT1e tapetype
Hi all,
Sorry about posting the HW compression version first (especially to anyone who
searches the archives). I read more on st.conf (yes it's running under Solaris 8) and
played some with the various options. Here is what I got when I used the correct
device:
$amtapetype -e 40g -f /dev/rmt/0ln -t HP-DLT1e
Estimated time to write 2 * 40960 Mbyte: 30720 sec = 8 h 32 min
wrote 1232058 32Kb blocks in 94 files in 13969 seconds (short write)
wrote 1238517 32Kb blocks in 189 files in 14193 seconds (short write)
define tapetype HP-DLT1e {
comment just produced by tapetype prog (hardware compression off)
length 38602 mbytes
filemark 0 kbytes
speed 2807 kps
}
Now to actually try a backup.
RE: adding snapshot backups?
It sounds to me like what you want to do is make a new amanda configuration which you run once a week and have it take full backups only. You would then need enough tapes to do say 12 full backups. That way you would have data from about 3 months ago if you needed it. Then, each week, in addition to your daily backups, you will do one extra backup which is your full backup of everything. It might be easier to get another 20 tapes and add them to your existing rotation. That way you will have the 10 tapes you are using plus two full cycles of backup history. Then you just go through all 30 tapes before starting over. -Original Message- From: lloyd [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 2:11 PM To: Subject: Re: adding snapshot backups? Brian Cuttler wrote: You have a tape cycle of 10, what is your dump cycle ? Certain less than 10, hopefully less than 5. 5 given one untouched copy of the your level 0 backup while the older level 0 is being overwritten (assuming a single level 0 per dump cycle). the dump cycle, runs per cycle, and tape cycle are 10. What are you trying to do ? just ensure there is some kind of snapshot history going back, say three months, in case i need to reach into the distant past for a file. maybe a once-weekly snapshot... Are you looking for periodic level 0 that are outside of the normal tape pool or rotation ? i think this is what i'm after. perhaps combine this with your suggestion to lower the dump cycle to 5 ? can i just change this value in amanda.conf?
how does Amanda decide which tape to use?
Hi all, I've got my tape drive stuff sorted out (thanks for all your help) and now I'm looking at setting up my tape rotation schedule. I need to be sure I get it right since it will be handed off to operators that won't be doing any debugging if something goes wrong. So, here is my plan. I will have a dump cycle of 7 days, runs per cycle of 7 (1 per day), tapes per run of 1, I have 15 tapes, and I would like to have 2 full backups before reusing a tape. If I label the tapes as TAPE001 through TAPE015 and do so in that order, I believe the first tape Amanda will want to use is TAPE001 (or does it even matter?). Now, assuming that I had the tape changing off to the operators on Monday (June 30), can I give them a document like this to follow? DATETAPE-TO-REMOVE TAPE-TO-INSERT June 30 noneTAPE001 July 1 TAPE001 TAPE002 July 2 TAPE002 TAPE003 July 15 TAPE015 TAPE001 July 16 TAPE001 TAPE002 Any other hints? Ean Kingston (ean_kingston AT kanetix.com) Analyst Kanetix Ltd. (www.kanetix.com) Phone: (416) 599-9779 x216
HP DLT1e tapetype
I couldn't find this one in the list archvies, so here it is.
I'm using 40GB DLT tapes (according to the label). Despite what the comment produced
says, I used the non-compressed device. I didn't give it an estimate for the tapesize.
Writing 256 Mbyte compresseable data: 34 sec
Writing 256 Mbyte uncompresseable data: 105 sec
WARNING: Tape drive has hardware compression enabled
Estimated time to write 2 * 1024 Mbyte: 840 sec = 0 h 14 min
wrote 1102644 32Kb blocks in 3372 files in 21817 seconds (short write)
wrote 1101228 32Kb blocks in 6756 files in 29828 seconds (short write)
define tapetype HP-DLT1e {
comment just produced by tapetype prog (hardware compression on)
length 34499 mbytes
filemark 13 kbytes
speed 1399 kps
}
Ean Kingston ([EMAIL PROTECTED])
Analyst
Kanetix Ltd. (www.kanetix.com)
Phone: (416) 599-9779 x216
RE: HP DLT1e tapetype
-Original Message-
On Thursday 19 June 2003 11:51, Ean Kingston wrote:
I couldn't find this one in the list archives, so here it is.
I'm using 40GB DLT tapes (according to the label). Despite what the
comment produced says, I used the non-compressed device. I didn't
give it an estimate for the tapesize.
Writing 256 Mbyte compresseable data: 34 sec
Writing 256 Mbyte uncompresseable data: 105 sec
WARNING: Tape drive has hardware compression enabled
Estimated time to write 2 * 1024 Mbyte: 840 sec = 0 h 14 min
wrote 1102644 32Kb blocks in 3372 files in 21817 seconds (short
write) wrote 1101228 32Kb blocks in 6756 files in 29828 seconds
(short write) define tapetype HP-DLT1e {
comment just produced by tapetype prog (hardware compression
on) length 34499 mbytes
filemark 13 kbytes
speed 1399 kps
}
And it appears the hardware compressor being on cost you 5.5 gigs.
The various 'tapetype' programs all use the output of /dev/urandom as
the data source, and the output of /dev/urandom is not compressible,
and will in fact grow by about the percentage you see above in being
passed thru the hardware compressor.
As others have noted Ean, you can turn it off, but this must be done
for every new tape that's inserted as the recognition phase of the
drive will turn it back on when the tapes are changed. Such info as
how to turn it on/off should be on the drive makers web page. To
your vendor its obviously not a very high priority to obtain that
info for you else he would have fired up a browser and found it on
the spot.
I'm using Solaris and, according to the documentation, it should not be using hardware
compression unless I specify the 'compress' device (/dev/rmt/0cn) as opposed to the
one I did use (/dev/rmt/0n). If what you say it true there is some way to force HW
compression for the tape drive regardless of what the OS wants.
