hello,
we have an amanda server in an internal, nated network. now i wanted to
backup a
client outside this network (directly connected), but i get this from
amstatus:
bart.imos.net:/ 0 planner: [missing result for / in bart.imos.net
response]
bart.imos.net:/boot 0 planner: [missing
Hi
I have playing about with Sun's new filesystem ZFS.
One of the things I wanted to do was make sure I could get amanda to
backup zfs.
The way the backup utility works with zfs is based on snapshots. You can
either
do a full bakup of a filesystem or the difference between two snapshots.
The
I've just been caught out by something which is either
(a) a limitation of AMANDA and/or tar/dump;
(b) a bug.
In summary: when a directory is *renamed* the files underneath it are
not considered to have changed: this means that a non-level-0 backup
following the directory rename only backs up
On Wednesday, 08.03.2006 at 11:34 +, Dave Ewart wrote:
I've just been caught out by something which is either
(a) a limitation of AMANDA and/or tar/dump;
(b) a bug.
A follow-up, prompted by a reply from Paul, indicating that I had indeed
forgotten a couple of rather important bits of
On Wednesday 08 March 2006 06:50, Dave Ewart wrote:
On Wednesday, 08.03.2006 at 11:34 +, Dave Ewart wrote:
I've just been caught out by something which is either
(a) a limitation of AMANDA and/or tar/dump;
(b) a bug.
A follow-up, prompted by a reply from Paul, indicating that I had
On Wednesday, 08.03.2006 at 07:35 -0500, Gene Heskett wrote:
On the client being backed-up:
$ tar --version
tar (GNU tar) 1.14
We believe this version of tar is borked. Please get the older
1.13-19, 1.13-25, or the newer 1.15-1. For whatever reason, 1.14 was
only visible on gnu.org
On Wednesday 08 March 2006 06:34, Dave Ewart wrote:
In summary: when a directory is *renamed* the files underneath it are
not considered to have changed
Usually, I would say that this is a limitation of the UNIX filesystem. A
directory's modification time can change anytime you add or remove a
On Wednesday 08 March 2006 08:43, Dave Ewart wrote:
On Wednesday, 08.03.2006 at 07:35 -0500, Gene Heskett wrote:
On the client being backed-up:
$ tar --version
tar (GNU tar) 1.14
We believe this version of tar is borked. Please get the older
1.13-19, 1.13-25, or the newer 1.15-1. For
On Wed, Mar 08, 2006 at 10:02:43AM -0500, Gene Heskett enlightened us:
On Wednesday, 08.03.2006 at 07:35 -0500, Gene Heskett wrote:
On the client being backed-up:
$ tar --version
tar (GNU tar) 1.14
We believe this version of tar is borked. Please get the older
1.13-19, 1.13-25,
On Wednesday 08 March 2006 06:34, Dave Ewart wrote:
In summary: when a directory is *renamed* the files underneath it are
not considered to have changed
This does not appear to happen with CVS tar in listed-incremental mode. Please
try upgrading your tar and check if you still see this
On Wednesday 08 March 2006 10:17, Matt Hyclak wrote:
On Wed, Mar 08, 2006 at 10:02:43AM -0500, Gene Heskett enlightened us:
On Wednesday, 08.03.2006 at 07:35 -0500, Gene Heskett wrote:
On the client being backed-up:
$ tar --version
tar (GNU tar) 1.14
We believe this version of tar
On Wed, Mar 08, 2006 at 10:31:44AM -0500, Gene Heskett enlightened us:
I hope you build your own RPMs, since I know you use an RPM based
system ;-)
Nope, I use checkinstall for some stuff, but this isn't being done for
these. And they are pinned in yum.conf. Yeah, my systems borked.
On Wednesday, 08.03.2006 at 10:02 -0500, Gene Heskett wrote:
This package of 'tar' is the current default in Debian/Sarge and is
updated with various security issues without changing the version
number, so it's not entirely clear what version is really there under
the hood.
Which is
On Wednesday, 08.03.2006 at 10:27 -0500, Ian Turner wrote:
On Wednesday 08 March 2006 06:34, Dave Ewart wrote:
In summary: when a directory is *renamed* the files underneath it are
not considered to have changed
This does not appear to happen with CVS tar in listed-incremental mode.
On Wed, Mar 08, 2006 at 04:21:42PM +, Dave Ewart wrote:
On Wednesday, 08.03.2006 at 10:27 -0500, Ian Turner wrote:
This does not appear to happen with CVS tar in listed-incremental mode.
Please
try upgrading your tar and check if you still see this behaviour.
OK, you've hit
--On March 8, 2006 11:34:16 AM + Dave Ewart [EMAIL PROTECTED] wrote:
Thoughts/opinions here? BTW the AMANDA server runs Debian/Woody
(2.4.2p2-4) and the client being backed up above runs Debian/Sarge AMD64
(2.4.4p3-3).
It could very well be b -- if it is it's not amanda, it's tar.
Hi Anthony,
Thanks for providing ufsdump wrapper to handle ZFS. When Application
API (http://wiki.zmanda.com/index.php/Application_API) is implemented
(hopefully
in the next Amanda release after 2.5), creating application plugin for snapshot
based filesystem such as ZFS will be easier. Issue 1
17 matches
Mail list logo
