Hi,
I've experienced strange filenames in Amanda's index like filename
(offset 16769536) in addition to filename for files on Linux XFS
using xfsdump-1.0.9.
The index is generated by client-src/sendbackup-dump.c:
program-backup_name = XFSDUMP;
program-restore_name =
I've experienced strange filenames in Amanda's index like filename
(offset 16769536) in addition to filename for files on Linux XFS
using xfsdump-1.0.9.
...
What's that offset about?
You're asking the wrong folks. Amanda only run xfs for you. If it's
throwing crap around (which appears to be
You're asking the wrong folks. Amanda only run xfs for you. If it's
throwing crap around (which appears to be the case), you need to ask
the xfsdump/xfsrestore folks.
I know Amanda is just my beloved, best-ever-seen and you-made-my-day
wrapper around dump/backup/xfsdump/tar...
But maybe the
It looks like xfsdump will break large files into chunks in the
dump archive. This has more to do with not splitting a record
in the dump archive between tape media than anything else I think.
It is also possible for an interrupted dump to be restored, and
really big files would tend to be a
Is this actually causing problems, or is it just a query as to why
you see the odd names?
Just being curious... I haven't recognized any problems yet. It just
causes an annoying listing of mangled filenames in addition to the
original filename in the index, my SysOps will ask me How can we
Is this actually causing problems, or is it just a query as to why
you see the odd names?
Just being curious... I haven't recognized any problems yet. It just
causes an annoying listing of mangled filenames in addition to the
original filename in the index, my SysOps will ask me How can
Are you using real tape media, or a file, I suspect the file case could
be smart enough not to do the split as it does not make a whole lot
of sense there.
Amanda triggers xfsdump to write to stdout while splitting it to go to
tape or a file on the holding disk (via network) and to xfsrestore
