Restoring /usr partition on Amanda server
Hi, Last Monday my /usr crashed. That meant I could boot in single user mode, but I had no amanda tool available, nor I had gzip or tar... I had built a statially linked version for amrestore, gzip and tar and put them in Amanda home directory (that is hopefully not on /usr). Be carefull: amrestore must be built to use the gzip in Amanda home dir! So I could use these tools to extract/restore the contents of /usr. More details in https://wwws.cs.ait.ac.th/amanda/recoveremail2.txt best regards, Olivier
Re: Change of tape drive unit
Guy Dallaire wrote: (BTW: for some reason I have to recreate those links at boot time in /etc/rc.local because they do not survive a reboot, I don't know why...) Might this be udev on Linux? I'm wondering what to do with my old DLT cartridges as I progressivly replace them with LTO ? I'm planning to do the following, please tell me if it's a good idea. [...] Why don't you `amadmin conf no-reuse' all of your old tapes, and label the new ones with a different name, DailySet1-025 ff. for example? That way, you keep the ability to restore from the old tapes, tape names do not change, and you never have two tapes carrying the same name. Unless you really want the tapes to be numbered starting from -001. Alex -- Alexander Jolk * BUF Compagnie * [EMAIL PROTECTED] Tel +33-1 42 68 18 28 * Fax +33-1 42 68 18 29
Re: permission problem with amrecover
Gene Heskett a écrit : On Thursday 27 April 2006 07:56, Thomas Ginestet wrote: [...] 501 Could not read config file /etc/amanda/DailySet/amanda.conf! I've checked amindexd logs: backup:/var/log/amanda# vi amindexd.20060426132954.debug amindexd: debug 1 pid 12531 ruid 34 euid 34: start at Wed Apr 26 13:23:57 2006 amindexd: version 2.5.0 amindexd: 220 backup AMANDA index server (2.5.0) ready. amindexd: SECURITY USER root bsd security: remote host backup.gpsa.fr user root local user backup amindexd: 200 Access OK amindexd: FEATURES feff9ffe07 amindexd: 200 FEATURES feff9ffe07 amindexd: DATE 2006-04-26 amindexd: 200 Working date set to 2006-04-26. amindexd: SCNF DailySet could not open conf file /etc/amanda/DailySet/amanda.conf: Permission denied amindexd: 501 Could not read config file /etc/amanda/DailySet/amanda.conf! My permissions for /etc/amanda/DailySet/amanda.conf: backup:/var/log/amanda# ls -al /etc/amanda/DailySet/amanda.conf -rwxrwx--- 1 root amanda 4451 2006-04-25 16:19 /etc/amanda/DailySet/amanda.conf I don't understand why it complain about that... You've apparently edited the amanda.conf as root (never do that, always become amanda to do that) and the perms are now fubar. It should look something like this: -rw-r--r-- 1 amanda disk 22049 Apr 16 08:59 /usr/local/etc/amanda/Daily/amanda.conf The user amanda should be a member of the group disk or backup. AFAIK, there is no group 'amanda', at least not here. Is this a new install? Any help would be appreciate Thomas Yes, I've tried to properly reconfigure Amanda but with Debian tools. I didn't find how to set --with-user=amanda --with-group=backup . options, that's why I've changed all permissions by hand. I'm so lost with permissionsfollowing your advices, this is what I've set: backup:~# ls -l /usr/sbin/am* = owner amanda group backup for all except for amcheck: -rwSr--r-- 1 root backup 35164 2006-04-03 14:07 /usr/sbin/amcheck -rwsr-x--- 1 root disk 88191 Apr 25 00:09 /usr/local/sbin/amcheck The s's are all lowercase here, no idea what diff that might indicate. backup:~# ls -al /usr/local/sbin/am* = owner amanda group backup for all except for amcheck: -rwSr--r-- 1 root backup 93903 2006-04-03 10:09 /usr/local/sbin/amcheck backup:~# ls -l /usr/local/libexec = owner amanda group backup for all except for: -rwSr--r-- 1 root backup 86228 2006-04-03 10:09 dumper -rwSr--r-- 1 root backup 40553 2006-04-03 10:08 killpgrp -rwSr--r-- 1 root backup 100783 2006-04-03 10:09 planner -rwSr--r-- 1 root backup 38055 2006-04-03 10:08 rundump -rwSr--r-- 1 root backup 38062 2006-04-03 10:08 runtar backup:~# ls -l /usr/lib/amanda = owner amanda group backup for all backup:~# ls -l /var/log/amanda = owner amanda group backup for all backup:~# ls -l /etc/amanda = owner amanda group backup for all backup:~# ls -l /etc/amandahosts = owner amanda group backup for all backup:~# ls -l /tmp/amanda = owner amanda group backup for all My dumpuser on amanda.conf is amanda but I can't launch amcheck anymore: backup:~# su amanda -c /usr/sbin/amcheck DailySet bash: /usr/sbin/amcheck: Permission non accordée (access not allowed for english guys ;-)) I must have forgotten something else but I don't know what... see my ls -l on amcheck above, or: -rwsr-x--- 1 root disk 88191 Apr 25 00:09 /usr/local/sbin/amcheck You are missing the 'x' bit in the perms in your copy. This is why we generally recommend building from the tarballs, doing the unpack, configure, and make stages in the user amanda's home directory. THEN you become root and do the make install, and all perms are then correctly set automaticly. So far, very few packagers making packages to match their fav systems have demonstrated a working understanding of the amanda theory of using just enough permissions to do the job. I've been building the new snapshots as they become available for several years now, and I've boiled it down to a short script that I use after becoming the user amanda, and unpacking the tarball in /home/amanda, and then cp'ing this script I keep a copy of sitting in /home/amanda: -- #!/bin/sh # since I'm always forgetting to su amanda... if [ `whoami` != 'amanda' ]; then echo echo Warning echo Amanda needs to be configured and built by the user amanda, echo but must be installed by user root. echo exit 1 fi make clean rm -f config.status config.cache ./configure --with-user=amanda \ --with-group=disk \ --with-owner=amanda \ --with-gnu-ld \ --prefix=/usr/local \ --with-tapedev=FILE:/amandatapes \ --with-debugging=/tmp/amanda-dbg/ \ --with-tape-server=coyote \ --with-amandahosts \ --with-configdir=/usr/local/etc/amanda \ --with-config=Daily \ --with-gnutar=/usr/local/bin/tar make - which is named gh.cf into the freshly unpacked directory, then cd'ing to that directory, and (set the
Release of Amanda 2.5.0p1
Hello, The Amanda core team is pleased to announce the release of Amanda 2.5.0p1. It can be dowloaded from http://www.amanda.org/ Here's a list of the changes for release 2.5.0p1 (from the NEWS file): Look at the ChangeLog file for more details. Changes in release 2.5.0p1 * Add the 'amtape update' command. * Many small bug fix. If you find bug in this release, please submit a bug report on sourceforge in the group v2.5.0p1.
Re: Change of tape drive unit
2006/4/28, Alexander Jolk [EMAIL PROTECTED]: Guy Dallaire wrote: (BTW: for some reason I have to recreate those links at boot time in /etc/rc.local because they do not survive a reboot, I don't know why...)Might this be udev on Linux? Maybe Why don't you `amadmin conf no-reuse' all of your old tapes, and label the new ones with a different name, DailySet1-025 ff. for example?Thatway, you keep the ability to restore from the old tapes, tape names donot change, and you never have two tapes carrying the same name.Unless you really want the tapes to be numbered starting from -001.After tapecycle tapes have passed in the rotation, wouldn't the contents of the tapes have been are overwritten anyway ? Considering this, I taught I might as well relabel them when their time comes around.
amanda gtar question
To try and make my backups smaller I run a perl script that runs goes
through my users directory and produces the following lines for each user.
The script then includes these lines in the disklist file. This has been
working great and my backups go rather fast.
The amrecover also works ok, if I needed to restore a file or a directory
for a user.
host /export/fssnap/users/zhangj export-users-tar -1 local
host /export/fssnap/users/zhangs export-users-tar -1 local
host /export/fssnap/users/zink export-users-tar -1 local
host /export/fssnap/users/zjelonek export-users-tar -1 local
host /export/fssnap/users/zli export-users-tar -1 local
host /export/fssnap/users/zmullero export-users-tar -1 local
define dumptype export-users-tar {
global
comment Full Backup of users using tar
program GNUTAR
maxdumps 10
}
But I ran into a major problem when I had to rebuild the entire users disk
because of a major crash.
The problem is that the user files in the backup tar file are relative to
/export/fssnap/users/username, which means I need to know and create the
directory name and permissions where the files will be placed on the disk
before I can restore.
I only wanted to make one pass through my backup tapes so I had to create a
script to manually read the first record of the backup tar file to get the
user/directory name, create the directory, cd to the directory and then
manually dd'ed and untared the file to the directory.
What I really need is for the backup tar file to be relative to
/export/fssnap/users.
QUESTION
Is there a way to force the relative path in the amanda tar command?
Thanks
_
Robert P. McGraw, Jr.
Manager, Computer System EMAIL: [EMAIL PROTECTED]
Purdue University ROOM: MATH-807
Department of MathematicsPHONE: (765) 494-6055
150 N. University Street FAX: (419) 821-0540
West Lafayette, IN 47907-2067
smime.p7s
Description: S/MIME cryptographic signature
Re: amanda gtar question
On 2006-04-28 14:49, McGraw, Robert P. wrote:
To try and make my backups smaller I run a perl script that runs goes
through my users directory and produces the following lines for each user.
The script then includes these lines in the disklist file. This has been
working great and my backups go rather fast.
The amrecover also works ok, if I needed to restore a file or a directory
for a user.
host /export/fssnap/users/zhangj export-users-tar -1 local
host /export/fssnap/users/zhangs export-users-tar -1 local
host /export/fssnap/users/zink export-users-tar -1 local
host /export/fssnap/users/zjelonek export-users-tar -1 local
host /export/fssnap/users/zli export-users-tar -1 local
host /export/fssnap/users/zmullero export-users-tar -1 local
define dumptype export-users-tar {
global
comment Full Backup of users using tar
program GNUTAR
maxdumps 10
}
But I ran into a major problem when I had to rebuild the entire users disk
because of a major crash.
The problem is that the user files in the backup tar file are relative to
/export/fssnap/users/username, which means I need to know and create the
directory name and permissions where the files will be placed on the disk
before I can restore.
I only wanted to make one pass through my backup tapes so I had to create a
script to manually read the first record of the backup tar file to get the
user/directory name, create the directory, cd to the directory and then
manually dd'ed and untared the file to the directory.
What I really need is for the backup tar file to be relative to
/export/fssnap/users.
QUESTION
Is there a way to force the relative path in the amanda tar command?
Use disklist entries in this form:
host unique_name /top/level/dir {
base-dumptype
include ./subdir
}
host /export/fssnap/users:zli /export/fssnap/users {
export-users-tar
include ./zli
}
host /export/fssnap/users:zmullero /export/fssnap/users {
export-users-tar
include ./zmullero
}
The second arg must be unique in a disklist. It can be whatever you
like. I used the concatenation of topdir and subdir with
colon as separator between the dir and subdir, but you could also
use a slash (no space).
Remark: when using vtapes, you are limited to those chars in that
unique name that the filesystem where the vtapes are located can handle.
E.g. many USB-drives use vfat, which *cannot* handle a colon in the
name. You get a very obscure error message from taper in that case.
--
Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... Are you sure? ... YES ... Phew ... I'm out *
***
Re: Change of tape drive unit
Guy Dallaire wrote: 2006/4/28, Alexander Jolk [EMAIL PROTECTED]: Guy Dallaire wrote: (BTW: for some reason I have to recreate those links at boot time in /etc/rc.local because they do not survive a reboot, I don't know why...) Might this be udev on Linux? Maybe Then you'd have to look into configuring udev in order for your symlink to be created automatically... After tapecycle tapes have passed in the rotation, wouldn't the contents of the tapes have been are overwritten anyway ? Considering this, I taught I might as well relabel them when their time comes around. Yes, after `tapecycle' tapes and `dumpcycle' days have passed. It just seems simpler to me to give different names to the new tapes, and either `no-reuse' the old tapes, or else amrmtape them when you don't need them anymore. (You can obviously label more than `tapecycle' tapes; amanda will happily use them and ask for them in order. Alex -- Alexander Jolk * BUF Compagnie * [EMAIL PROTECTED] Tel +33-1 42 68 18 28 * Fax +33-1 42 68 18 29
Re: Change of tape drive unit
On Fri, Apr 28, 2006 at 08:47:13AM -0400, Guy Dallaire wrote: 2006/4/28, Alexander Jolk [EMAIL PROTECTED]: Why don't you `amadmin conf no-reuse' all of your old tapes, and label the new ones with a different name, DailySet1-025 ff. for example? That way, you keep the ability to restore from the old tapes, tape names do not change, and you never have two tapes carrying the same name. Unless you really want the tapes to be numbered starting from -001. After tapecycle tapes have passed in the rotation, wouldn't the contents of the tapes have been are overwritten anyway ? Considering this, I taught I might as well relabel them when their time comes around. Certainly, what some of us have suggested is that you might consider the data on the dlt tapes as archival. Maybe 6 months from now you just might want something from April that is no longer on your 25 lto tapes. Unless you have other needs for the dlt tapes, why wipe out the indexes and all trace that those backup data ever existed when actually they still do? How you use the dlt tapes and your needs are certainly specific to your environment. These are just suggestions you may not have considered. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: permission problem with amrecover
On Friday 28 April 2006 05:31, Thomas Ginestet wrote: Gene Heskett a écrit : Thanks a lot Gene (and you too Matt ;-) ), your script is such a good idea. Using the x bit was better ;-). But I have others problems like the generated tapelist with owner amanda and group amanda (and restricted permissions to owner) which complains when running amrecover. The easiest way for me is to remove all file installed with my debian packager and reinstall by hand with corrects arguments in my ./configure My Debian mind tell me to download source package, modify arguments and then re-package Amanda but...I'm so lazy on Friday. Thomas Chuckle, been there, done that, bought the t-shirt wore it out even. But at least you now know what to do. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: Change of tape drive unit
2006/4/28, Jon LaBadie [EMAIL PROTECTED]: On Fri, Apr 28, 2006 at 08:47:13AM -0400, Guy Dallaire wrote: 2006/4/28, Alexander Jolk [EMAIL PROTECTED]: Why don't you `amadmin conf no-reuse' all of your old tapes, and label the new ones with a different name, DailySet1-025 ff. for example?That way, you keep the ability to restore from the old tapes, tape names do not change, and you never have two tapes carrying the same name.Unless you really want the tapes to be numbered starting from -001. After tapecycle tapes have passed in the rotation, wouldn't the contents of the tapes have been are overwritten anyway ? Considering this, I taught I might as well relabel them when their time comes around.How you use the dlt tapes and your needs are certainly specific to yourenvironment.These are just suggestions you may not have considered. Yes, OK thanks for all the suggestions Actually, I'll keep the DLT tape drive and device names in Linux (and change the config(s) if needed) because I have another amanda archival config that runs once a month and forces level 0 of all DLE's. I keep those monthly backups forever, in addition of my regular rotation of 4 weeks.
Re: 2.5.0 config file errors on FC5
On Wednesday 26 April 2006 09:40, Silver Salonen wrote: Hi. As I'm in kind of hurry (I'm writing a bachelor's thesis about backups and a small part of it is about Amanda and the deadline is at the beginning of the next week), I installed Amanda 2.5.0 RPM for FC4 on FC5. I've looked Amanda's official documentation's page about a dozen times, but it looks somewhat obfuscating, so now I tried to start with Amanda according to Zmanda's quick start guide (http://wiki.zmanda.com/index.php/Quick_start). BTW, could anybody suggest a nice documentation where it would be possible to get a nice and quick overview about Amanda's structure (the main process, dealing with backup-media, etc. - some chema maybe)? The main documentation is really scary - it has specific information and how-to's about different parts, but the overall picture.. :( I've configured everything exactly as written on the quick start page, but when I try to label a virtual tape (being actually a folder on hard drive), I get several errors about my amanda.conf. I execute: # su - amandabackup $ cd /backup/amanda-vtapes/ $ ammt -t file:/backup/amanda-vtapes/tape rewind $ amlabel daily Test-01 And get: /etc/amanda/daily/amanda.conf, line 164: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 164: end of line expected /etc/amanda/daily/amanda.conf, line 166: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 166: end of line expected /etc/amanda/daily/amanda.conf, line 168: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 168: end of line expected /etc/amanda/daily/amanda.conf, line 170: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 170: end of line expected /etc/amanda/daily/amanda.conf, line 213: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 213: end of line expected /etc/amanda/daily/amanda.conf, line 214: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 214: end of line expected /etc/amanda/daily/amanda.conf, line 217: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 217: end of line expected /etc/amanda/daily/amanda.conf, line 218: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 219: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 219: end of line expected /etc/amanda/daily/amanda.conf, line 220: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 221: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 221: end of line expected /etc/amanda/daily/amanda.conf, line 222: holding disk parameter expected amlabel: errors processing config file /etc/amanda/daily/amanda.conf I think there's no point to copy-paste all the problematic lines, but I'd do it about some of the first. Lines from 164 to 168 are: infofile /var/lib/amanda/daily/curinfo# database DIRECTORY logdir /var/lib/amanda/daily# log directory indexdir /var/lib/amanda/daily/index # index directory tapelist /var/lib/amanda/daily/tapelist # list of used tapes # tapelist is stored, by default, in the directory that contains amanda.conf I've googled about this error, but everything I've found is some of Amanda's source-code. Is the FC4 version really so incompatible with FC5 or what could be the problem? Thanks in advance, Silver Did you at any point, try to edit that with an M$ application? That smells like a linefeed problem where carriage returns got into it somehow. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: 2.5.0 config file errors on FC5
On Friday 28 April 2006 16:53, Gene Heskett wrote: On Wednesday 26 April 2006 09:40, Silver Salonen wrote: Hi. As I'm in kind of hurry (I'm writing a bachelor's thesis about backups and a small part of it is about Amanda and the deadline is at the beginning of the next week), I installed Amanda 2.5.0 RPM for FC4 on FC5. I've looked Amanda's official documentation's page about a dozen times, but it looks somewhat obfuscating, so now I tried to start with Amanda according to Zmanda's quick start guide (http://wiki.zmanda.com/index.php/Quick_start). BTW, could anybody suggest a nice documentation where it would be possible to get a nice and quick overview about Amanda's structure (the main process, dealing with backup-media, etc. - some chema maybe)? The main documentation is really scary - it has specific information and how-to's about different parts, but the overall picture.. :( I've configured everything exactly as written on the quick start page, but when I try to label a virtual tape (being actually a folder on hard drive), I get several errors about my amanda.conf. I execute: # su - amandabackup $ cd /backup/amanda-vtapes/ $ ammt -t file:/backup/amanda-vtapes/tape rewind $ amlabel daily Test-01 And get: /etc/amanda/daily/amanda.conf, line 164: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 164: end of line expected /etc/amanda/daily/amanda.conf, line 166: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 166: end of line expected /etc/amanda/daily/amanda.conf, line 168: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 168: end of line expected /etc/amanda/daily/amanda.conf, line 170: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 170: end of line expected /etc/amanda/daily/amanda.conf, line 213: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 213: end of line expected /etc/amanda/daily/amanda.conf, line 214: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 214: end of line expected /etc/amanda/daily/amanda.conf, line 217: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 217: end of line expected /etc/amanda/daily/amanda.conf, line 218: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 219: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 219: end of line expected /etc/amanda/daily/amanda.conf, line 220: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 221: holding disk parameter expected /etc/amanda/daily/amanda.conf, line 221: end of line expected /etc/amanda/daily/amanda.conf, line 222: holding disk parameter expected amlabel: errors processing config file /etc/amanda/daily/amanda.conf I think there's no point to copy-paste all the problematic lines, but I'd do it about some of the first. Lines from 164 to 168 are: infofile /var/lib/amanda/daily/curinfo# database DIRECTORY logdir /var/lib/amanda/daily# log directory indexdir /var/lib/amanda/daily/index # index directory tapelist /var/lib/amanda/daily/tapelist # list of used tapes # tapelist is stored, by default, in the directory that contains amanda.conf I've googled about this error, but everything I've found is some of Amanda's source-code. Is the FC4 version really so incompatible with FC5 or what could be the problem? Thanks in advance, Silver Did you at any point, try to edit that with an M$ application? That smells like a linefeed problem where carriage returns got into it somehow. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. No-no, I already got a solution for that.. there was an uncomplete bracket ;) Silver
Re: amanda gtar question
On Fri, Apr 28, 2006 at 03:25:34PM +0200, Paul Bijnens wrote:
On 2006-04-28 14:49, McGraw, Robert P. wrote:
To try and make my backups smaller I run a perl script that runs goes
through my users directory and produces the following lines for each
user.
...
host /export/fssnap/users/zhangj export-users-tar -1 local
host /export/fssnap/users/zhangs export-users-tar -1 local
host /export/fssnap/users/zink export-users-tar -1 local
host /export/fssnap/users/zjelonek export-users-tar -1 local
host /export/fssnap/users/zli export-users-tar -1 local
host /export/fssnap/users/zmullero export-users-tar -1 local
define dumptype export-users-tar {
global
comment Full Backup of users using tar
program GNUTAR
maxdumps 10
}
But I ran into a major problem when I had to rebuild the entire users
disk because of a major crash.
...
What I really need is for the backup tar file to be relative to
/export/fssnap/users.
QUESTION
Is there a way to force the relative path in the amanda tar command?
Use disklist entries in this form:
host unique_name /top/level/dir {
base-dumptype
include ./subdir
}
host /export/fssnap/users:zli /export/fssnap/users {
export-users-tar
include ./zli
}
host /export/fssnap/users:zmullero /export/fssnap/users {
export-users-tar
include ./zmullero
}
The second arg must be unique in a disklist. It can be whatever you
like. I used the concatenation of topdir and subdir with
colon as separator between the dir and subdir, but you could also
use a slash (no space).
I was going to suggest the same solution.
Minor correction (I so seldom can find any flaws in Paul's posts :).
It is the pair, hostname/diskname that must be unique. When used
with a diskname and a starting directory I consider the diskname
to be a tag. Thus I don't make it resemble a pathname. So I
might chose tags like Users:zli or SnapUsers-zmullero. Or
even just the username which would be unique on any particular host.
Remark: when using vtapes, you are limited to those chars in that
unique name that the filesystem where the vtapes are located can handle.
E.g. many USB-drives use vfat, which *cannot* handle a colon in the
name. You get a very obscure error message from taper in that case.
Didn't think about that when I added my USB drives. Another reason
I'm happy I reformatted to ext2. BTW I got a few extra GB on those
drives by creating the ext2 filesystem with no reserve for root (5%
by default) and by reducing the number of inodes by a factor of 8.
I don't expect my vtapes will consume the million inodes that left ;)
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
FreeBSD client
Some of you might remember I'm piecing together a previous, non-working, installation of amanda. The help I've received off here has been great, so thanks again! The next piece in this puzzle is a FreeBSD (5.4) machine that appears to have amanda already installed. I can't find any documentation on getting the client working on BSD so started going by all the information I've gleened troubleshooting the Linux machines here. I can't find a .amandahosts file, do I need to create this and if so where? Or should this information go somewhere else? I assume /tmp/amanda should exist on the machine and be writable and ownder by operator:operator (operator being the default username the client seems to install by, and operator being BSD's equiv of 'disk' group), is this so? Thanks, john
Scalability information sought
At the recent 'Trenton Computer Festival' I was discussing amanda with a gentleman who asked something like how big can amanda go? I described hearing about sites with multiple terrabytes of data, but he was unimpressed. He was more interested in number of items. I guess he meant clients or disklist entries in amanda terminology. He heard I was giving a talk on amanda at a local users group in a couple of weeks he indicated that he would be attending. I'd like to have more definitive (hopefully impressive :) information for him at that time. I looked back at the survey results from a few years ago. At that time the respondents reported maximums of: 5 TB total disk capacity 4 TB actual data stored 700 GB average size of amdump run 70 clients ? disklist entries (not asked in the survey) If any of you have installations with substantially higher values than these, I'd love to hear of it. You can email me directly rather than littering the list. I can always post a summary of what I hear. Thanks, jon -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Scalability information sought
Jon LaBadie wrote: I looked back at the survey results from a few years ago. At that time the respondents reported maximums of: 5 TB total disk capacity 4 TB actual data stored 700 GB average size of amdump run 70 clients ? disklist entries (not asked in the survey) If any of you have installations with substantially higher values than these, I'd love to hear of it. I expect that to be slightly outdated now :) In fact I *know* that there are some reasonably bigger installations of Amanda out there, although I don't run them myself. Greetings, looking forward to the results of that survey, Stefan.
Taper problems with 2.5.0
Hello! Anyone knows what following error means? *** THE DUMPS DID NOT FINISH PROPERLY! The next 3 tapes Amanda expects to use are: PPC02, PPC03, PPC04. FAILURE AND STRANGE DUMP SUMMARY: host.do.main /etc RESULTS MISSING host.do.main /mRESULTS MISSING [ ... ] taper: FATAL cannot allocate shared memory driver: FATAL reading result from taper: Connection reset by peer [ ... ] NOTES: taper: attach_buffers: (20 tapebufs: 659696 bytes) No space left on device taper: attach_buffers: (19 tapebufs: 626916 bytes) No space left on device [ ... ] All file systems (especially holding disk) have plenty free space and inodes. Both, holding disk and tape were empty. I'd expect an empty tape when taper fails. But empty holding disk is not exactly what I'd expect in such a situation.
Re: FreeBSD client
John Clement wrote: Some of you might remember I'm piecing together a previous, non-working, installation of amanda. The help I've received off here has been great, so thanks again! The next piece in this puzzle is a FreeBSD (5.4) machine that appears to have amanda already installed. I can't find any documentation on getting the client working on BSD so started going by all the information I've gleened troubleshooting the Linux machines here. I can't find a .amandahosts file, do I need to create this and if so where? Or should this information go somewhere else? I assume /tmp/amanda should exist on the machine and be writable and ownder by operator:operator (operator being the default username the client seems to install by, and operator being BSD's equiv of 'disk' group), is this so? do amadmin test version the output of the above command tells how it's configured and where the log will be kept and etc. -- Thank you! Kevin Till Amanda documentation: http://wiki.zmanda.com Amanda forums:http://forums.zmanda.com
Re: FreeBSD client
John Clement wrote: Some of you might remember I'm piecing together a previous, non-working, installation of amanda. The help I've received off here has been great, so thanks again! The next piece in this puzzle is a FreeBSD (5.4) machine that appears to have amanda already installed. John, let us know the/some background of your mission. Seems you're the one to keep the wheels reelin' ... after someone else has left the building. Your puzzle is ours, as it seem ;-) Regards, Stefan.
