tar escaping into a different file system
Finally I'm getting back on track after the tar 1.15.91-2 incremental changes.
Due to this issue and my yearly holidays, my backups are long overdue and
Amanda likes to do lots of level 0s (as expected).
I just noticed this in the mail log of last night's backup:
| /-- anakin / lev 0 FAILED [data write: Connection reset by peer]
| sendbackup: start [anakin:/ level 0]
| sendbackup: info BACKUP=/bin/tar
| sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
| sendbackup: info COMPRESS_SUFFIX=.gz
| sendbackup: info end
| ? gtar: ./proc/19106/fd/5: Warning: Cannot stat: No such file or directory
| ? gtar: ./proc/19106/task/19106/fd/5: Warning: Cannot stat: No such file or
| directory
| ? gtar: ./proc/6490/task/19182: Warning: Cannot stat: No such file or
| directory
| ? gtar: ./proc/6490/task/19182/attr: Warning: Cannot stat: No such file or
| directory
| ? gtar: ./proc/6490/task/19182/attr: Warning: Cannot stat: No such file or
| directory
| ? gtar: ./proc/6490/task/19182/fd: Warning: Cannot stat: No such file or
| directory
| ? gtar: ./proc/6490/task/19182/fd: Warning: Cannot stat: No such file or
| directory
| ? gtar: ./proc/asound/card0/pcm0p/sub1: file changed as we read it
| ? gtar: ./proc/irq/14/ide0: file changed as we read it
| ? gtar: ./proc/sys/fs/mqueue: file changed as we read it
| ? gtar: ./proc/sys/net/ipv6/conf/default: file changed as we read it
| | gtar: ./dev/gpmctl: socket ignored
| | gtar: ./dev/log: socket ignored
| \
Since /proc is on a separate file system, tar is not supposed to enter that
directory.
Anyone seen that before? I'm using tar 1.15.91-2 and amanda 1:2.5.0p2-1 (+ my
backport of the fixes for tar 1.15.91, cfr.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378558), on Debian
testing/unstable.
Is this another tar 1.15.91 breakage?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
restore information needed
Hi all, Can any one please help me out in this regard. I have taken backup using amanda on a virtual tape library. How to restore the contents back. If i check the file type it is showing as character Computer Graphics Metafile. Thanks in advance kamalesh
Re: restore information needed
Please visit http://wiki.zmanda.com/index.php/Restoring_files Thanks,Sachin.On 7/31/06, kamalesh krishna murthy <[EMAIL PROTECTED]> wrote: Hi all, Can any one please help me out in this regard. I have taken backup using amanda on a virtual tape library. How to restore the contents back. If i check the file type it is showing as character Computer Graphics Metafile. Thanks in advance kamalesh
Correct use of amflush
Hi, I'd appreciate some advice on what is regarded as the correct usage of amflush and the tapes to use with amflush. If the need to run amflush occurs, then amanda tells you which tape to use next, or that you can use a new tape. My question is simply this: Is it acceptable to use the next (already labelled) tape for the amflush operation, or is there any reason why amflush should rather/only be done with a new tape? E.g. I use daily-1 for a backup run, and the backup fails for some reason and some data is on the holding disk. Amanda tells me that she expects daily-2 or a new tape for the next run. I run amflush, and amanda wants a tape. Is it alright to use daily-2, or is it better to use a new tape? Thanks very much. -- View this message in context: http://www.nabble.com/Correct-use-of-amflush-tf2026836.html#a5573711 Sent from the Amanda - Users forum at Nabble.com.
Re: Correct use of amflush
On Mon, 31 Jul 2006, Joe Donner (sent by Nabble.com) wrote: E.g. I use daily-1 for a backup run, and the backup fails for some reason and some data is on the holding disk. Amanda tells me that she expects daily-2 or a new tape for the next run. I run amflush, and amanda wants a tape. Is it alright to use daily-2, or is it better to use a new tape? Either is fine. If you're going to use an existing tape, daily-2 is what amanda will want. At any time it's always acceptable to use a new tape. If you use a new tape amanda will add it to the normal rotation at this point. What you choose to do is up to local policy. -Mitch
Re: Correct use of amflush
Aha - thanks for that! That was kind of what I was wondering about - didn't realise that amanda will add it to the rotation, so I thought what happens to the tape then... I wonder - how will amanda handle labelling the new tape, then? Will you be asked to label it first, manually, or does amanda label it automatically? Thanks! Mitch Collinsworth wrote: > > > On Mon, 31 Jul 2006, Joe Donner (sent by Nabble.com) wrote: > >> E.g. I use daily-1 for a backup run, and the backup fails for some reason >> and some data is on the holding disk. Amanda tells me that she expects >> daily-2 or a new tape for the next run. I run amflush, and amanda wants >> a >> tape. Is it alright to use daily-2, or is it better to use a new tape? > > Either is fine. If you're going to use an existing tape, daily-2 is what > amanda will want. At any time it's always acceptable to use a new tape. > If you use a new tape amanda will add it to the normal rotation at this > point. What you choose to do is up to local policy. > > -Mitch > > -- View this message in context: http://www.nabble.com/Correct-use-of-amflush-tf2026836.html#a5574181 Sent from the Amanda - Users forum at Nabble.com.
Still struggling with L0
Guys I'm have _real_ trouble trying to force Amanda to do a L0 backup of the system that was effected by Amanda wiping out the last L0. I've tried to force a L0 backup of it, like : amadmin DailySet1 force qtvpdc.lab:/Shares amadmin: qtvpdc.lab:/Shares is set to a forced level 0 at next run. But when amdump runs, it just schedules a L1 or L2 backup. As you can imagine I'm not best pleased as I _still_ haven't been able to get an L0 of this system on tape 5 days later (after severely reducing the filesystem size) Any ideas ??? Cheers -- AlanP
Re: Still struggling with L0
The little bit of experience I have of amanda has showed me that "dumpcycle 0" in amanda.conf will force a level 0 (full) dump. I've been running amanda in a test lab with that setting before going production with incremental backups. Probably not the correct way of doing it in your case, but maybe it works if all else fails? Alan Pearson wrote: > > Guys > > I'm have _real_ trouble trying to force Amanda to do a L0 backup of the > system that was effected by Amanda wiping out the last L0. > > I've tried to force a L0 backup of it, like : > > amadmin DailySet1 force qtvpdc.lab:/Shares > amadmin: qtvpdc.lab:/Shares is set to a forced level 0 at next run. > > > But when amdump runs, it just schedules a L1 or L2 backup. > > As you can imagine I'm not best pleased as I _still_ haven't been able to > get an L0 of this system on tape 5 days later (after severely reducing the > filesystem size) > > Any ideas ??? > > Cheers > -- > AlanP > > > > -- View this message in context: http://www.nabble.com/Still-struggling-with-L0-tf2027407.html#a5575507 Sent from the Amanda - Users forum at Nabble.com.
Re: Correct use of amflush
On Mon, Jul 31, 2006 at 04:37:58AM -0700, Joe Donner (sent by Nabble.com) wrote: > > Aha - thanks for that! > > That was kind of what I was wondering about - didn't realise that amanda > will add it to the rotation, so I thought what happens to the tape then... > > I wonder - how will amanda handle labelling the new tape, then? Will you be > asked to label it first, manually, or does amanda label it automatically? > > Thanks! > > > Mitch Collinsworth wrote: > > > > > > On Mon, 31 Jul 2006, Joe Donner (sent by Nabble.com) wrote: > > > >> E.g. I use daily-1 for a backup run, and the backup fails for some reason > >> and some data is on the holding disk. Amanda tells me that she expects > >> daily-2 or a new tape for the next run. I run amflush, and amanda wants > >> a > >> tape. Is it alright to use daily-2, or is it better to use a new tape? > > > > Either is fine. If you're going to use an existing tape, daily-2 is what > > amanda will want. At any time it's always acceptable to use a new tape. > > If you use a new tape amanda will add it to the normal rotation at this > > point. What you choose to do is up to local policy. > > Traditionally amanda would never automatically label tapes. It is a one-time administrator task. ISTR that recent amanda versions have a directive to automatically label unlabelled tapes. It was intended for some vtape installations and some specialty situations. It is NOT on by default. I'd recommend against using autolabeling unless very clear of the implications. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Correct use of amflush
bis 15.8. bin ich nicht erreichbar. in dringenden fällen senden sie ihre nachricht bitte an mailto:[EMAIL PROTECTED], vielen dank.
Re: tar escaping into a different file system
On Mon, Jul 31, 2006 at 09:52:10AM +0200, Geert Uytterhoeven wrote: > > Finally I'm getting back on track after the tar 1.15.91-2 incremental changes. > Due to this issue and my yearly holidays, my backups are long overdue and > Amanda likes to do lots of level 0s (as expected). > > I just noticed this in the mail log of last night's backup: > > | /-- anakin / lev 0 FAILED [data write: Connection reset by peer] > | sendbackup: start [anakin:/ level 0] > | sendbackup: info BACKUP=/bin/tar > | sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - > | sendbackup: info COMPRESS_SUFFIX=.gz > | sendbackup: info end > | ? gtar: ./proc/19106/fd/5: Warning: Cannot stat: No such file or directory > | ? gtar: ./proc/19106/task/19106/fd/5: Warning: Cannot stat: No such file or > | directory > | ? gtar: ./proc/6490/task/19182: Warning: Cannot stat: No such file or > | directory > | ? gtar: ./proc/6490/task/19182/attr: Warning: Cannot stat: No such file or > | directory > | ? gtar: ./proc/6490/task/19182/attr: Warning: Cannot stat: No such file or > | directory > | ? gtar: ./proc/6490/task/19182/fd: Warning: Cannot stat: No such file or > | directory > | ? gtar: ./proc/6490/task/19182/fd: Warning: Cannot stat: No such file or > | directory > | ? gtar: ./proc/asound/card0/pcm0p/sub1: file changed as we read it > | ? gtar: ./proc/irq/14/ide0: file changed as we read it > | ? gtar: ./proc/sys/fs/mqueue: file changed as we read it > | ? gtar: ./proc/sys/net/ipv6/conf/default: file changed as we read it > | | gtar: ./dev/gpmctl: socket ignored > | | gtar: ./dev/log: socket ignored > | \ > > Since /proc is on a separate file system, tar is not supposed to enter that > directory. > > Anyone seen that before? I'm using tar 1.15.91-2 and amanda 1:2.5.0p2-1 (+ my > backport of the fixes for tar 1.15.91, cfr. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378558), on Debian > testing/unstable. > > Is this another tar 1.15.91 breakage? > Things to check might include: Do the amanda debug files on the client show the tar argument list with the "-l" or "--one-file-system" argument. Do you have any "include" directives. Tar will happily go to other file systems if you specifically tell it to. I once ran a DLE that covered 3 or 4 tiny file systems in one DLE by using / as the starting directory and including /a, /b, /c, ... (the mount points). If you run tar with the create and verbose (cv) options and the output is to /dev/null (f /dev/null), then tar will output the filenames of what it would backup, but doesn't. It only visits the inodes, not the datablocks. So you could try 1.15.91 manually and see if the output filenames include the /proc files. Lots of output, so probably collect to a file and search with less or more. Also, don't forget the --one-file-system option. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
amcheck error
Amanda version: 2.5.0 Linux: Fedora Core 4 Windows Amanda client: Downloaded from http://prdownloads.sourceforge.net/amanda-win32/amanda-clients-2.5.0-2001062 8.zip?use_mirror=nchc and installed it on the Windows platform. The amandad service is successfully starting by running the rc.amandad batch script on the Windows side. On the Amanda server (running Linux OS), we did the appropriate configuration of the amanda build by running the following configuration line: ./configure --with-user=amanda --with-group=backup And successfully did the make and 'make install' as well (after creating the user 'amanda' and group 'backup') We went and created the appropriate entries in the amandahosts file in the following format and placed it in the home directory of Amanda user: The amcheck utility is throwing out an error stating that "access as amanda not allowed from [EMAIL PROTECTED]". Is there an issue running the client on Windows and the server on the Linux server? The basic communication between the amandad client and the amcheck run on the server seems to be fine since the name of the server gets succesfully printed on the amandad client window when a request for a connection goes successfully to the client. Is there a requirement that we need to run Cygwin mandatorily on the Windows client for getting this up and running?
Re: tar escaping into a different file system
On Mon, 31 Jul 2006, Jon LaBadie wrote:
> On Mon, Jul 31, 2006 at 09:52:10AM +0200, Geert Uytterhoeven wrote:
> >
> > Finally I'm getting back on track after the tar 1.15.91-2 incremental
> > changes.
> > Due to this issue and my yearly holidays, my backups are long overdue and
> > Amanda likes to do lots of level 0s (as expected).
> >
> > I just noticed this in the mail log of last night's backup:
> >
> > | /-- anakin / lev 0 FAILED [data write: Connection reset by peer]
> > | sendbackup: start [anakin:/ level 0]
> > | sendbackup: info BACKUP=/bin/tar
> > | sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
> > | sendbackup: info COMPRESS_SUFFIX=.gz
> > | sendbackup: info end
> > | ? gtar: ./proc/19106/fd/5: Warning: Cannot stat: No such file or directory
> > | ? gtar: ./proc/19106/task/19106/fd/5: Warning: Cannot stat: No such file
> > or
> > | directory
> > | ? gtar: ./proc/6490/task/19182: Warning: Cannot stat: No such file or
> > | directory
> > | ? gtar: ./proc/6490/task/19182/attr: Warning: Cannot stat: No such file or
> > | directory
> > | ? gtar: ./proc/6490/task/19182/attr: Warning: Cannot stat: No such file or
> > | directory
> > | ? gtar: ./proc/6490/task/19182/fd: Warning: Cannot stat: No such file or
> > | directory
> > | ? gtar: ./proc/6490/task/19182/fd: Warning: Cannot stat: No such file or
> > | directory
> > | ? gtar: ./proc/asound/card0/pcm0p/sub1: file changed as we read it
> > | ? gtar: ./proc/irq/14/ide0: file changed as we read it
> > | ? gtar: ./proc/sys/fs/mqueue: file changed as we read it
> > | ? gtar: ./proc/sys/net/ipv6/conf/default: file changed as we read it
> > | | gtar: ./dev/gpmctl: socket ignored
> > | | gtar: ./dev/log: socket ignored
> > | \
> >
> > Since /proc is on a separate file system, tar is not supposed to enter that
> > directory.
> >
> > Anyone seen that before? I'm using tar 1.15.91-2 and amanda 1:2.5.0p2-1 (+
> > my
> > backport of the fixes for tar 1.15.91, cfr.
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378558), on Debian
> > testing/unstable.
> >
> > Is this another tar 1.15.91 breakage?
> >
>
> Things to check might include:
>
> Do the amanda debug files on the client show the tar argument list
> with the "-l" or "--one-file-system" argument.
>
> Do you have any "include" directives. Tar will happily go to other
> file systems if you specifically tell it to. I once ran a DLE that
> covered 3 or 4 tiny file systems in one DLE by using / as the
> starting directory and including /a, /b, /c, ... (the mount points).
>
> If you run tar with the create and verbose (cv) options and the
> output is to /dev/null (f /dev/null), then tar will output the
> filenames of what it would backup, but doesn't. It only visits
> the inodes, not the datablocks. So you could try 1.15.91 manually
> and see if the output filenames include the /proc files. Lots
> of output, so probably collect to a file and search with less or more.
> Also, don't forget the --one-file-system option.
According to the logs, it used
| running: /bin/tar: gtar --create --file - --directory / --one-file-system
--listed-incremental /var/lib/amanda/gnutar-lists/anakin__0.new --sparse
--ignore-failed-read --totals --exclude-from
/tmp/amanda/sendbackup._.20060731014330.exclude .
If I manually run
| tar -v --create --file /dev/null --directory / --one-file-system --sparse
--ignore-failed-read --totals --exclude-from
/tmp/amanda/sendbackup._.20060731014330.exclude .
it doesn't visit /proc and says
| tar: ./proc/: file is on a different filesystem; not dumped
when noticing its existence.
However, if I add `--listed-incremental /tmp/xxx' it tells me:
| tar: ./bin: Directory is new
| tar: ./boot: Directory is new
| tar: ./build: Directory is new
| tar: ./dev: Directory is new
| tar: ./etc: Directory is new
| tar: ./home: Directory is new
| tar: ./initrd: Directory is new
| tar: ./lib: Directory is new
| tar: ./lost+found: Directory is new
| tar: ./media: Directory is new
| tar: ./mnt: Directory is new
| tar: ./none: Directory is new
| tar: ./proc: Directory is new
| tar: ./root: Directory is new
| tar: ./sbin: Directory is new
| tar: ./scratch: Directory is new
| tar: ./sys: Directory is new
| tar: ./tmp: Directory is new
and so on. And it enters e.g. /home, while /home is on a separate file system
(just like /boot, /usr, /var, /tmp).
Looks like tar 1.15.92 is seriously broken...
Bummer, it's even a known issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376816
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377124
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Recovering files from DVD-recorded backup
After the struggle to burn my tape-split backups onto DVD, I find myself wondering just how useful they are. The current set of backups are still on hard drive, but what if I want to find an earlier copy of a file which has since been burned onto DVD? It seems to me that once vtapes are free for overwriting the corresponding index will be lost too. Can either amrestore or amrecover actually access these files? Anne pgpfo9mZkCLHk.pgp Description: PGP signature
Re: amcheck error
On Mon, Jul 31, 2006 at 10:14:29PM +0530, joseph wrote: > Amanda version: 2.5.0 > > Linux: Fedora Core 4 > > Windows Amanda client: Downloaded from > http://prdownloads.sourceforge.net/amanda-win32/amanda-clients-2.5.0-2001062 > > 8.zip?use_mirror=nchc and installed it on the Windows platform. The amandad > service is successfully starting by running the rc.amandad batch script on > the Windows side. > That sourceforge project is not part of the amanda project except that the win32 project use the amanda code as its starting point and attempts to be compatible with amanda servers. Note however the date, June, 2001. Although the win32 proports to be an amanda 2.5.0 version, the 2.5.0 branch that existed in 2001 was an ?experimental? branch and bears little relationship to the official amanda 2.5.0 version released in March 2006. Based on the lack of activity, I suspect that win32 project is defunct. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Still struggling with L0
On Mon, Jul 31, 2006 at 02:04:54PM +0100, Alan Pearson wrote: > Guys > > I'm have _real_ trouble trying to force Amanda to do a L0 backup of the > system that was effected by Amanda wiping out the last L0. > > I've tried to force a L0 backup of it, like : > > amadmin DailySet1 force qtvpdc.lab:/Shares > amadmin: qtvpdc.lab:/Shares is set to a forced level 0 at next run. > > > But when amdump runs, it just schedules a L1 or L2 backup. > > As you can imagine I'm not best pleased as I _still_ haven't been able to > get an L0 of this system on tape 5 days later (after severely reducing the > filesystem size) > > Any ideas ??? Just a total off-the-wall one. Is your gnutar version 1.15.9?. Another thread today indicated that those tar versions have a defect that lets them cross filesystems improperly. Perhaps your tar is doing so also and the estimated size seems too large because of that. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Recovering files from DVD-recorded backup
On Mon, Jul 31, 2006 at 06:56:22PM +0100, Anne Wilson wrote: > After the struggle to burn my tape-split backups onto DVD, I find myself > wondering just how useful they are. The current set of backups are still on > hard drive, but what if I want to find an earlier copy of a file which has > since been burned onto DVD? > > It seems to me that once vtapes are free for overwriting the corresponding > index will be lost too. Can either amrestore or amrecover actually access > these files? > Obviously not talking from experience here. So this is just a conceptual framework for something that might work. You do realize that you are, or will soon be, the leading expert on saving amanda backups on optical media, right? Suppose you had a different config for recovery (rec-config). The rec-config might use nearly all the same config data and could use the same curinfo/log/index directories as your normal config. Further, suppose you never deleted (amrmtape) or overwrote a vtape in your regular config (unless the dvd data were no longer needed). That would keep the index and log files available for amrecover. Your rec-config could use a device, maybe with chg-manual, that had "data" pointing to your dvd mount point (a symlink). I'm not thinking well enough to recommend how to handle the current vtapes. Maybe rm the data a day or two before reuse, relabel the vtape with amlabel for a new label, and maybe rename the slot one greater than current max. Another totally off-the-wall brainstorm; what if you reserve one slot in your changer directory as a symbolic link to your dvd mount point. Say it was slot99 or slot1 or ???. Perhaps when amrecover asked for a particular tape you could mount the appropriate dvd, and ammt/amtape it to the current active changer position. I was thinking about that from my current installation. My actual storage is on two external drives. My changer "slot" directory is on the hard system's hard drive and the "slotXX" directories are actually symbolic links to external drive directories. It could just as well point to a mounted dvd directory. Such an approach would be testable with your current setup. Rename the slotXX containing the original hard disk data. Recreate slotXX as a symbolic link to your dvd data. Try amrecover. You would still need to retain index etc. and relabel hd tapes. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Recovering files from DVD-recorded backup
On Mon, Jul 31, 2006 at 06:56:22PM +0100, Anne Wilson wrote: > It seems to me that once vtapes are free for overwriting the corresponding > index will be lost too. Can either amrestore or amrecover actually access > these files? Barring defects in the file/media, amrestore can *always* be used to recover an amanda backup. The procedure isn't quite as automated as amrecover. Here's an outline of what you might need to do: 1) Determine what tape you actually need. You might not know this for real the first time! Trial and error may be required. 2) Mount the DVD, say at /mnt. 3) To figure out what backups are on the tape, run something like this: # amrestore -f 0 -p file:/mnt/tapeX invalid-host > /dev/null This says to start at block 0, of the tape file:/mnt/tapeX (path depends on how you named tapes/burned them), search for "invalid-host" and throw the data to /dev/null. This command will give you a printout of the contents of the tape like this: amrestore: 0: skipping start of tape: date 20050128 label DailySet117 amrestore: 1: skipping blah.sda1.20050128.2 ... This output is formatted like "hostname.device.date.dumplevel". Find the dump that you are looking for. Let's assume we want to restore from "blah.sda1.20050128.2". 4) Now we run a valid amrestore command to get data: # amrestore -f 1 -p file:/mnt/tapeX blah sda1 | restore -if - This pulls data for blah:/sda1 from file:/mnt/tapeX starting at block 1. You'll get a shell very much like amrecover that you can navigate the filesystem dump, add files, and extract them. If you use tar, you'll want to do something like: # amrestore -f 1 -p file:/mnt/tapeX blah sda1 | tar xpvf - to untar the tarball into your current directory. -- Ross Vandegrift [EMAIL PROTECTED] "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
Re: Still struggling with L0
On Mon, 31 Jul 2006, Alan Pearson wrote:
I've tried to force a L0 backup of it, like :
amadmin DailySet1 force qtvpdc.lab:/Shares
amadmin: qtvpdc.lab:/Shares is set to a forced level 0 at next run.
But when amdump runs, it just schedules a L1 or L2 backup.
Syntax:
% amadmin help
Usage: amadmin {} ...
Valid s are:
version # Show version info.
force [ []* ]+ # Force level 0 at next run.
unforce [ []* ]+ # Clear force command.
force-bump [ []* ]+# Force bump at next run.
force-no-bump [ []* ]+ # Force no-bump at next run.
unforce-bump [ []* ]+ # Clear bump command.
reuse ... # re-use this tape.
no-reuse ...# never re-use this tape.
find [ []* ]* # Show which tapes these dumps are on.
delete [ []* ]*# Delete from database.
info [ []* ]* # Show current info records.
due [ []* ]* # Show due date.
balance # Show nightly dump size balance.
tape# Show which tape is due next.
bumpsize# Show current bump thresholds.
export [ []* ]*# Export curinfo database to
stdout.
import # Import curinfo database from stdin.
disklist [ []* ]* # Show disklist entries.
So your "amadmin DailySet1 force qtvpdc.lab:/Shares"
should be "amadmin DailySet1 force qtvpdc.lab /Shares"
-Mitch
Re: Still struggling with L0
On Mon, Jul 31, 2006 at 03:24:28PM -0400, Mitch Collinsworth wrote:
>
> On Mon, 31 Jul 2006, Alan Pearson wrote:
>
> >I've tried to force a L0 backup of it, like :
> >
> >amadmin DailySet1 force qtvpdc.lab:/Shares
> >amadmin: qtvpdc.lab:/Shares is set to a forced level 0 at next run.
> >
> >
> >But when amdump runs, it just schedules a L1 or L2 backup.
>
> Syntax:
>
> % amadmin help
>
> Usage: amadmin {} ...
> Valid s are:
> version # Show version info.
> force [ []* ]+ # Force level 0 at next run.
...
> info [ []* ]* # Show current info records.
...
>
>
> So your "amadmin DailySet1 force qtvpdc.lab:/Shares"
> should be "amadmin DailySet1 force qtvpdc.lab /Shares"
>
Nice catch. I'm surprised at the resulting message.
When I tried a similar bad syntax I got "amadmin: no disk matched"
The amadmin info command shows when a DLE is set to forced.
Here is one I forced for demo.
Current info for bigcow OPT:
(Forcing to level 0 dump at next run) <<
Stats: dump rates (kps), Full: 64.0, 64.0, -1.0
Incremental: 64.0, 64.0, 64.0
compressed size, Full: 640.0%,640.0%,640.0%
Incremental: 640.0%,640.0%,640.0%
Dumps: lev datestmp tape file origK compK secs
0 20060727 vtape1495 10 641
1 20060731 vtape18 121 10 641
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: tar escaping into a different file system
On Monday 31 July 2006 13:24, Geert Uytterhoeven wrote:
>On Mon, 31 Jul 2006, Jon LaBadie wrote:
>> On Mon, Jul 31, 2006 at 09:52:10AM +0200, Geert Uytterhoeven wrote:
[...]
>Looks like tar 1.15.92 is seriously broken...
>
>Bummer, it's even a known issue:
>
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376816
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377124
>
Who's working on that I wonder? And can you back up to 1.15.1? I've been
using it here for about a year, seems stable to me. But I don't know if
it handles all this late model SELinux thingies well at all.
>Gr{oetje,eeting}s,
>
> Geert
>
>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> [EMAIL PROTECTED]
>
>In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that. -- Linus Torvalds
--
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: Recovering files from DVD-recorded backup
On Monday 31 July 2006 13:56, Anne Wilson wrote: >After the struggle to burn my tape-split backups onto DVD, I find myself >wondering just how useful they are. The current set of backups are still > on hard drive, but what if I want to find an earlier copy of a file > which has since been burned onto DVD? > >It seems to me that once vtapes are free for overwriting the > corresponding index will be lost too. Can either amrestore or amrecover > actually access these files? No, but dd with the right options, piped into tar or gzip & then tar can. Thats one of the beautifull things about amanda, basic system tools can do a restore without amanda's help. >Anne -- 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: Still struggling with L0
Ooops
Sorry that's what I typed, cut and paste was a bit off as I tried to
remove the company name from the host !
Finally got a L0 pumped to tape, after several runs (other errors were
involved such as exclude list wrong)
many thanks everyone.
--
AlanP
On Mon, July 31, 2006 8:24 pm, Mitch Collinsworth wrote:
>
> On Mon, 31 Jul 2006, Alan Pearson wrote:
>
>> I've tried to force a L0 backup of it, like :
>>
>> amadmin DailySet1 force qtvpdc.lab:/Shares
>> amadmin: qtvpdc.lab:/Shares is set to a forced level 0 at next run.
>>
>>
>> But when amdump runs, it just schedules a L1 or L2 backup.
>
> Syntax:
>
> % amadmin help
>
> Usage: amadmin {} ...
> Valid s are:
> version # Show version info.
> force [ []* ]+ # Force level 0 at next run.
> unforce [ []* ]+ # Clear force command.
> force-bump [ []* ]+# Force bump at next run.
> force-no-bump [ []* ]+ # Force no-bump at next
> run.
> unforce-bump [ []* ]+ # Clear bump command.
> reuse ... # re-use this tape.
> no-reuse ...# never re-use this tape.
> find [ []* ]* # Show which tapes these dumps
> are on.
> delete [ []* ]*# Delete from database.
> info [ []* ]* # Show current info records.
> due [ []* ]* # Show due date.
> balance # Show nightly dump size balance.
> tape# Show which tape is due next.
> bumpsize# Show current bump thresholds.
> export [ []* ]*# Export curinfo database
> to stdout.
> import # Import curinfo database from
> stdin.
> disklist [ []* ]* # Show disklist entries.
>
>
> So your "amadmin DailySet1 force qtvpdc.lab:/Shares"
> should be "amadmin DailySet1 force qtvpdc.lab /Shares"
>
> -Mitch
>
Re: Recovering files from DVD-recorded backup
On Monday 31 July 2006 19:45, Jon LaBadie wrote: > On Mon, Jul 31, 2006 at 06:56:22PM +0100, Anne Wilson wrote: > > After the struggle to burn my tape-split backups onto DVD, I find myself > > wondering just how useful they are. The current set of backups are still > > on hard drive, but what if I want to find an earlier copy of a file which > > has since been burned onto DVD? > > > > It seems to me that once vtapes are free for overwriting the > > corresponding index will be lost too. Can either amrestore or amrecover > > actually access these files? > > Obviously not talking from experience here. > So this is just a conceptual framework for something that might work. > You do realize that you are, or will soon be, the leading expert > on saving amanda backups on optical media, right? > Now there's a scarey thought ;-) > Suppose you had a different config for recovery (rec-config). > The rec-config might use nearly all the same config data and > could use the same curinfo/log/index directories as your > normal config. Further, suppose you never deleted (amrmtape) > or overwrote a vtape in your regular config (unless the dvd > data were no longer needed). That would keep the index and > log files available for amrecover. > Never overwrite a vtape? So it would be necessary to add vtapes from time to time? > Your rec-config could use a device, maybe with chg-manual, > that had "data" pointing to your dvd mount point (a symlink). > > I'm not thinking well enough to recommend how to handle the > current vtapes. Maybe rm the data a day or two before reuse, > relabel the vtape with amlabel for a new label, and maybe rename > the slot one greater than current max. > > > Another totally off-the-wall brainstorm; what if you reserve > one slot in your changer directory as a symbolic link to your > dvd mount point. Say it was slot99 or slot1 or ???. Perhaps > when amrecover asked for a particular tape you could mount > the appropriate dvd, and ammt/amtape it to the current active > changer position. > > I was thinking about that from my current installation. My > actual storage is on two external drives. My changer "slot" > directory is on the hard system's hard drive and the "slotXX" > directories are actually symbolic links to external drive > directories. It could just as well point to a mounted dvd > directory. > So that backup wouldn't actually write to the hard disk, but to the DVD? If it did that, tape-spanning would be problematic, wouldn't it? I can't see how it could work. > Such an approach would be testable with your current setup. > Rename the slotXX containing the original hard disk data. > Recreate slotXX as a symbolic link to your dvd data. Try > amrecover. > > You would still need to retain index etc. and relabel hd tapes. That's a lot to think about and experiment with. I'll play around a little when I can make time. Thanks for the ideas. Anne pgpPfCWAFSkbZ.pgp Description: PGP signature
Re: Release of amanda-2.5.1b2
2.5.1b2 RPMs and source tar ball are available for following platforms at http://www.zmanda.com/downloads.html - Red Hat Enterprise server 4, - Red Hat Enterprise server 3 - Suse Linux Enterprise 9, - Suse Linux Enterprise 10, - Open Suse 10.0, - Fedora Core 3, - Fedora Core 4, - Fedora Core 5 and - Source RPM The list of features in 2.5.1b2 release and how to use them are in http://wiki.zmanda.com/index.php/2.5.1_features page. Any feedback on this beta release and wiki documentation would be appreciated. Thanks, Paddy On 7/28/06, Jean-Louis Martineau <[EMAIL PROTECTED]> wrote: Hello, The Amanda core team is pleased to announce the second beta release of Amanda 2.5.1, the 2.5.1b2 release. It should be the latest beta before the release of 2.5.1. We plan to release the final 2.5.1 at the end of the august month. Please, test this latest beta release and report all bug you can find. It can be dowloaded from http://www.amanda.org (not yet available) or https://sourceforge.net/project/showfiles.php?group_id=120. Here's a list of the changes for release 2.5.1b2 (from the NEWS file): Look at the ReleaseNotes and ChangeLog file for more details, you will alos find usefull information on http://wiki.zmanda.com/index.php/2.5.1_features. * debug file are seperated in subdir client/server/amandad with the config name. * amandates client config option. * gnutar_list-dir client config option. * dumptype holdingdisk get new value: NEVER, AUTO, REQUIRED * amgetconf doesn't write the BUGGY message. * work with tar-1.15.91 * Open SSL encryption support * amfetchdump -o is replaced by -O. * amrecover_do_fsf default to yes * amrecover_check_label default to yes * amcheck -w will do all test including the tape writable test. use amcheck -t -w if you want only the tape writable test. * usetimestamps * bsdudp/bsdtcp, 2 new auth. * Unlimited number of DLE on a client with bsdtcp/rsh or ssh auth. * docs/howto-auth.txt * amandad_path, client_username and ssh_keys (for ssh/rsh) * client config file (see man amanda-client.conf) * amrecover use the security-api * amoldrecover which use the old amindexd/amidxtaped protocol * -o option to overwrite config option (see in man amanda, the CONFIGURATION OVERWRITE section) -- Amanda documentation: http://wiki.zmanda.com Amanda forums: http://forums.zmanda.com
Re: amcheck error
> Is there a requirement that we need to run Cygwin mandatorily on the > Windows > client for getting this up and running? I am not user of the windows client. But are you sure Amanda is fully operational on the Linux machine first? - what "amcheck -s " is saying? - what is you have a DLE for the Linux machine only and try "amcheck -c " ? - what is you let Amanda run with the Linux machine only? Once I am sure the Linux server is working, I would see to the Windows client. Bests, Olivier
