Spurious "tar: Skipping to next header" at end of restore

At the end of amcheckdump and amrecover (if i recover the last file) i am getting: tar: Skipping to next header /usr/bin/tar: Exiting with failure status due to previous errors Amrecover still restores every file as it should. This only happens when i have encryption on. Manual restores

RE: CPU eating tar process

da-us...@amanda.org On Behalf Of Debra S Baddorf Sent: Tuesday, September 21, 2021 1:38 PM To: Kees Meijs | Nefos Cc: Debra S Baddorf ; amanda-users@amanda.org Subject: Re: CPU eating tar process ATTENTION: This email came from an external source. Do not open attachments or click on links from unknow

RE: CPU eating tar process

Jens, Kees, I think Shilly Tar, STAR is multi-threaded and that we use it with Amanda on at least one of our Amanda clients. Honestly don't recall (without checking the docs) if spindle is to group DLE's for concurrent backup, or to avoid running them concurrently, I think that latter

Re: CPU eating tar process

Have you experimented with dividing those target disks into smaller pieces, using tar? So that amanda isn’t doing level 0 on all parts on the same day? I’ve divided some disks as far as a*, b*, c*, …. z*, Other (to catch caps or numbers or future additions). I’ve found that each piece

Re: CPU eating tar process

bound?  If so, you may have to live with slw backups.  We eventually added NVMe SSDs to our ZFS array as special devices and sent files smaller than 128KB to NVMe, which along with the metadata, helped speed up backups quite a bit. It may be worth trying star instead of tar, but I think it too

Re: CPU eating tar process

Thanks, I'll take that into consideration. K. On 21-09-2021 16:30, Jens Berg wrote: maybe you can try to split up the files into several DLEs and put them into different spindles. That should fire off multiple instances of tar in parallel, if I understood Amanda's concept of spindles

Re: CPU eating tar process

Ah, I'll take a look at that as well. Thanks! K. On 21-09-2021 16:44, Cuttler, Brian R (HEALTH) wrote: I think Shilly Tar, STAR is multi-threaded and that we use it with Amanda on at least one of our Amanda clients. Honestly don't recall (without checking the docs) if spindle is to group

Re: CPU eating tar process

up backups quite a bit. It may be worth trying star instead of tar, but I think it too is single threaded. There's something called tarsplitter on github which is multi-threaded if you don't mind experimenting: https://github.com/AQUAOSOTech/tarsplitter Also Sprach Kees Meijs | Nefos: Hi list

Re: CPU eating tar process

Hi Kees, maybe you can try to split up the files into several DLEs and put them into different spindles. That should fire off multiple instances of tar in parallel, if I understood Amanda's concept of spindles correctly. Hope it helps, Jens On 21.09.2021 15:55, Kees Meijs | Nefos wrote

CPU eating tar process

Hi list, We've got some backup targets with lots (and lots, and then some) of files. There's so much of them that making back-ups is becoming a problem. During the backup process, tar(1) is eating up a CPU core. There's no or hardly no I/O wait to be seen. Very likely tar is single threaded

Re: The saga comtinues:Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

ssue...) > > > > Nathan > > It was running just fine an hour before the backup started, as I had > another missing excludes file msg from amcheck, and had created > the /GenesAmandaHelper-0.61 directory, and had touc

Re: The saga comtinues:Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

ssing excludes file msg from amcheck, and had created the /GenesAmandaHelper-0.61 directory, and had touched the excludes file therein. I had not made any entries in that tile so it would exclude such as /sys or /proc from the / dle. I suspect that allowing tar to scan /proc may have lead to the c

