Re: amsamba and NTFS permissions
Am 25.09.2014 um 17:21 schrieb Stefan G. Weichinger: > > Additional info: > > they can't use the A/ZManda-Windows-Client because the NTFS-share is > shared from a storage/SAN and not from a dedicated MS Windows Server. > > So we have to solve that on the side of the linux server, I assume. Does nobody here successfully do that with amanda?
Re: amsamba and NTFS permissions
"Stefan G. Weichinger" writes: > Am 25.09.2014 um 17:21 schrieb Stefan G. Weichinger: >> >> Additional info: >> >> they can't use the A/ZManda-Windows-Client because the NTFS-share is >> shared from a storage/SAN and not from a dedicated MS Windows Server. >> >> So we have to solve that on the side of the linux server, I assume. > > Does nobody here successfully do that with amanda? You supposedly could run A/ZManda-Windows-Client on a Windows client (one that remotely mounts the NTFS share). It will have a cost because the files are traveling the network twice (from NTFS server to Windows client and from Windows client to Amanda server). Your Windows client could be some virtual machine that is started only for back-up purposes (a virtualbox running from Amanda server, so you "cut off" one network transfer). That is ugly. It depends what is the NAS/storage amde of. Best regards, Olivier --
Re: Question about backing up a MS-Windows VM (NFTS file system)
On Mon, Sep 29, 2014 at 03:51:43PM +, Joi L. Ellis wrote: > I've got some systems in a similar situation, and I usually don't bother > backing up from the guest's filesystem directly. I have a cron job that > makes an LVM snapshot of the disk image and uses 'dd' to do make a bit image > of the entire filesystem into a .img file, and then I have Amanda back up the > .img file. Afterwards the LVM snapshot is deleted. That way I don't have to > deal with registry, acls and other windows black magic inside the file > system, I have an image of the entire disk I can dd back into the LVM volume > if it is ever needed. > > That said, If your windows-specific java app (what a moronic thing to > create...) only writes simple files that don't have further hooks into > windows, you may well do fine with a gnu tar copy of them. I've never had > much luck at that level. > > On the other hand, I do have Amanda backing up a windows XP box using > Cygwin's Amanda client and cygwin's gnu tar, and it does work, albeit very > slowly. (Ancient 32-bit XP machine with a huge hard drive in it.) > Everything I care about it is in the Cygwin section of the filesystem and > none of that has windows hooks I need to worry about. I have a DLE > configured to read /cygdrive/c/users/jlellis, which is the Cygwin-version of > C:/Users/Jlellis, my home directory under windows. > > The dd of the disk image is a lot faster than the Cygwin/amanda client/Cygwin > gnu tar, for what it's worth. > Joi, Have you ever tried a restore by the dd back to LVM method? Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (609) 477-8330 (C)
Barcode mismatches
I’ve used amanda with virtual tapes successfully for years. I’m now attempting
to add a physical tape library for the first time, a StorageTek SL150 with two
LTO6 drives. After I have confidence in the configuration and some testing,
the first few actual, scheduled dumps run fine. But around the 4th or 5th
regularly scheduled dump, I consistently get errors about barcode mismatches
with tape labels.
I label tapes using commands like this:
amlabel -f --barcode CA0014 Weekly1-library1 Weekly1-library1-CA0014
First, is there documentation to define specific definitions for LTO6 and or
StorageTek libraries? The only source I’ve found is this, but these devices
are absent.
http://wiki.zmanda.com/index.php/Tapetype_definitions
Absent that, does anyone have any advice about how to avoid
delayed/intermittent barcode mismatch problems? Here’s a typical example of
the error:
ERROR: Slot 16, label 'Weekly1-library1-CA0014', mismatch barcode between
changer 'CA0017' and tapelist file 'CA0014'
Server check took 245.881 seconds
amanda.conf file includes:
define changer sl150-robot {
tapedev "chg-robot:/dev/changer" #tape/by-id/scsi-3500104f000d21512"
property "tape-device" "0=tape:/dev/nst0" "1=tape:/dev/nst1”
length 2442818848 kbytes
filemark 1806 kbytes
speed 74006 kps
blocksize 32 kbytes
}
labelstr "Weekly1-library1-CA00[0-9][0-9]"
amrecover_changer "sl150-robot"
tapedev "sl150-robot"
tapetype LTO6
Re: Barcode mismatches
Which version of amanda are you using?
Are you sure the tape-device property is correctly set?
try: amtape Weekly1-library1 verify
Jean-Louis
On 10/02/2014 03:29 PM, Mike Driscoll wrote:
I’ve used amanda with virtual tapes successfully for years. I’m now attempting
to add a physical tape library for the first time, a StorageTek SL150 with two
LTO6 drives. After I have confidence in the configuration and some testing,
the first few actual, scheduled dumps run fine. But around the 4th or 5th
regularly scheduled dump, I consistently get errors about barcode mismatches
with tape labels.
I label tapes using commands like this:
amlabel -f --barcode CA0014 Weekly1-library1 Weekly1-library1-CA0014
First, is there documentation to define specific definitions for LTO6 and or
StorageTek libraries? The only source I’ve found is this, but these devices
are absent.
http://wiki.zmanda.com/index.php/Tapetype_definitions
Absent that, does anyone have any advice about how to avoid
delayed/intermittent barcode mismatch problems? Here’s a typical example of
the error:
ERROR: Slot 16, label 'Weekly1-library1-CA0014', mismatch barcode between
changer 'CA0017' and tapelist file 'CA0014'
Server check took 245.881 seconds
amanda.conf file includes:
define changer sl150-robot {
tapedev "chg-robot:/dev/changer" #tape/by-id/scsi-3500104f000d21512"
property "tape-device" "0=tape:/dev/nst0" "1=tape:/dev/nst1”
length 2442818848 kbytes
filemark 1806 kbytes
speed 74006 kps
blocksize 32 kbytes
}
labelstr "Weekly1-library1-CA00[0-9][0-9]"
amrecover_changer "sl150-robot"
tapedev "sl150-robot"
tapetype LTO6
Re: Barcode mismatches
Hi Jean-Louis. I am using version 3.3.6. I am confident that tape-device is
correct insofar as I can complete multiple, successful dumps before the
mismatches begin.
amtape verify looks good…
$ amtape Weekly1-library1 verify
GOOD : Drive 0 is device tape:/dev/nst0
GOOD : Drive 1 is device tape:/dev/nst1
property "TAPE-DEVICE" "0=tape:/dev/nst0" "1=tape:/dev/nst1"
On Oct 2, 2014, at 12:50, Jean-Louis Martineau wrote:
> Which version of amanda are you using?
>
> Are you sure the tape-device property is correctly set?
> try: amtape Weekly1-library1 verify
>
> Jean-Louis
>
> On 10/02/2014 03:29 PM, Mike Driscoll wrote:
>> I’ve used amanda with virtual tapes successfully for years. I’m now
>> attempting to add a physical tape library for the first time, a StorageTek
>> SL150 with two LTO6 drives. After I have confidence in the configuration
>> and some testing, the first few actual, scheduled dumps run fine. But
>> around the 4th or 5th regularly scheduled dump, I consistently get errors
>> about barcode mismatches with tape labels.
>>
>> I label tapes using commands like this:
>> amlabel -f --barcode CA0014 Weekly1-library1 Weekly1-library1-CA0014
>>
>>
>> First, is there documentation to define specific definitions for LTO6 and or
>> StorageTek libraries? The only source I’ve found is this, but these devices
>> are absent.
>> http://wiki.zmanda.com/index.php/Tapetype_definitions
>>
>>
>> Absent that, does anyone have any advice about how to avoid
>> delayed/intermittent barcode mismatch problems? Here’s a typical example of
>> the error:
>>
>> ERROR: Slot 16, label 'Weekly1-library1-CA0014', mismatch barcode between
>> changer 'CA0017' and tapelist file 'CA0014'
>> Server check took 245.881 seconds
>>
>> amanda.conf file includes:
>>
>> define changer sl150-robot {
>> tapedev "chg-robot:/dev/changer"
>> #tape/by-id/scsi-3500104f000d21512"
>> property "tape-device" "0=tape:/dev/nst0" "1=tape:/dev/nst1”
>> length 2442818848 kbytes
>> filemark 1806 kbytes
>> speed 74006 kps
>> blocksize 32 kbytes
>> }
>> labelstr "Weekly1-library1-CA00[0-9][0-9]"
>> amrecover_changer "sl150-robot"
>> tapedev "sl150-robot"
>> tapetype LTO6
>