Re: The saga comtinues:Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On Thu, Sep 05, 2019 at 04:14:43 -0400, Gene Heskett wrote: > Looks like its worse than I thought. While amcheck was happy, picnc > crashed on the first access last night. > > >From the email: > FAILURE DUMP SUMMARY: > picnc / lev 1 FAILED [data timeout] > picnc / lev 1 FAILED [[request

The saga comtinues:Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On Wednesday 04 September 2019 16:37:26 Gene Heskett wrote: > On Wednesday 04 September 2019 16:15:53 Uwe Menges wrote: > > On 9/4/19 7:43 PM, Gene Heskett wrote: > > > On Wednesday 04 September 2019 12:36:43 Charles Curley wrote: > > >> I don't understand it either, but then again all I know is

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On Wednesday 04 September 2019 16:15:53 Uwe Menges wrote: > On 9/4/19 7:43 PM, Gene Heskett wrote: > > On Wednesday 04 September 2019 12:36:43 Charles Curley wrote: > >> I don't understand it either, but then again all I know is what > >> Nathan pointed out in the release notes: > >>

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On 9/4/19 7:43 PM, Gene Heskett wrote: > On Wednesday 04 September 2019 12:36:43 Charles Curley wrote: >> I don't understand it either, but then again all I know is what Nathan >> pointed out in the release notes: >> https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-ne >>

Fw: Bug#939411: Acknowledgement (amanda: merged /usr and tar path problem in /etc/amanda-security.conf)

Begin forwarded message: Date: Wed, 04 Sep 2019 17:36:03 + From: "Debian Bug Tracking System" To: Charles Curley Subject: Bug#939411: Acknowledgement (amanda: merged /usr and tar path problem in /etc/amanda-security.conf) Thank you for filing a new Bug report with Debian

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On Wednesday 04 September 2019 12:36:43 Charles Curley wrote: > On Wed, 4 Sep 2019 12:10:09 -0400 > > Gene Heskett wrote: > > > You can see from Gene's error messages that it's currently trying > > > to run "/usr/bin/tar" -- and that is what you would expec

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

hich isn't present on amanda mailing list messages. On e.g. bug-tar, it looks like List-Post: <mailto:bug-...@gnu.org> Yours, Uwe

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On Wed, 4 Sep 2019 12:10:09 -0400 Gene Heskett wrote: > > You can see from Gene's error messages that it's currently trying to > > run "/usr/bin/tar" -- and that is what you would expect on a > > usrmerged system. So he just needs to grant that permission (i.e. &

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

ILED ["security file > > > '/etc/amanda-security.conf' do not allow to run '/usr/bin/tar' as > > > root for 'amgtar:gnutar_path'"] picnc /boot lev 0 FAILED > > > ["security file > > > '/etc/amanda-security.conf' do not allow to run '/usr/bin/tar' as

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

ian. I don't use rasbian. If there are differences between them, I > wouldn't know of them. > > > FAILURE DUMP SUMMARY: > > picnc / lev 0 FAILED ["security file '/etc/amanda-security.conf' > > do not allow to run '/usr/bin/tar' as root for > > 'amgtar:gnutar_path'&q

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On Wed, Sep 04, 2019 at 05:48:41 -0600, Charles Curley wrote: > On Wed, 4 Sep 2019 07:02:58 -0400 > Gene Heskett wrote: > > > FAILURE DUMP SUMMARY: > > picnc / lev 0 FAILED ["security file '/etc/amanda-security.conf' > > do not allow to run '/usr/bin/tar'

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

ian. I don't use rasbian. If there are differences between them, I > wouldn't know of them. > Not rasbian, but "debian-arm". It installs an arm64, not an armhf, and runs sweet. > > FAILURE DUMP SUMMARY: > > picnc / lev 0 FAILED ["security file '/etc/amanda-secu

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

E DUMP SUMMARY: > picnc / lev 0 FAILED ["security file '/etc/amanda-security.conf' > do not allow to run '/usr/bin/tar' as root for 'amgtar:gnutar_path'"] > picnc /boot lev 0 FAILED ["security file > '/etc/amanda-security.conf' do not allow to run '/usr/bin/tar'

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

ing and grepping suggest that it never was installed and > then removed. Ok, I've tried about every option thats been discussed, I think its time to file a bug against debian for breaking amanda with buster. FAILURE DUMP SUMMARY: picnc / lev 0 FAILED ["security file '/etc/amanda-security.

Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

On Tue, 3 Sep 2019 21:15:55 -0600 Charles Curley wrote: > On Tue, 3 Sep 2019 21:48:52 -0400 > Nathan Stratton Treadway wrote: > > > p.s. On the Buster systems you have installed from scratch, and thus > > have the merge-onto-/usr in place, is the "usrmerge" package > > installed? > > It is

Re: tar backups not doing incrementals

So I don't > know if it could be device minor changing, etc. I don't know what else it > could be, though As I mentioned before I am not familiar with FreeNAS and FreeBSD Jails, but all Unix filesystem have a device number assigned to them as part of the basic "API" of being

Re: tar backups not doing incrementals

uns as 0. > > > > > > How do I fix this? > > > > I fixed a similar symptom on my system with > > property "CHECK-DEVICE" "NO" > > (using amgtar), which hands "--no-check-device" to GNU tar, > > which makes it

Re: tar backups not doing incrementals

out Jim, just curious if you had had a chance to investigate your GNU-tar-incremental problems any further? Nathan Nathan Stratton Treadway - natha...@ontko.co

Re: tar backups not doing incrementals

ay wrote: > On Sat, Jun 15, 2019 at 20:35:30 +0200, Uwe Menges wrote: > > On 6/15/19 6:43 PM, Jim Kusznir wrote: > > > Ever since, any backup is run as a level 0 (even though it > > > reports doing a level 1, 2, etc).  Everything runs as 0. > > > > > > How do I

Re: tar backups not doing incrementals

On Mon, Jun 17, 2019 at 18:13:30 -0700, Jim Kusznir wrote: > The backups are not completing because the level 0 problem: planner thinks > its running a backup that can complete, but ends up with 10x the data that > a single run can handle, and it fills up the tape and the holding disk > (which is

Re: tar backups not doing incrementals

nstalled in the main FreeNAS applaince is wiped next upgrade. Jails are how you install additional packages in a long-term way. The jail does have access to the underlying filesystem from FreeNAS. Maybe I do need that option to tell it not to pay attention to devices...but I thought tar would go

Re: tar backups not doing incrementals

> But those are in fact volumes that I've been getting level 0's of even > though it claims its a level 1 or 2. Yes, that's not a good sign. GNU tar updates the snapshot file passed in to it as it runs, so before invoking tar Amanda makes a copy of the previous level's snapshot file (over to the

Re: tar backups not doing incrementals

gt; > > How do I fix this? > > > > I fixed a similar symptom on my system with > > property "CHECK-DEVICE" "NO" > > (using amgtar), which hands "--no-check-device" to GNU tar, > > which makes it no longer think the toplevel dir has be

Re: tar backups not doing incrementals

ed a similar symptom on my system with > property "CHECK-DEVICE" "NO" > (using amgtar), which hands "--no-check-device" to GNU tar, > which makes it no longer think the toplevel dir has been renamed, > so it doesn't store all files in its incremental. Yes, i

Re: tar backups not doing incrementals

amgtar), which hands "--no-check-device" to GNU tar, which makes it no longer think the toplevel dir has been renamed, so it doesn't store all files in its incremental. I think what happened to me is that some LVM volumes got mounted with a different minor number, triggering that. G

Re: tar backups not doing incrementals

actual level 0 backup? > dumptype is based on comp-tar-user, and has exclude lists (I'm backing up a > 100TB storage array by subdividing using exclude lists as indicated in the > wiki). > > What could have been going on here? How do I get it working again? Assuming you are referring

Re: tar backups not doing incrementals

el 1, 2, etc).  Everything runs as 0. > > How do I fix this? > > dumptype is based on comp-tar-user, and has exclude lists (I'm backing > up a 100TB storage array by subdividing using exclude lists as > indicated in the wiki). > > What could have been going on here?  How do I get it working again? > > Thanks! > --Jim

tar backups not doing incrementals

it in the process. I also rebooted the BSD client. Ever since, any backup is run as a level 0 (even though it reports doing a level 1, 2, etc). Everything runs as 0. How do I fix this? dumptype is based on comp-tar-user, and has exclude lists (I'm backing up a 100TB storage array by subdividing using

Re: Gnu tar 1.27 and sparse files

On 25 May 2016, at 19:41, Joi L. Ellis wrote: > Now, this link into Active Directory has bloated the /var/log/lastlog file up > to something massive, and it’s taking forever to get estimates for dumps from > this machine, to the point that Amanda server gives up with a

Gnu tar 1.27 and sparse files

massive, and it's taking forever to get estimates for dumps from this machine, to the point that Amanda server gives up with a timeout error. The actual size of the file is only 52K, but its apparent size is 337G. I can strace tar (gnutar 1.27.1) and it's sitting there reading 512 blocks of zeroes

Excluding AutoFS 'directories' when using tar

no # Don't dump to temp disk (holdingdisk) before backup to tape index yes # Generate index. For restoration usage fallback-splitsize 1000 Mb tape_splitsize 1000 Mb exclude list optional .excludes } define dumptype root-tar { # How to dump root's directory global

Re: Excluding AutoFS 'directories' when using tar

man amanda.conf Konsole output exclude [ list | file ][[optional][append][ string]+] Konsole output For GNU-tar, exclude expressions must always be specified as relative to the top-level directory of the DLE, and must start with ./. See the manpages for individual

Re: Excluding AutoFS 'directories' when using tar

even if amanda/tar could back them up, attempting to recover them would likey cause a crash due to session differences. The path to this file exclude-list however is specified in absolute: exclude list /GenesAmandaHelper-0.61/excludes In the Global dumptype The backup drive itself (I use

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

tar 1.27 or later, but are are still using 'program GNUTAR' dumptypes and thus don't have an easy way to manually add this message to the NORMAL list. Anyway, also attached is a patch to do that. Nathan

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

://sourceforge.net/p/amanda/code/5765/ However, it looks like the corresponding change wasn't made to the amgtar man page; a patch to do that is attached. Also, is there some reason this same NORMAL RE wasn't added to the sendclient-gnutar.c file? I assume many sites now have client machines running GNU tar

Warning on Version of tar When Compiling 3.3.6

When compiling 3.3.6 I received the message: WARNING: /bin/tar is not bsdtar, so it will not be used. What tar is it going to use if not that one? The command: /bin/tar --version returns: tar (GNU tar) 1.15.1 I thought that was a good tar to use. What's the right one? Steve -- Steven J

Re: Warning on Version of tar When Compiling 3.3.6

Steven, Amanda can use gnutar, star, suntar or bsdtar. On 07/17/2014 11:59 AM, Steven Backus wrote: When compiling 3.3.6 I received the message: WARNING: /bin/tar is not bsdtar, so it will not be used. It means that it didn't find a bsdtar, which if fine unless you want to use the ambsdtar

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

Thank you all for your help. I've decided to follow Jens' approach and have added the directories to my tar exclude list. Now sendbackup doesn't complain about the new tar warnings anymore. We don't use amgtar and I don't know if it would be worth the effort to switch from tar to amgtar

sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

.cluster.peercode.nl__1.new' Mon Jun 2 02:23:55 2014: thd-0x100f600: sendbackup: Spawning /usr/lib/amanda/runtar runtar daily /bin/tar --create --file - --directory / --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/app26.cluster.peercode.nl__1.new --sparse --ignore-failed-read --totals

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

You can modify your disklist and add exclude statements to your DLE, something like myhost.some.domain / / { root-tar exclude append ./dev exclude append ./home ... } 1 Probably it also makes sense to exclude other directories that don't need to be backed up, for example ./tmp, ./var

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

Hi Mark, Which version of tar are you using? ('/bin/tar --version' on the client) I never see the 'directory is on a different filesystem; not dumped' message. Jean-Louis On 06/02/2014 03:54 AM, Mark Ruys wrote: Hi, In my Amanda sendbackup log, I get the following messages: Mon Jun 2 02

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

Op 2 jun. 2014, om 12:49 heeft Jean-Louis Martineau martin...@zmanda.com het volgende geschreven: Hi Mark, Which version of tar are you using? ('/bin/tar --version' on the client) 1.27.1 Thanks, Mark I never see the 'directory is on a different filesystem; not dumped' message. Jean

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

mark, It is a new message in tar 1.27. With the GNUTAR program, you must add exclude like Jens suggested. A better option is to use the amgtar application: program APPLICATION application { plugin amgtar property NORMAL : ./dev: directory is on a different filesystem; not dumped } Jean

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

On Mon, Jun 02, 2014 at 07:50:33AM -0400, Jean-Louis Martineau wrote: mark, It is a new message in tar 1.27. With the GNUTAR program, you must add exclude like Jens suggested. A better option is to use the amgtar application: program APPLICATION application { plugin amgtar

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

On 06/02/2014 02:46 PM, Jon LaBadie wrote: On Mon, Jun 02, 2014 at 07:50:33AM -0400, Jean-Louis Martineau wrote: mark, It is a new message in tar 1.27. With the GNUTAR program, you must add exclude like Jens suggested. A better option is to use the amgtar application: program APPLICATION

Re: sendbackup: 118: strange(?): /bin/tar: ./dev: directory is on a different filesystem; not dumped

Jon LaBadie j...@jgcomp.com (Mo 02 Jun 2014 20:46:00 CEST): On Mon, Jun 02, 2014 at 07:50:33AM -0400, Jean-Louis Martineau wrote: mark, It is a new message in tar 1.27. With the GNUTAR program, you must add exclude like Jens suggested. A better option is to use the amgtar

this does not look like a tar archive

Hi list, i have a strange problem with two different DLEs. I get the following error on a regular base: DEBIAN //DC02/Backup lev 1 FAILED [/bin/tar: This does not look like a tar archive] /-- DEBIAN //DC02/Backup lev 1 FAILED [/bin/tar: This does not look like a tar archive

Re: this does not look like a tar archive

On 04/14/2014 04:07 AM, Traugott Simon wrote: Hi list, i have a strange problem with two different DLE´s. I get the following error on a regular base: DEBIAN //DC02/Backup lev 1 FAILED [/bin/tar: This does not look like a tar archive] /-- DEBIAN //DC02/Backup lev 1 FAILED [/bin/tar

Aw: Re: this does not look like a tar archive

: parent_wtr 8 Mon Apr 14 01:41:15 2014: thd-0x1b6e600: Amsamba: password THATSMYPW Mon Apr 14 01:41:15 2014: thd-0x1b6e600: Amsamba: child_rdr 5 Mon Apr 14 01:41:15 2014: thd-0x1b6e600: Amsamba: /bin/tar -tf - Mon Apr 14 01:41:15 2014: thd-0x1b6e600: Amsamba: warning: close() on unopened filehandle 0

Re: [Bug-tar] New install of 1.27, is refusing to backup certain subtrees

.) You can suppress this message with the --warning=no-xdev option, so there's no need to update Amanda. (A bit off-topic here, but for what it's worth Amanda already has a mechanism for classifying the significance of various output lines it gets from tar. So mostly likely they'll

Re: Testing tar with amdump was(level 1 does not behave as level 1)

, but just in case you haven't already found it, the exact format of the snapshot files is documented in the GNU tar textinfo manual, e.g. this page on the GNU website: http://www.gnu.org/software/tar/manual/html_node/Snapshot-Files.html#SEC190 They are considered binary files because they use a NUL

Re: [Bug-tar] New install of 1.27, is refusing to backup certain subtrees

On Monday 03 March 2014 01:44:15 Nathan Stratton Treadway did opine: On Sun, Mar 02, 2014 at 06:39:09 -0500, Gene Heskett wrote: STRANGE DUMP DETAILS: /-- coyote /lib lev 0 STRANGE [...] ? /usr/local/bin/tar: ./init/rw: directory is on a different filesystem; not dumped

Re: [Bug-tar] New install of 1.27, is refusing to backup certain subtrees

On Monday 03 March 2014 01:47:46 Sergey Poznyakoff did opine: Nathan Stratton Treadway natha...@ontko.com ha escrit: What has changed is that tar 1.27 now prints a warning message when it detects a filesystem boundary (when --one-file-system is in effect), while earlier versions didn't

Testing tar with amdump was(level 1 does not behave as level 1)

Testing my problem has taken nearly 2 weeks, also because my quick tests with tar options but on smaller directories do not produce the erroneous results as the full amdumps do, which take long times. The tests were also rather haphazard. I might try to identify the problems, but will do so more

Re: tar suddenly hanging, backups near 100% fail

On Wednesday 26 February 2014 10:39:13 Gene Heskett did opine: Greetings; 3 backups ago, with no change to the amanda.conf in months, I have awakened to a hung tar task using 100% of a core, more than 5 hours after it should have completed. It is in that state now. How can I find what

Re: tar suddenly hanging, backups near 100% fail

On Wednesday 26 February 2014 12:19:18 Gene Heskett did opine: On Wednesday 26 February 2014 10:39:13 Gene Heskett did opine: Greetings; 3 backups ago, with no change to the amanda.conf in months, I have awakened to a hung tar task using 100% of a core, more than 5 hours after

Re: tar suddenly hanging, backups near 100% fail

I missed whether you tried using strace and lsof (or the /proc file system) to see what system call and/or what file tar might be stuck on? --- Markus A. Iturriaga Woelfel, IT Administrator Department of Electrical Engineering and Computer Science University of Tennessee Min H. Kao Building

tar suddenly hanging, backups near 100% fail

Greetings; 3 backups ago, with no change to the amanda.conf in months, I have awakened to a hung tar task using 100% of a core, more than 5 hours after it should have completed. It is in that state now. How can I find what is causing this blockage? Here is the report from yesterdays attempt

Re: 7zip instead of tar?

On 06/19/2013 10:37 PM, Schlacta, Christ wrote: Is it possible, or even better, supported to use .7z instead of .tar for the backup archive format? I know .7z gets incredible compression rates and provides the archive layer functionality as well, and includes an encryption mechanism as well

7zip instead of tar?

Is it possible, or even better, supported to use .7z instead of .tar for the backup archive format? I know .7z gets incredible compression rates and provides the archive layer functionality as well, and includes an encryption mechanism as well.

Solaris cluster and amanda, tar dumps

the problems seem like they'll be in my power to fix. bionsc1 /global/usr1-others /dev/md/bg-schost-1/rdsk/d311 { user-tar exclude ./biosup/bioproj/people/dlong } bioquad/usr1 comp-user amcheck -c bionsc bionsc1 /global/usr1-others Amanda Backup Client

Re: GNU tar --one-file-system flag seems to have no effect

strange that it has never affected backup of /, as indicated by Nathan above. I did experimentation using a simple directory tree to emulate your move-to-new-partition situation, and confirmed that even in tar 1.26 (i.e. the current latest release) there's a bug that shows up in your particular

Re: GNU tar --one-file-system flag seems to have no effect

Hello all, Just to keep the amount of messages down, I'll respond to several questions at once. Robert wrote: Is tar on the OP system actually GNUTar? On *Linux* systems it generally is, but I am not certain about *commercial* UNIX systems... It is true that 'standard' tar on FreeBSD

Re: GNU tar --one-file-system flag seems to have no effect

in the directory lists after copying them to the new partition. After mounting the new partition on /storage/lists they would be masked and would not be accessible using file system semantics. But dump-like programs could still see, and back-up, the masked files. Tar should be using file system semantics

Re: GNU tar --one-file-system flag seems to have no effect

On 05/18/2012 12:33 AM, Toomas Aas wrote: Hello Nathan! What exactly happened that convinced you the contents of /storage/lists was still getting included in the dump for /storage ? First I noticed in the e-mail report that level 1 backup of /storage was just a little bit bigger than

Re: GNU tar --one-file-system flag seems to have no effect

On Fri, May 18, 2012 at 07:33:31 +0300, Toomas Aas wrote: First I noticed in the e-mail report that level 1 backup of /storage was just a little bit bigger than level 0 backup of /storage/lists (9703 vs 9120 MB). Then I looked at the index file of /storage DLE on server for that day's amdump

Re: GNU tar --one-file-system flag seems to have no effect

On Thu, 17 May 2012, Toomas Aas wrote: I had one big filesystem mounted on /storage which was backed up by a DLE using comp-user-tar dumptype. Yesterday I split out one subdirectory, /storage/lists, into separate partition and added another DLE for /storage/lists, also using comp-user-tar

Re: GNU tar --one-file-system flag seems to have no effect

Thu, 17 May 2012 kirjutas Christopher X. Candreva ch...@westnet.com: One file system means just that. Unless /storage/lists is a separate partition mounted at that point, /storage is one file system, as you say above. You need the explicit exclude. That was exactly my point. Until day before

Re: GNU tar --one-file-system flag seems to have no effect

On Thu, 17 May 2012, Toomas Aas wrote: Thu, 17 May 2012 kirjutas Christopher X. Candreva ch...@westnet.com: One file system means just that. Unless /storage/lists is a separate partition mounted at that point, /storage is one file system, as you say above. You need the explicit exclude.

Re: GNU tar --one-file-system flag seems to have no effect

On Thu, May 17, 2012 at 07:02:51 +0300, Toomas Aas wrote: Tonight's amdump run seems to have backed up the contents of /storage/lists twice, once as /storage/lists DLE and once as part of /storage DLE. I thought that '--one-file-system' flag passed by Amanda to gtar is supposed to prevent

Re: GNU tar --one-file-system flag seems to have no effect

on /storage/lists they would be masked and would not be accessible using file system semantics. But dump-like programs could still see, and back-up, the masked files. Tar should be using file system semantics, but like I said, grasping. jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore

Re: GNU tar --one-file-system flag seems to have no effect

Hello Nathan! What exactly happened that convinced you the contents of /storage/lists was still getting included in the dump for /storage ? First I noticed in the e-mail report that level 1 backup of /storage was just a little bit bigger than level 0 backup of /storage/lists (9703 vs

Re: GNU tar --one-file-system flag seems to have no effect

could still see, and back-up, the masked files. Tar should be using file system semantics, but like I said, grasping. I just double-checked and I'm pretty sure I did delete the original files from the directory. When I umount /storage/lists, the directory appears empty. -- Toomas Aas

GNU tar --one-file-system flag seems to have no effect

I had one big filesystem mounted on /storage which was backed up by a DLE using comp-user-tar dumptype. Yesterday I split out one subdirectory, /storage/lists, into separate partition and added another DLE for /storage/lists, also using comp-user-tar dumptype. Tonight's amdump run seems

Re: tar estimate dying

wrote: Can you post the exact error message you get from amanda? You said 'broken pipe', where do you get it. Telling 'tar estimate dying' or 'broken pipe' is useless if you don't show how/where you get them. The sendsize debug file looks good, please post the debug file that show the error you

tar estimate dying

the tar process just dies and the estimate doesnt seem to get to the server. The / is only about 10gig and until recently been fine. These are old computers, however the /home part. is 20gig and has been fine. I am using tar (now 1.20 after downgrading from 1.23 for testing) I have also tried

Re: tar estimate dying

this question, as I have run out of ideas. I am running a 2.6.1p2-3 server with the same as clients. Recently a couple of clients are not able to backup their / file system. All of the other file systems on them backup fine (/home /boot). After about 30 minutes the tar process just dies and the estimate

Re: tar estimate dying

Can you post the exact error message you get from amanda? You said 'broken pipe', where do you get it. Telling 'tar estimate dying' or 'broken pipe' is useless if you don't show how/where you get them. The sendsize debug file looks good, please post the debug file that show the error you

Re: tar estimate dying

working for the last six years. On Thu, 7 Jul 2011, Jean-Louis Martineau wrote: Can you post the exact error message you get from amanda? You said 'broken pipe', where do you get it. Telling 'tar estimate dying' or 'broken pipe' is useless if you don't show how/where you get them. The sendsize

Re: tar estimate dying

the connection itself. Something to look for Deb Baddorf On Jul 7, 2011, at 2:14 PM, Jean-Louis Martineau wrote: Can you post the exact error message you get from amanda? You said 'broken pipe', where do you get it. Telling 'tar estimate dying' or 'broken pipe' is useless if you don't

Re: tar estimate dying

Martineau wrote: Can you post the exact error message you get from amanda? You said 'broken pipe', where do you get it. Telling 'tar estimate dying' or 'broken pipe' is useless if you don't show how/where you get them. The sendsize debug file looks good, please post the debug file that show

Re: tar estimate dying

Jean-Louis, On Thu, Jul 07, 2011 at 03:35:58PM -0400, Jean-Louis Martineau wrote: If you got only 'failed' for the error message, then something is really broken, I would like to see it, can you post the complete line from the 'FAILURE DUMP SUMMARY' section of the report. I mispoke, this is

Re: tar 1.2.6

/2011 02:23 AM, gene heskett wrote: So finally, linux once again has a tar that amanda can use. Which version of amanda are you using? amanda-3.2.1.svn.3841.tar.gz I think Gene does a nightly download and build and install of the most recent verzion just before kicking off of amdump

Re: tar 1.2.6

, the crontab directory got moved, so nothing I was depending on cron to do was done for about 30 hours. I meowed some on the pclos forum, as did a few others over that! So finally, linux once again has a tar that amanda can use. What has it been, 5, 6 months now we've had to make sure the package

Re: tar 1.2.6

On 03/22/2011 02:23 AM, gene heskett wrote: So finally, linux once again has a tar that amanda can use. Which version of amanda are you using?

Re: tar 1.2.6

On Tue, Mar 22, 2011 at 10:28:29AM -0400, Mike Neimoyer wrote: On 03/22/2011 02:23 AM, gene heskett wrote: So finally, linux once again has a tar that amanda can use. Which version of amanda are you using? I think Gene does a nightly download and build and install of the most recent

Re: tar 1.2.6

On Tuesday, March 22, 2011 06:34:42 PM Jon LaBadie did opine: On Tue, Mar 22, 2011 at 10:28:29AM -0400, Mike Neimoyer wrote: On 03/22/2011 02:23 AM, gene heskett wrote: So finally, linux once again has a tar that amanda can use. Which version of amanda are you using? amanda-3.2.1.svn

tar 1.2.6

I see is available from the pclos repo's this morning, so I'm going to take a chance. I'll report if it works tonight. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)

  1   2   3   4   5   6   7   8   9   >