Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-11-10 um 17:13 schrieb Stefan G. Weichinger:

Am 2017-11-10 um 16:00 schrieb Stefan G. Weichinger:


I start with a taper.debug with debug-level 3:


Do I have to provide more debug-files?
amanda.conf or parts of it (the storage defs were in an earlier mail
today and I don't want to flood the list)?

I have to leave in a few minutes and will check back in a few hours, I
assume.


no hints on this?
I should flush these DLEs over the weekend ...

right now I get for amcheck:



$ amcheck daily
Amanda Tape Server Host Check
-
NOTE: Holding disk '/mnt/backup/amhold/daily': 5806 GB disk space 
available, using 5756 GB

slot 1: volume 'ARC865'
Will write to volume 'ARC865' in slot 1.
NOTE: skipping tape-writable test
ERROR: reservation belongs to another instance
Server check took 104.132 seconds
(brought to you by Amanda 3.5)

what can I do about this?

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-11-10 um 16:00 schrieb Stefan G. Weichinger:
> 
> I start with a taper.debug with debug-level 3:

Do I have to provide more debug-files?
amanda.conf or parts of it (the storage defs were in an earlier mail
today and I don't want to flood the list)?

I have to leave in a few minutes and will check back in a few hours, I
assume.

Thanks so far

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

I start with a taper.debug with debug-level 3:

taper: pid 27077 ruid 87 euid 87 version 3.5: start at Fri Nov 10
15:30:49 2017
 taper: Arguments: daily --storage archive --log-filename
/var/lib/amanda/daily/log.20171110153047.0
 taper: reading config file /etc/amanda/daily/amanda.conf
 taper: pid 27077 ruid 87 euid 87 version 3.5: rename at Fri Nov 10
15:30:49 2017
 taper: chg-robot: using statefile
'/var/spool/amanda/amanda/chg-robot-dev-sg3'
 taper: event: loop: enter: nonblockg=0, eh=(nil)
 taper: taper/driver << START-TAPER taper0 worker0-0 archive 20171110153047
 taper: Amanda::Taper::Scribe: starting
 taper: Amanda::Taper::Scan::traditional stage 1: search for oldest
reusable volume
 taper: Amanda::Taper::Scan::traditional oldest reusable volume is 'CMR908'
 taper: Amanda::Taper::Scan::traditional stage 1: searching oldest
reusable volume 'CMR908'
 taper: invoking /usr/sbin/mtx -f /dev/sg3 status
 taper: mtx:   Storage Changer /dev/sg3:1 Drives, 8 Slots ( 0
Import/Export )
 taper: mtx: Data Transfer Element 0:Full (Storage Element 3
Loaded):VolumeTag = CMR863L6
 taper: mtx:   Storage Element 1:Full :VolumeTag=CMR865L6
 taper: mtx:   Storage Element 2:Full :VolumeTag=CMR867L6
 taper: mtx:   Storage Element 3:Empty
 taper: mtx:   Storage Element 4:Full :VolumeTag=CMR864L6
 taper: mtx:   Storage Element 5:Full :VolumeTag=CMR866L6
 taper: mtx:   Storage Element 6:Empty
 taper: mtx:   Storage Element 7:Empty
 taper: mtx:   Storage Element 8:Empty
 taper: robot: updating state
 taper: robot: loading label 'CMR908'
 taper: new Amanda::Changer::Error: type='failed', reason='notfound',
message='label 'CMR908' not recognized or not found'
 taper: label 'CMR908' not recognized or not found
 taper: Amanda::Taper::Scan::traditional oldest reusable volume not found
 taper: Amanda::Taper::Scan::traditional stage 2: scan for any reusable
volume
 taper: robot: too early for another 'status' invocation
 taper: robot: requested volume is already in drive 0
 taper: robot: polling 'tape:/dev/nst0' to see if it's ready
 taper: Device is in variable block size
 taper: robot: setting current slot to 3
 taper: Slot 3 with label ARC863 is usable
 taper: Amanda::Taper::Scan::traditional result: 'ARC863' on
tape:/dev/nst0 slot 3, mode 2
 taper: taper/driver >> TAPER-OK worker0-0 ALLOW-TAKE-SCRIBE-FROM
 taper: taper/driver << CLOSE-VOLUME worker0-0
 taper: taper/driver >> CLOSED-VOLUME worker0-0
 taper: taper/driver << QUIT
 taper: Amanda::Taper::Scribe: quitting
 taper: robot: too early for another 'status' invocation
 taper: ru_utime   : 0
 taper: ru_stime   : 0
 taper: ru_maxrss  : 37676
 taper: ru_ixrss   : 0
 taper: ru_idrss   : 0
 taper: ru_isrss   : 0
 taper: ru_minflt  : 8241
 taper: ru_majflt  : 2
 taper: ru_nswap   : 0
 taper: ru_inblock : 32
 taper: ru_oublock : 48
 taper: ru_msgsnd  : 0
 taper: ru_msgrcv  : 0
 taper: ru_nsignals: 0
 taper: ru_nvcsw   : 17
 taper: ru_nivcsw  : 4
 taper: pid 27077 finish time Fri Nov 10 15:30:49 2017


plus the amflush.debug:

 amflush: pid 27074 ruid 87 euid 87 version 3.5: start at Fri Nov 10
15:30:47 2017
 amflush: Arguments: daily samba.gigabit.net veeam_backup windows_vss
smb-Einkauf smb-Homes smb-Leitungsteam smb-Marketing smb-Messprotokolle
 amflush: reading config file /etc/amanda/daily/amanda.conf
 amflush: pid 27074 ruid 87 euid 87 version 3.5: rename at Fri Nov 10
15:30:47 2017
 amflush: beginning trace log: /var/lib/amanda/daily/log.20171110153047.0
 amflush: beginning amdump log
 amflush:
/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/Amflush.pm:102:info:226
The timestamp is '20171110153047'
 amflush:
/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/Amflush.pm:108:info:221
The amdump trace file is '/var/lib/amanda/daily/amdump.20171110153047'
 amflush:
/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/Amflush.pm:114:info:220
The log file is '/var/lib/amanda/daily/log.20171110153047.0'
 amflush:  driver: 27076
 amflush: exec: /usr/libexec/amanda/driver daily nodump --no-vault
--log-filename /var/lib/amanda/daily/log.20171110153047.0
 amflush: flushing
/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.smb-Einkauf.0

[..]

 amflush: driver finished with exit code 0
 amflush: running amreport
 amflush: Running /usr/sbin/amreport daily --from-amdump -l
/var/lib/amanda/daily/log.20171110153047.0
 amflush: /usr/sbin/amreport exited with code 0
 amflush: renaming amdump log and trimming old amdump logs (beyond
tapecycle+2)
 amflush: Amflush exiting with code 0
 amflush: exiting with code 0

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 10/11/17 09:14 AM, Stefan G. Weichinger wrote:

Am 2017-11-10 um 14:59 schrieb Jean-Louis Martineau:
> Stefan,
>
> Post all debug files and log generated while running amflush.

will try

that server doesn't write debugfiles now, I raised the debug-*
parameters in amanda.conf but can't find the related files.

You should find them in `amgetconf build.amanda_dbgdir`



I don't remember, is that a configure-flag?

--

# file amdump (even when I ran amflush ...):

amflush: start at Fri Nov 10 15:08:20 CET 2017
amflush: datestamp 20171110
amflush: starttime 20171110150820
amflush: starttime-locale-independent 2017-11-10 15:08:20 CET
FLUSH 519;daily samba.gigabit.net 
 
smb-Einkauf 20171108204306 0

/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.smb-Einkauf.0
FLUSH 501;daily samba.gigabit.net 
 
smb-Homes 20171108204306 0

/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.smb-Homes.0
FLUSH 521;daily samba.gigabit.net 
 
smb-Leitungsteam 20171108204306 0

/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.smb-Leitungsteam.0
FLUSH 502;daily samba.gigabit.net 
 
smb-Marketing 20171108204306 0

/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.smb-Marketing.0
FLUSH 504;daily samba.gigabit.net 
 
smb-Messprotokolle 20171108204306 0

/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.smb-Messprotokolle.0
FLUSH 518;daily samba.gigabit.net 
 
veeam_backup 20171108204306 0

/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.veeam_backup.0
FLUSH 512;daily samba.gigabit.net 
 
windows_vss 20171108204306 0

/mnt/backup/amhold/daily/20171108204306/samba.gigabit.net.windows_vss.0
FLUSH 532;daily samba.gigabit.net 
 
smb-Einkauf 20171109225002 1

/mnt/backup/amhold/daily/20171109225002/samba.gigabit.net.smb-Einkauf.1
FLUSH 526;daily samba.gigabit.net 
 
smb-Homes 20171109225002 0

/mnt/backup/amhold/daily/20171109225002/samba.gigabit.net.smb-Homes.0
FLUSH 535;daily samba.gigabit.net 
 
smb-Leitungsteam 20171109225002 1

/mnt/backup/amhold/daily/20171109225002/samba.gigabit.net.smb-Leitungsteam.1
FLUSH 527;daily samba.gigabit.net 
 
smb-Marketing 20171109225002 0

/mnt/backup/amhold/daily/20171109225002/samba.gigabit.net.smb-Marketing.0
FLUSH 529;daily samba.gigabit.net 
 
smb-Messprotokolle 20171109225002 0

/mnt/backup/amhold/daily/20171109225002/samba.gigabit.net.smb-Messprotokolle.0
ENDFLUSH
driver: pid 26839 executable /usr/libexec/amanda/driver version 3.5
driver: adding holding disk 0 dir /mnt/backup/amhold/daily size
8843993088 chunksize 10485760
reserving 0 out of 8843993088 for degraded-mode dumps
driver: taper taper0 storage archive tape_size 2442818848
driver: send-cmd time 0.044 to taper0: START-TAPER taper0 worker0-0
archive 20171110150820
driver: start time 0.044 inparallel 4 bandwidth 9 diskspace
8843993088 dir OBSOLETE datestamp 20171110150820 driver: drain-ends
tapeq LARGESTFIT big-dumpers BTBT
driver: state time 0.044 free kps: 9 space: 8843993088 taper: idle
idle-dumpers: 4 qlen tapeq taper0: 0:0 runq: 0 directq: 0 roomq: 0
wakeup: 0 driver-idle: not-idle
driver: interface-state time 0.044 if default: free 9
driver: hdisk-state time 0.044 hdisk 0: free 8843993088 dumpers 0
driver: state time 0.468 free kps: 9 space: 8843993088 taper: idle
idle-dumpers: 4 qlen tapeq taper0: 0:0 runq: 0 directq: 0 roomq: 0
wakeup: 0 driver-idle: not-idle
driver: interface-state time 0.468 if default: free 9
driver: hdisk-state time 0.468 hdisk 0: free 8843993088 dumpers 0
driver: result time 0.468 from taper0: TAPER-OK worker0-0
ALLOW-TAKE-SCRIBE-FROM
driver: state time 0.469 free kps: 9 space: 8843993088 taper: idle
idle-dumpers: 4 qlen tapeq taper0: 0:0 runq: 0 directq: 0 roomq: 0
wakeup: 0 driver-idle: no-dumpers
driver: interface-state time 0.469 if default: free 9
driver: hdisk-state time 0.469 hdisk 0: free 8843993088 dumpers 0
driver: state time 0.469 free kps: 9 space: 8843993088 taper: idle
idle-dumpers: 4 qlen tapeq taper0: 0:0 runq: 0 directq: 0 roomq: 0
wakeup: 0 driver-idle: no-dumpers
driver: interface-state time 0.469 if default: free 9
driver: hdisk-state time 0.469 hdisk 0: free 8843993088 dumpers 0
Move runq to directq
driver: state time 0.469 free kps: 9 space: 8843993088 taper: idle
idle-dumpers: 4 qlen tapeq taper0: 0:0 runq: 0 directq: 0 roomq: 0
wakeup: 0 driver-idle: no-dumpers
driver: interface-state time 0.469 if default: free 9
driver: hdisk-state time 0.469 hdisk 0: free 8843993088 dumpers 0
driver: state time 0.469 free kps: 9 space: 8843993088 taper: idle
idle-dumpers: 4 qlen tapeq taper0: 0:0 runq: 0 directq: 0 roomq: 0
wakeup: 0 driver-idle: no-dumpers
driver: interface-state time 0.469 if 

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

Stefan,

Post all debug files and log generated while running amflush.

Jean-Louis

On 10/11/17 08:45 AM, Stefan G. Weichinger wrote:

Am 2017-11-08 um 18:57 schrieb Jean-Louis Martineau:

On 28/10/17 12:37 PM, Stefan G. Weichinger wrote:

Is it possible to amflush dumps from holdingdisk to tape while keeping
the dump files in the holdingdisk (for flushing them to a second set of
tapes later or just restore purposes) ?



It's not possible to flush them again.

Keeping them for restore: no, but it is a good idea for future feature.

OK. I try:

2 storages in one config:


define storage daily {
 tapepool "daily"
 tapetype "LTO6"
 tpchanger "robot"
 #labelstr "^CMR[0-9][0-9]*$"# label constraint regex: all
tapes must match
 autolabel "CMR%b"   # label constraint regex: all tapes must
match
 autoflush   no
 flush-threshold-dumped  500 # (or more)
 flush-threshold-scheduled   500 # (or more)
 taperflush  500
 runtapes 4  # number of tapes to be used in
a single run of amdump
}

define storage archive {
 tapepool "archive"
 tapetype "LTO6"
 tpchanger "robot"
 #labelstr "^ARC[0-9][0-9]*$"# label constraint regex: all
tapes must match
 autolabel "ARC%b"   # label constraint regex: all tapes must
match
 runtapes 4  # number of tapes to be used in
a single run of amdump
 dump-selection ALL FULL
}


-

The ARC-tapes are WORM and should only get the lev0 dumps.

labelled tapes ... examples:

0 ARC866 reuse BARCODE:CMR866L6 BLOCKSIZE:32 POOL:archive
STORAGE:archive CONFIG:daily

20171023201805 CMR940 reuse BARCODE:CMR940L6 BLOCKSIZE:32 POOL:daily
STORAGE:daily CONFIG:daily

I ran amdump --no-taper in the last days to collect lev0 in holdingdisk,
now I want to write/amflush these dumps to the tapes in storage "archive".

amcheck is OK, but amflush fails.

amflush daily -o storage=archive

Is that related to the TAPE POOL or what?

The report mail isn't clearly telling me what the problem is, it simply
does not start flushing.

A line from amstatus:

samba.gigabit.net:veeam_backup   20171108204306 0  3149g (daily)
terminated while waiting for flushing

What does the (daily) mean here?

pls advise, I should do that archive run this weekend.
thanks

ps: amanda-3.5, btw


This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-11-08 um 18:57 schrieb Jean-Louis Martineau:
> On 28/10/17 12:37 PM, Stefan G. Weichinger wrote:
>> Is it possible to amflush dumps from holdingdisk to tape while keeping
>> the dump files in the holdingdisk (for flushing them to a second set of
>> tapes later or just restore purposes) ?
>>
>>
> It's not possible to flush them again.
> 
> Keeping them for restore: no, but it is a good idea for future feature.

OK. I try:

2 storages in one config:


define storage daily {
tapepool "daily"
tapetype "LTO6"
tpchanger "robot"
#labelstr "^CMR[0-9][0-9]*$"# label constraint regex: all
tapes must match
autolabel "CMR%b"   # label constraint regex: all tapes must
match
autoflush   no
flush-threshold-dumped  500 # (or more)
flush-threshold-scheduled   500 # (or more)
taperflush  500
runtapes 4  # number of tapes to be used in
a single run of amdump
}

define storage archive {
tapepool "archive"
tapetype "LTO6"
tpchanger "robot"
#labelstr "^ARC[0-9][0-9]*$"# label constraint regex: all
tapes must match
autolabel "ARC%b"   # label constraint regex: all tapes must
match
runtapes 4  # number of tapes to be used in
a single run of amdump
dump-selection ALL FULL
}


-

The ARC-tapes are WORM and should only get the lev0 dumps.

labelled tapes ... examples:

0 ARC866 reuse BARCODE:CMR866L6 BLOCKSIZE:32 POOL:archive
STORAGE:archive CONFIG:daily

20171023201805 CMR940 reuse BARCODE:CMR940L6 BLOCKSIZE:32 POOL:daily
STORAGE:daily CONFIG:daily

I ran amdump --no-taper in the last days to collect lev0 in holdingdisk,
now I want to write/amflush these dumps to the tapes in storage "archive".

amcheck is OK, but amflush fails.

amflush daily -o storage=archive

Is that related to the TAPE POOL or what?

The report mail isn't clearly telling me what the problem is, it simply
does not start flushing.

A line from amstatus:

samba.gigabit.net:veeam_backup   20171108204306 0  3149g (daily)
terminated while waiting for flushing

What does the (daily) mean here?

pls advise, I should do that archive run this weekend.
thanks

ps: amanda-3.5, btw

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 08/11/17 03:40 PM, Nathan Stratton Treadway wrote:
> On Wed, Nov 08, 2017 at 12:50:12 -0500, Jean-Louis Martineau wrote:
> > YES
>
> Great, thanks for confirming my understanding.
>
> A few clarifications:
> > >
> > > 2) the "without holding disk" scenario would involve:
> > > * no global "storage" parameter (or one listing a single storage)
> > It must list the main storage.
>
> Yes -- so either 1) an explicit "storage" line in the amanda.conf file
> listing just the main storage, or 2) no "storage" line in the file,
> which would result in the main storage being the auto-created one named
> the same as the config name, right?
right
>
>
> > >
> > > (Does having one of the two storages with no volume found drop the
> > > entire run into degraded mode?)
> > Good question, I think no (If I remember correctly)
>
> (In my quick testing [with both storages listed on the "storage" line],
> amdump *did* drop to degraded mode for the whole run when it couldn't
> find a volume in the "offsite" storage [though there was one for the
> main storage]; I didn't investigate carefully to see if there was a
> setting that could override that behavior.
Which make sense.
You could set the 'reserve' parameter to 0 if you have enough holding 
disk.With a small reserve, it still do full backup in degraded mode.

Jean-Louis
>
> On the other hand, in the "without holding disk" scenario, a missing
> "offsite" volume does not trigger degraded mode.)
>
> Nathan
>
> 
> Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
> Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ 
> 
> GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt 
>  
> ID: 1023D/ECFB6239
> Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Nathan Stratton Treadway]

On Wed, Nov 08, 2017 at 12:50:12 -0500, Jean-Louis Martineau wrote:
> YES

Great, thanks for confirming my understanding.

A few clarifications:
> >
> > 2) the "without holding disk" scenario would involve:
> > * no global "storage" parameter (or one listing a single storage)
> It must list the main storage.

Yes -- so either 1) an explicit "storage" line in the amanda.conf file
listing just the main storage, or 2) no "storage" line in the file,
which would result in the main storage being the auto-created one named
the same as the config name, right?


> >
> > (Does having one of the two storages with no volume found drop the
> > entire run into degraded mode?)
> Good question, I think no (If I remember correctly)

(In my quick testing [with both storages listed on the "storage" line],
amdump *did* drop to degraded mode for the whole run when it couldn't
find a volume in the "offsite" storage [though there was one for the
main storage]; I didn't investigate carefully to see if there was a
setting that could override that behavior.

On the other hand, in the "without holding disk" scenario, a missing
"offsite" volume does not trigger degraded mode.)

Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 28/10/17 12:37 PM, Stefan G. Weichinger wrote:

Is it possible to amflush dumps from holdingdisk to tape while keeping
the dump files in the holdingdisk (for flushing them to a second set of
tapes later or just restore purposes) ?



It's not possible to flush them again.

Keeping them for restore: no, but it is a good idea for future feature.


Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 04/11/17 09:55 PM, Nathan Stratton Treadway wrote:
> On Mon, Oct 16, 2017 at 09:20:16 -0400, Jean-Louis Martineau wrote:
> > Amanda 3.5 can do everything you want only by running the amdump 
> command.
> >
> > Using an holding disk:
> >
> > * You configure two storages
> > * All dumps go to the holding disk
> > * All dumps are copied to each storages, not necessarily at the same
> > time or in the same run.
> > * The dumps stay in holding until they are copied to both storages
> > * You can tell amanda that everything must go to both storage or only
> > some dle full/incr
> >
> > Without holding disk
> >
> > * You configure one storage telling it to automatically vault its
> > dumps to the vault-storage
> > * You configure one vault-storage
> > * All dumps are dumped to the storage then vaulted to the vault-storage
> > * The vault operation can be done later in the same run or in a
> > different run.
> > * All dumps must go to the storage, but you can vault only some dles
> > full/incr
>
> Jean-Louis, are the following correct summararies of how one would
> actually implement the two scenarios you describe above?
>
> 1) the "using a holding disk" scenario would involve:
> * listing both storages in the "storage" global parameter
> * no "vault-storage" line
> * no "vault" parameter in either storage definition
> * the "you can tell amanda that everything" part would be
> accomplished using the "dump-selection" parameter in each storage
> definition
YES
>
> 2) the "without holding disk" scenario would involve:
> * no global "storage" parameter (or one listing a single storage)
It must list the main storage.
> * the "vault" parameter would be found in the storage definition for
> that main storage
> * if you want to do the vaulting as part of the amdump run, the
> global "vault-storage" parameter would list the (single) vault storage
> * if you want to do the vaulting later, you would not have
> "vault-storage" defined (and would kick off the vaulting operation with
> amdump CONF BADHOST -ovault-storage="VAULT"
> )
> * the "you can vault only some dles full/incr" part would be
> accomplished using the "dump-selection" parameter in the vault
> storage definition
> * if a holding disk is defined, dumps stay there only until they are
> written to the main storage, after which they are deleted from the
> holding disk (and thus the vaulting step pulls dumps back off the
> storage to which they were previously written)
YES
>
>
>
> If I'm using vtapes (on internal drives) for my main storage, is there
> any downside to using the second scenario instead of the first?
This scenario can be better because it reduce the number of read/write 
to the server disk.
But it can also reduce the parallelism, so you should increase 
taper-parallel-write and also configure amanda so than it use more than 
one tape.
Setting 'max-dle-by-volume 1' and adding a lot of slots can achieve it.
>
> (I am already using a holding disk for the main dump, but it seems like
> using the second scenario would mean that if the vault storage isn't
> available during the run, I won't end up filling the holding disk with
> dumps that have already been written successfully to the main
> storage)
>
>
>
> Finally, a couple question about your statement "All dumps are copied to
> each storages, not necessarily at the same time or in the same run." (in
> the use-holding-disk scenario):
>
> * am I correct that amdump would always try to use both storages, and
> thus situation in which they would be written at different times is
> when an acceptable volume is not found when amdump starts?
They are never written at the same time! Each storage have different 
setting and speed.
They are written in the same run if the configuration allow and 
acceptable volumes are found.
>
> (Does having one of the two storages with no volume found drop the
> entire run into degraded mode?)
Good question, I think no (If I remember correctly)
>
> * Once that has happened, one would make the missing volume available
> and then use the "amflush" command to kick off the pending writes,
> right? (rather than "amdump CONF BADHOST" as used in the
> no-holding-disk scenario)
yes


Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Nathan Stratton Treadway]

On Mon, Oct 16, 2017 at 09:20:16 -0400, Jean-Louis Martineau wrote:
> Amanda 3.5 can do everything you want only by running the amdump command.
>
> Using an holding disk:
> 
>   * You configure two storages
>   * All dumps go to the holding disk
>   * All dumps are copied to each storages, not necessarily at the same
> time or in the same run.
>   * The dumps stay in holding until they are copied to both storages
>   * You can tell amanda that everything must go to both storage or only
> some dle full/incr
> 
> Without holding disk
> 
>   * You configure one storage telling it to automatically vault its
> dumps to the vault-storage
>   * You configure one vault-storage
>   * All dumps are dumped to the storage then vaulted to the vault-storage
>   * The vault operation can be done later in the same run or in a
> different run.
>   * All dumps must go to the storage, but you can vault only some dles
> full/incr

Jean-Louis, are the following correct summararies of how one would
actually implement the two scenarios you describe above?

1) the "using a holding disk" scenario would involve:
   * listing both storages in the "storage" global parameter
   * no "vault-storage" line
   * no "vault" parameter in either storage definition
   * the "you can tell amanda that everything" part would be
 accomplished using the "dump-selection" parameter in each storage
 definition

2) the "without holding disk" scenario would involve:
   * no global "storage" parameter (or one listing a single storage)
   * the "vault" parameter would be found in the storage definition for
 that main storage
   * if you want to do the vaulting as part of the amdump run, the
 global "vault-storage" parameter would list the (single) vault storage
   * if you want to do the vaulting later, you would not have
 "vault-storage" defined (and would kick off the vaulting operation with
 amdump CONF BADHOST -ovault-storage="VAULT" 
 ) 
   * the "you can vault only some dles full/incr" part would be
 accomplished using the "dump-selection" parameter in the vault 
 storage definition
   * if a holding disk is defined, dumps stay there only until they are
 written to the main storage, after which they are deleted from the
 holding disk (and thus the vaulting step pulls dumps back off the
 storage to which they were previously written)



If I'm using vtapes (on internal drives) for my main storage, is there
any downside to using the second scenario instead of the first?  

(I am already using a holding disk for the main dump, but it seems like
using the second scenario would mean that if the vault storage isn't
available during the run, I won't end up filling the holding disk with
dumps that have already been written successfully to the main
storage)



Finally, a couple question about your statement "All dumps are copied to
each storages, not necessarily at the same time or in the same run." (in
the use-holding-disk scenario):

  * am I correct that amdump would always try to use both storages, and
thus situation in which they would be written at different times is
when an acceptable volume is not found when amdump starts?

(Does having one of the two storages with no volume found drop the
entire run into degraded mode?)

  * Once that has happened, one would make the missing volume available
and then use the "amflush" command to kick off the pending writes,
right?  (rather than "amdump CONF BADHOST" as used in the
no-holding-disk scenario)


Thanks.

Nathan



Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: approaches to Amanda vaulting?

[Nathan Stratton Treadway]

On Mon, Oct 16, 2017 at 09:20:16 -0400, Jean-Louis Martineau wrote:
> Amanda 3.5 can do everything you want only by running the amdump command.
> 
> Using an holding disk:
> 
>   * You configure two storages
>   * All dumps go to the holding disk
>   * All dumps are copied to each storages, not necessarily at the same
> time or in the same run.
>   * The dumps stay in holding until they are copied to both storages
>   * You can tell amanda that everything must go to both storage or only
> some dle full/incr
> 

Am I understanding correctly that in order to have amdump schedule dumps
for copying to the vault (thus avoiding the need to run "amvault"
separately), I have to define a "vault" option for the main storage?

(In partiular, if my main storage is the implicitely-generated one named
after my config name, I still need have a "define storage" section for
it in order to include the "vault" option there?)


Also, is this summary correct?:

  1) the "vault" option on the main storage tells amdump the storage(s)
 which should automatically "get sent" copies of the dumps as they
 are written to the main storage

  2) the "dump-selection" option on the vault storage definition then
 controls which of those "main" dumps actually get written to that
 vault storage.

  3) the "vault-storage" option controls whether the dumps selected in
 step 2) are automatically written to the vault storage as part of
 the normal amdump run?

Thanks.

Nathan



Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Is it possible to amflush dumps from holdingdisk to tape while keeping
the dump files in the holdingdisk (for flushing them to a second set of
tapes later or just restore purposes) ?

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-25 um 12:56 schrieb Stefan G. Weichinger:

> All this is kind of non-intuitive, at least for me so far.

hello, anyone?

:-P

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-25 um 13:21 schrieb Stefan G. Weichinger:

> something around the taperscan ?
> 
> we have
> 
> # in storage def
> TAPERSCAN   "taper_lexical"

with traditional taperscan it works
although it is there for a reason, I think JLM told me to use "lexical" ?

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

now kind of a sidestep:

I loaded a tape of the "normal"/primary storage and wanted to amflush to it.

Received error in amcheck (with more than one tape):

ERROR: amcheck-device terminated with signal 11

this is a gentoo host, amanda-3.5, with perl-5.24.3

-

I tried this:

$ perl -d  /usr/libexec/amanda/amcheck-device myconf myconf

Loading DB routines from perl5db.pl version 1.49_05
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(/usr/libexec/amanda/amcheck-device:38):
38: Amanda::Util::setup_application("amcheck-device", "server",
$CONTEXT_CMDLINE, "amanda", "amanda");
  DB<1> c
Signal SEGV at
/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/Taper/Scan/lexical.pm line 102.

Amanda::Taper::Scan::lexical::analyze(Amanda::Taper::Scan::lexical=HASH(0x5637e23df700),
 ARRAY(0x5637e2176c80), HASH(0x5637e23df9b8)) called at 
/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/ScanInventory.pm line 274

Amanda::ScanInventory::__ANON__[/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/ScanInventory.pm:294]()
 called at /usr/lib64/perl5/vendor_perl/5.24.3/Amanda/MainLoop.pm line 820

Amanda::MainLoop::__ANON__[/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/MainLoop.pm:822](Amanda::MainLoop::Source=HASH(0x5637e0687838))
 called at /usr/lib64/perl5/vendor_perl/5.24.3/Amanda/MainLoop.pm line 791
eval {...} called at
/usr/lib64/perl5/vendor_perl/5.24.3/Amanda/MainLoop.pm line 791
Amanda::MainLoop::run() called at /usr/libexec/amanda/amcheck-device
line 325


--


something around the taperscan ?

we have

# in storage def
TAPERSCAN   "taper_lexical"

DEFINE TAPERSCAN taper_lexical {
  COMMENT "lexical"
  PLUGIN  "lexical"
}

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-25 um 08:41 schrieb Stefan G. Weichinger:
> Am 2017-10-24 um 21:09 schrieb Jean-Louis Martineau:
>> Stefan,
>>
>> can you try the attached patch?
> 
> Unfortunately not as quickly as usual, my test VM is based on debian and
> not gentoo, so a quick patch-and-rebuild isn't done as easily (never
> built debian pkgs).
> 
> Renaming the secondary storage to "second" works though. Funny that I
> hit that edge case right at first try ;-)

next questions:

$ /usr/sbin/amvault  --dry-run myconf --dest-storage=archive --fulls-only

lists dumps on tapes and dumps still in the holdingdisk.

With one tape-device only I can't copy from tape to tape, so I only want
the dumps in holdingdisk.

If I add for example "--src-timestamp  20171022101048" with a timestamp
of lev0 DLEs listed via

$ amadmin myconf holding list -l

no DLE is selected ...

-

can/should I use amflush to "copy" the DLEs in holdingdisk to
archive/vault-storage?

All this is kind of non-intuitive, at least for me so far.

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-24 um 21:09 schrieb Jean-Louis Martineau:
> Stefan,
> 
> can you try the attached patch?

Unfortunately not as quickly as usual, my test VM is based on debian and
not gentoo, so a quick patch-and-rebuild isn't done as easily (never
built debian pkgs).

Renaming the secondary storage to "second" works though. Funny that I
hit that edge case right at first try ;-)

Stefan

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

Stefan,

can you try the attached patch?

Jean-Louis

On 24/10/17 03:00 PM, Jean-Louis Martineau wrote:

On 24/10/17 02:45 PM, Jean-Louis Martineau wrote:

On 24/10/17 02:29 PM, Stefan G. Weichinger wrote:

Am 2017-10-24 um 20:25 schrieb Jean-Louis Martineau:


This is not what you want.
You want amlabel to do its operation on the vault storage.
amlabel operate on the first configured storage, so this is what you
must change.

$ amlabel -ostorage=vault daily vault01 slot 1

thanks, but now:

$ amlabel -ostorage=vault daily vault01 slot 1
argument 'vault': string expected
argument 'vault': string expected


I don't get it, can you try the following:

amlabel -ostorage='vault' daily vault01 slot 1
amlabel -ostorage="vault" daily vault01 slot 1
amlabel -ostorage='"vault"' daily vault01 slot 1


I found why it doesn't work with a 'vault' storage.
The same parser is used for the configuration files and the -o 
argument, but 'vault' is a reserved keyword in amanda, so you must 
pass a string to the parser


amlabel -ostorage='"vault"' daily vault01 slot 1


Jean-Louis


This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail
diff --git a/common-src/conffile.c b/common-src/conffile.c
index f8df190..bb670ce 100644
--- a/common-src/conffile.c
+++ b/common-src/conffile.c
@@ -4280,7 +4280,7 @@ read_storage_identlist(
 free_val_t(val);
 ckseen(&val->seen);
 val->v.identlist = NULL;
-get_conftoken(CONF_ANY);
+get_conftoken(CONF_IDENT);
 while (tok == CONF_STRING || tok == CONF_IDENT) {
 	val->v.identlist = g_slist_append(val->v.identlist,
 	  g_strdup(tokenval.v.s));

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 24/10/17 02:45 PM, Jean-Louis Martineau wrote:

On 24/10/17 02:29 PM, Stefan G. Weichinger wrote:

Am 2017-10-24 um 20:25 schrieb Jean-Louis Martineau:


This is not what you want.
You want amlabel to do its operation on the vault storage.
amlabel operate on the first configured storage, so this is what you
must change.

$ amlabel -ostorage=vault daily vault01 slot 1

thanks, but now:

$ amlabel -ostorage=vault daily vault01 slot 1
argument 'vault': string expected
argument 'vault': string expected


I don't get it, can you try the following:

amlabel -ostorage='vault' daily vault01 slot 1
amlabel -ostorage="vault" daily vault01 slot 1
amlabel -ostorage='"vault"' daily vault01 slot 1


I found why it doesn't work with a 'vault' storage.
The same parser is used for the configuration files and the -o argument, 
but 'vault' is a reserved keyword in amanda, so you must pass a string 
to the parser


amlabel -ostorage='"vault"' daily vault01 slot 1


Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 24/10/17 02:29 PM, Stefan G. Weichinger wrote:

Am 2017-10-24 um 20:25 schrieb Jean-Louis Martineau:


This is not what you want.
You want amlabel to do its operation on the vault storage.
amlabel operate on the first configured storage, so this is what you
must change.

$ amlabel -ostorage=vault daily vault01 slot 1

thanks, but now:

$ amlabel -ostorage=vault daily vault01 slot 1
argument 'vault': string expected
argument 'vault': string expected


I don't get it, can you try the following:

amlabel -ostorage='vault' daily vault01 slot 1
amlabel -ostorage="vault" daily vault01 slot 1
amlabel -ostorage='"vault"' daily vault01 slot 1
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 24/10/17 02:07 PM, Stefan G. Weichinger wrote:


I was able to label the vtapes in storage "daily" but can't figure out
why this command accesses changer "disk1" instead of "disk2" ->

$ /usr/sbin/amlabel  --storage vault --pool vault daily vault01 slot 1
Reading label...
Found label 'daily01' but it doesn't match the labelstr
'^daily[0-9][0-9]*$'.
Not writing label.
Not writing label.

tried several combinations of parameters etc ...

$ man amlabel
   --storage storage
   Assign the storage to the label, it can only be used with 
--assign,

   you can't assign a storage to a new labelled volume.

This is not what you want.
You want amlabel to do its operation on the vault storage.
amlabel operate on the first configured storage, so this is what you 
must change.


$ amlabel -ostorage=vault daily vault01 slot 1


Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-24 um 19:07 schrieb Austin S. Hemmelgarn:

> Based on what you're saying you want, I think you want the following in
> your config:
> 
>     flush-threshold-dumped 400
>     flush-threshold-scheduled 400
>     taperflush 400
>     autoflush yes
> 
> The first two control flushing during a run, while taperflush controls
> flushing at the end of a run.  To get the flushing to actually happen,
> you then need autoflush set to yes (and amanda will complain if it's not
> set to yes and taperflush is more than zero).
> 
> Now, I'm not 100% certain that will work, as I've not done this type of
> thing myself (at work, we just use the holding disk as a cache so that
> we can finish dumps as quickly as possible without our (slow,
> parity-raid backed) persistent storage being the bottleneck, and at home
> I don't use it since I don't need parallelization and I don't have any
> disks that are faster than any others), but based on what I understand
> from the documentation, I'm pretty sure this should do it.

thanks for the explanation, I have that setup there and just let the
normal amdump-cronjob run tonight. And see what happens.

The admin forgot to swap tapes, so degraded mode only anyway for now ;-)

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-24 um 18:28 schrieb Stefan G. Weichinger:
> Am 2017-10-24 um 13:38 schrieb Austin S. Hemmelgarn:
>> On 2017-10-22 13:38, Stefan G. Weichinger wrote:
>>> After or before I additionally can do something like:
>>>
>>> amvault myconf --dest-storage --latest-fulls archive
>>>
>>> correct?
>> I think so, but I'm not 100% certain.
> 
> oh ;-)
> 
>>> An additional hurdle is that the customer wants to use WORM tapes for
>>> archive, so I should get that right at the first run to not waste any
>>> tapes
> 
>> Perhaps create a temporary virtual tape library for testing that the
>> archiving schedule works as expected?  This is what I generally do
>> when testing changes at work (although I usually do it using a copy of
>> the main configuration so that I don't confuse the planner for the
>> production backups with half a dozen runs in one day).
> 
> Sure, that would be good, but I don't have that much disk space available.
> 
> I am currently trying to wrap my head around the tuning of these
> parameters (and understand the exact meaning by reading the man page):
> 
> flush-threshold-dumped
> flush-threshold-scheduled
> taperflush
> 
> I had lev0 of all DLEs in the holding disk and both flush-threshold
> values on 400 -> I thought this would keep data for 4 tapes inside the
> disk, but no, some lev0 backups were flushed to primary storage already.
> 
> Maybe I set up a VM with 2 vtape changers and play around there to learn
> and understand.

did that and created a basic config with 2 chg-disk changers:

DEFINE CHANGER disk1 {
  COMMENT ""
  TAPEDEV ""
  TPCHANGER   "chg-disk:/mnt/disk1"
  CHANGERDEV  ""
  CHANGERFILE ""
  PROPERTY"removable" "no"
  PROPERTY"umount" "no"
  PROPERTY"num-slot" "5"
  PROPERTY"auto-create-slot" "yes"
  PROPERTY"mount" "no"
}

DEFINE CHANGER disk2 {
  COMMENT ""
  TAPEDEV ""
  TPCHANGER   "chg-disk:/mnt/disk2"
  CHANGERDEV  ""
  CHANGERFILE ""
  PROPERTY"removable" "no"
  PROPERTY"umount" "no"
  PROPERTY"num-slot" "5"
  PROPERTY"auto-create-slot" "yes"
  PROPERTY"mount" "no"
}

DEFINE STORAGE daily {
  COMMENT ""
  POLICY  "daily"
  TAPEDEV ""
  TPCHANGER   "disk1"
  LABELSTR"^daily[0-9][0-9]*$"
  AUTOLABEL   ""
  META-AUTOLABEL  ""
  TAPEPOOL"daily"
  RUNTAPES1
  TAPERSCAN   "lexi"
  TAPETYPE"HARD-DISK"
  MAX-DLE-BY-VOLUME   10
  TAPERALGO   SMALLEST
  TAPER-PARALLEL-WRITE 1
  EJECT-VOLUMEno
  ERASE-VOLUMEno
  DEVICE-OUTPUT-BUFFER-SIZE 1310720
  AUTOFLUSH   yes
  FLUSH-THRESHOLD-DUMPED 0
  FLUSH-THRESHOLD-SCHEDULED 0
  TAPERFLUSH  0
  REPORT-USE-MEDIAyes
  REPORT-NEXT-MEDIA   yes
  INTERACTIVITY   ""
  SET-NO-REUSEno
  ERASE-ON-FAILUREno
  ERASE-ON-FULL   no
}

DEFINE STORAGE vault {
  COMMENT ""
  POLICY  "daily"
  TAPEDEV ""
  TPCHANGER   "disk2"
  LABELSTR"^vault[0-9][0-9]*$"
  AUTOLABEL   ""
  META-AUTOLABEL  ""
  TAPEPOOL"vault"
  RUNTAPES1
  TAPERSCAN   "lexi"
  TAPETYPE"HARD-DISK"
  MAX-DLE-BY-VOLUME   10
  TAPERALGO   SMALLEST
  TAPER-PARALLEL-WRITE 1
  EJECT-VOLUMEno
  ERASE-VOLUMEno
  DEVICE-OUTPUT-BUFFER-SIZE 1310720
  AUTOFLUSH   yes
  FLUSH-THRESHOLD-DUMPED 0
  FLUSH-THRESHOLD-SCHEDULED 0
  TAPERFLUSH  0
  REPORT-USE-MEDIAyes
  REPORT-NEXT-MEDIA   yes
  INTERACTIVITY   ""
  SET-NO-REUSEno
  ERASE-ON-FAILUREno
  ERASE-ON-FULL   no
}


-

I was able to label the vtapes in storage "daily" but can't figure out
why this command accesses changer "disk1" instead of "disk2" ->

$ /usr/sbin/amlabel  --storage vault --pool vault daily vault01 slot 1
Reading label...
Found label 'daily01' but it doesn't match the labelstr
'^daily[0-9][0-9]*$'.
Not writing label.
Not writing label.

tried several combinations of parameters etc ...

Re: approaches to Amanda vaulting?

[Austin S. Hemmelgarn]

On 2017-10-24 12:28, Stefan G. Weichinger wrote:

Am 2017-10-24 um 13:38 schrieb Austin S. Hemmelgarn:

On 2017-10-22 13:38, Stefan G. Weichinger wrote:

After or before I additionally can do something like:

amvault myconf --dest-storage --latest-fulls archive

correct?

I think so, but I'm not 100% certain.


oh ;-)


An additional hurdle is that the customer wants to use WORM tapes for
archive, so I should get that right at the first run to not waste any 
tapes


Perhaps create a temporary virtual tape library for testing that the 
archiving schedule works as expected?  This is what I generally do 
when testing changes at work (although I usually do it using a copy of 
the main configuration so that I don't confuse the planner for the 
production backups with half a dozen runs in one day).


Sure, that would be good, but I don't have that much disk space available.

I am currently trying to wrap my head around the tuning of these 
parameters (and understand the exact meaning by reading the man page):


flush-threshold-dumped
flush-threshold-scheduled
taperflush

I had lev0 of all DLEs in the holding disk and both flush-threshold 
values on 400 -> I thought this would keep data for 4 tapes inside the 
disk, but no, some lev0 backups were flushed to primary storage already.


Maybe I set up a VM with 2 vtape changers and play around there to learn 
and understand.
Based on what you're saying you want, I think you want the following in 
your config:


flush-threshold-dumped 400
flush-threshold-scheduled 400
taperflush 400
autoflush yes

The first two control flushing during a run, while taperflush controls 
flushing at the end of a run.  To get the flushing to actually happen, 
you then need autoflush set to yes (and amanda will complain if it's not 
set to yes and taperflush is more than zero).


Now, I'm not 100% certain that will work, as I've not done this type of 
thing myself (at work, we just use the holding disk as a cache so that 
we can finish dumps as quickly as possible without our (slow, 
parity-raid backed) persistent storage being the bottleneck, and at home 
I don't use it since I don't need parallelization and I don't have any 
disks that are faster than any others), but based on what I understand 
from the documentation, I'm pretty sure this should do it.

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-24 um 13:38 schrieb Austin S. Hemmelgarn:

On 2017-10-22 13:38, Stefan G. Weichinger wrote:

After or before I additionally can do something like:

amvault myconf --dest-storage --latest-fulls archive

correct?

I think so, but I'm not 100% certain.


oh ;-)


An additional hurdle is that the customer wants to use WORM tapes for
archive, so I should get that right at the first run to not waste any 
tapes


Perhaps create a temporary virtual tape library for testing that the 
archiving schedule works as expected?  This is what I generally do when 
testing changes at work (although I usually do it using a copy of the 
main configuration so that I don't confuse the planner for the 
production backups with half a dozen runs in one day).


Sure, that would be good, but I don't have that much disk space available.

I am currently trying to wrap my head around the tuning of these 
parameters (and understand the exact meaning by reading the man page):


flush-threshold-dumped
flush-threshold-scheduled
taperflush

I had lev0 of all DLEs in the holding disk and both flush-threshold 
values on 400 -> I thought this would keep data for 4 tapes inside the 
disk, but no, some lev0 backups were flushed to primary storage already.


Maybe I set up a VM with 2 vtape changers and play around there to learn 
and understand.


Stefan

Re: approaches to Amanda vaulting?

[Austin S. Hemmelgarn]

On 2017-10-22 13:38, Stefan G. Weichinger wrote:

Am 2017-10-16 um 19:22 schrieb Stefan G. Weichinger:

Am 2017-10-16 um 15:20 schrieb Jean-Louis Martineau:

Amanda 3.5 can do everything you want only by running the amdump command.

Using an holding disk:

* You configure two storages
* All dumps go to the holding disk
* All dumps are copied to each storages, not necessarily at the same
time or in the same run.
* The dumps stay in holding until they are copied to both storages
* You can tell amanda that everything must go to both storage or only
some dle full/incr



I now have set up a config like this:


define changer robot {
 tpchanger "chg-robot:/dev/sg3"
 property "tape-device" "0=tape:/dev/nst0"
 property "eject-before-unload" "no"
 property "use-slots" "1-8"
}

define tapetype LTO6 {
#comment "Created by amtapetype; compression enabled"
length 2442818848 kbytes # etwa 2.4 TB (sgw)
filemark 1806 kbytes
speed 74006 kps
blocksize 32 kbytes
part_size 200G
}

define storage myconf {
 tapepool "myconf"
 tapetype "LTO6"
 tpchanger "robot"
 labelstr "^CMR[0-9][0-9]*$"
 autoflush   yes
#   flush-threshold-dumped 100
#   flush-threshold-scheduled 100
#
#   lass alles in holding disk
  flush-threshold-dumped 400 # (or more)
  flush-threshold-scheduled  400 # (or more)
  taperflush 400
 runtapes 4
}

define storage archive {
 tapepool "archive"
 tapetype "LTO6"
 tpchanger "robot"
 labelstr "^ARC[0-9][0-9]*$"
 autoflush   yes
 flush-threshold-dumped 100
 flush-threshold-scheduled 100
 runtapes 4
 dump-selection ALL FULL
}

storage "myconf"
maxdumpsize -1
amrecover_changer "robot"


> 8<

my goal:

I have to create a set of archive tapes for that customer, every 3
months or so.

With the above setup I now ran "amdump --no-taper myconf" which
collected all dumps on holdingdisk (did an "amadmin myconf force *"
before to force FULLs now).

As I understand that I could now do a plain amflush which should

(a) write to the tapes of tapepool "myconf" and

(b) leave the holdingdisk tarballs where they are, right?

(I am not yet sure about that "400" above, I want to keep data for all 4
tapes in the holdingdisk now and may reduce that to 100 for normal daily
runs without "--no-taper" or so)

After or before I additionally can do something like:

amvault myconf --dest-storage --latest-fulls archive

correct?

I think so, but I'm not 100% certain.


An additional hurdle is that the customer wants to use WORM tapes for
archive, so I should get that right at the first run to not waste any tapesPerhaps create a temporary virtual tape library for testing that the 
archiving schedule works as expected?  This is what I generally do when 
testing changes at work (although I usually do it using a copy of the 
main configuration so that I don't confuse the planner for the 
production backups with half a dozen runs in one day).

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-16 um 19:22 schrieb Stefan G. Weichinger:
> Am 2017-10-16 um 15:20 schrieb Jean-Louis Martineau:
>> Amanda 3.5 can do everything you want only by running the amdump command.
>>
>> Using an holding disk:
>>
>> * You configure two storages
>> * All dumps go to the holding disk
>> * All dumps are copied to each storages, not necessarily at the same
>> time or in the same run.
>> * The dumps stay in holding until they are copied to both storages
>> * You can tell amanda that everything must go to both storage or only
>> some dle full/incr


I now have set up a config like this:


define changer robot {
tpchanger "chg-robot:/dev/sg3"
property "tape-device" "0=tape:/dev/nst0"
property "eject-before-unload" "no"
property "use-slots" "1-8"
}

define tapetype LTO6 {
#comment "Created by amtapetype; compression enabled"
length 2442818848 kbytes # etwa 2.4 TB (sgw)
filemark 1806 kbytes
speed 74006 kps
blocksize 32 kbytes
part_size 200G
}

define storage myconf {
tapepool "myconf"
tapetype "LTO6"
tpchanger "robot"
labelstr "^CMR[0-9][0-9]*$"
autoflush   yes
#   flush-threshold-dumped 100
#   flush-threshold-scheduled 100
#
#   lass alles in holding disk
 flush-threshold-dumped 400 # (or more)
 flush-threshold-scheduled  400 # (or more)
 taperflush 400
runtapes 4
}

define storage archive {
tapepool "archive"
tapetype "LTO6"
tpchanger "robot"
labelstr "^ARC[0-9][0-9]*$"
autoflush   yes
flush-threshold-dumped 100
flush-threshold-scheduled 100
runtapes 4
dump-selection ALL FULL
}

storage "myconf"
maxdumpsize -1
amrecover_changer "robot"

-- 

my goal:

I have to create a set of archive tapes for that customer, every 3
months or so.

With the above setup I now ran "amdump --no-taper myconf" which
collected all dumps on holdingdisk (did an "amadmin myconf force *"
before to force FULLs now).

As I understand that I could now do a plain amflush which should

(a) write to the tapes of tapepool "myconf" and

(b) leave the holdingdisk tarballs where they are, right?

(I am not yet sure about that "400" above, I want to keep data for all 4
tapes in the holdingdisk now and may reduce that to 100 for normal daily
runs without "--no-taper" or so)

After or before I additionally can do something like:

amvault myconf --dest-storage --latest-fulls archive

correct?

An additional hurdle is that the customer wants to use WORM tapes for
archive, so I should get that right at the first run to not waste any tapes

thanks for any hints and suggestions,
Stefan

Re: approaches to Amanda vaulting?

[Austin S. Hemmelgarn]

On 2017-10-19 11:06, Jean-Louis Martineau wrote:

On 19/10/17 08:48 AM, Austin S. Hemmelgarn wrote:
 > On 2017-10-18 15:45, Stefan G. Weichinger wrote:
 >> Am 2017-10-16 um 20:47 schrieb Austin S. Hemmelgarn:
 >>
 >>> While it's not official documentation, I've got a working
 >>> configuration with
 >>> Amanda 3.5.0 on my personal systems, using locally accessible
 >>> storage for
 >>> primary backups, and S3 for vaulting (though I vault everything, the
 >>> local
 >>> storage is for getting old files back, S3 is for disaster
 >>> recovery). I've
 >>> put a copy of the relevant config fragment at the end of this reply,
 >>> with
 >>> various private data replaced, and some bits that aren't really
 >>> relevant
 >>> (like labeling options) elided.
 >>
 >> A quick thank you at this point:
 >>
 >> thanks for providing this config plus explanations, I will try to set up
 >> a similar config soon and take your example as a template.
 >>
 >> And maybe come back with some additional questions ;-)
 >>
 >> for example: what do you run as cronjobs, what do you do via manual
 >> commands? amdump in cron, amvault now and then?
 > Well, there's two options for how to handle it.
 >
 > Where I work, we use a very similar configuration to what I posted,
 > and run amdump and amvault independently, both through cron (though we
 > only vault full backups to S3 since we have a reasonably good level of
 > trust in the reliability of our local storage). This gives very good
 > control of exactly what and exactly when things get vaulted, and
 > allows for scheduling vaulting separately from dumps (we prefer to
 > only copy things out to S3 once a month and need to make sure the
 > network isn't bogged down with backups during work hours, so this is a
 > big plus for us).
The problem with the amvault command is that it do only according to the
command line, which can be difficult to get right.
If amvault fail, it's hard to find the correct arguments to vault what
was not yet vaulted.
With wrong arguments, some dump might never be vaulted, or some dumps
might be vaulted multiple time (on different amvault invocation).
To be entirely honest, I wouldn't exactly call `--latest-fulls`, 
`--fulls-only`, or `--incrs-only` hard to get right.  It's only really 
tricky if you want to only vault subsets of the config.  Add to that 
that it's pretty easy to see what got vaulted if you have e-mail set up 
right, and it really isn't too bad for most use cases.


Since you want to vault all full, I would set 'vault' in the local
storage, set 'dump-selection' in the cloud storage, but will not set
'vault-storage'
That way the vault are scheduled but are not executed because
vault-storage is not set. Amanda know they must be vaulted.
Every month, you can run: amdump CONF BADHOST -ovault-storage="cloud"
to do the vaulting.
We've actually been discussing migrating things to operate like I have 
them set up on my home systems (albeit only vaulting fulls), as the 
'once a month' part of vaulting is largely a hold-over from our old 
(pre-Amanda) backup system which did fulls on the first of the month, 
and archived them off-site the day afterwards.


 >
 > On my home systems, I also use a similar config, but I instead have a
 > 'vault' option specified in the 'local' storage block that points to
 > the 'cloud' and says to vault immediately after dump generation(so the
 > line is 'vault cloud 0'). With this setup, amdump will run the
 > vaulting operation itself after finishing everything else for the dump
 > (and you actually don't need the 'vault-storage' line at the end I
 > think), and you either end up vaulting everything, or have to limit
 > things through the config with a 'dump-selection' line in your 'cloud'
 > storage definition.
vault-storage is required, otherwise the vault are not executed.

Good to know, that could probably be better explained in the documentation.

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 19/10/17 08:48 AM, Austin S. Hemmelgarn wrote:

On 2017-10-18 15:45, Stefan G. Weichinger wrote:

Am 2017-10-16 um 20:47 schrieb Austin S. Hemmelgarn:

While it's not official documentation, I've got a working 
configuration with
Amanda 3.5.0 on my personal systems, using locally accessible 
storage for
primary backups, and S3 for vaulting (though I vault everything, the 
local
storage is for getting old files back, S3 is for disaster 
recovery).  I've
put a copy of the relevant config fragment at the end of this reply, 
with
various private data replaced, and some bits that aren't really 
relevant

(like labeling options) elided.


A quick thank you at this point:

thanks for providing this config plus explanations, I will try to set up
a similar config soon and take your example as a template.

And maybe come back with some additional questions ;-)

for example: what do you run as cronjobs, what do you do via manual
commands? amdump in cron, amvault now and then?

Well, there's two options for how to handle it.

Where I work, we use a very similar configuration to what I posted, 
and run amdump and amvault independently, both through cron (though we 
only vault full backups to S3 since we have a reasonably good level of 
trust in the reliability of our local storage).  This gives very good 
control of exactly what and exactly when things get vaulted, and 
allows for scheduling vaulting separately from dumps (we prefer to 
only copy things out to S3 once a month and need to make sure the 
network isn't bogged down with backups during work hours, so this is a 
big plus for us).
The problem with the amvault command is that it do only according to the 
command line, which can be difficult to get right.
If amvault fail, it's hard to find the correct arguments to vault what 
was not yet vaulted.
With wrong arguments, some dump might never be vaulted, or some dumps 
might be vaulted multiple time (on different amvault invocation).


Since you want to vault all full, I would set 'vault' in the local 
storage, set 'dump-selection' in the cloud storage, but will not set 
'vault-storage'
That way the vault are scheduled but are not executed because 
vault-storage is not set. Amanda know they must be vaulted.

Every month, you can run: amdump CONF BADHOST -ovault-storage="cloud"
to do the vaulting.



On my home systems, I also use a similar config, but I instead have a 
'vault' option specified in the 'local' storage block that points to 
the 'cloud' and says to vault immediately after dump generation(so the 
line is 'vault cloud 0').  With this setup, amdump will run the 
vaulting operation itself after finishing everything else for the dump 
(and you actually don't need the 'vault-storage' line at the end I 
think), and you either end up vaulting everything, or have to limit 
things through the config with a 'dump-selection' line in your 'cloud' 
storage definition.

vault-storage is required, otherwise the vault are not executed.

Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Austin S. Hemmelgarn]

On 2017-10-18 15:45, Stefan G. Weichinger wrote:

Am 2017-10-16 um 20:47 schrieb Austin S. Hemmelgarn:


While it's not official documentation, I've got a working configuration with
Amanda 3.5.0 on my personal systems, using locally accessible storage for
primary backups, and S3 for vaulting (though I vault everything, the local
storage is for getting old files back, S3 is for disaster recovery).  I've
put a copy of the relevant config fragment at the end of this reply, with
various private data replaced, and some bits that aren't really relevant
(like labeling options) elided.


A quick thank you at this point:

thanks for providing this config plus explanations, I will try to set up
a similar config soon and take your example as a template.

And maybe come back with some additional questions ;-)

for example: what do you run as cronjobs, what do you do via manual
commands? amdump in cron, amvault now and then?

Well, there's two options for how to handle it.

Where I work, we use a very similar configuration to what I posted, and 
run amdump and amvault independently, both through cron (though we only 
vault full backups to S3 since we have a reasonably good level of trust 
in the reliability of our local storage).  This gives very good control 
of exactly what and exactly when things get vaulted, and allows for 
scheduling vaulting separately from dumps (we prefer to only copy things 
out to S3 once a month and need to make sure the network isn't bogged 
down with backups during work hours, so this is a big plus for us).


On my home systems, I also use a similar config, but I instead have a 
'vault' option specified in the 'local' storage block that points to the 
'cloud' and says to vault immediately after dump generation(so the line 
is 'vault cloud 0').  With this setup, amdump will run the vaulting 
operation itself after finishing everything else for the dump (and you 
actually don't need the 'vault-storage' line at the end I think), and 
you either end up vaulting everything, or have to limit things through 
the config with a 'dump-selection' line in your 'cloud' storage definition.

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-16 um 20:47 schrieb Austin S. Hemmelgarn:

> While it's not official documentation, I've got a working configuration with
> Amanda 3.5.0 on my personal systems, using locally accessible storage for
> primary backups, and S3 for vaulting (though I vault everything, the local
> storage is for getting old files back, S3 is for disaster recovery).  I've
> put a copy of the relevant config fragment at the end of this reply, with
> various private data replaced, and some bits that aren't really relevant
> (like labeling options) elided.

A quick thank you at this point:

thanks for providing this config plus explanations, I will try to set up
a similar config soon and take your example as a template.

And maybe come back with some additional questions ;-)

for example: what do you run as cronjobs, what do you do via manual
commands? amdump in cron, amvault now and then?

Stefan

Re: approaches to Amanda vaulting?

[Austin S. Hemmelgarn]

On 2017-10-16 13:22, Stefan G. Weichinger wrote:
> Am 2017-10-16 um 15:20 schrieb Jean-Louis Martineau:
>> Amanda 3.5 can do everything you want only by running the amdump command.
>>
>> Using an holding disk:
>>
>> * You configure two storages
>> * All dumps go to the holding disk
>> * All dumps are copied to each storages, not necessarily at the same
>> time or in the same run.
>> * The dumps stay in holding until they are copied to both storages
>> * You can tell amanda that everything must go to both storage or only
>> some dle full/incr
> 
> 
> So it is possible to set up a mix of "normal" daily backups with
> incrementals/fulls and "archive"/vault backups with only the full
> backups of a specific day ?
> 
> I have requests to do so for a customer, until now we used amanda-3.3.9
> and 2 configs sharing most of config and disklist ...
> 
> Nathan, the OP of this thread and others (including me) would like to
> see actual examples of configuration, a howto or something.
> 
> The man page https://wiki.zmanda.com/man/amvault.8.html is a bit minimal
> ...
> 
> Is there anything additional to that manpage and maybe:
> 
> http://wiki.zmanda.com/index.php/How_To:Copy_Data_from_Volume_to_Volume
> 
> ?
While it's not official documentation, I've got a working configuration with
Amanda 3.5.0 on my personal systems, using locally accessible storage for
primary backups, and S3 for vaulting (though I vault everything, the local
storage is for getting old files back, S3 is for disaster recovery).  I've
put a copy of the relevant config fragment at the end of this reply, with
various private data replaced, and some bits that aren't really relevant
(like labeling options) elided.

For this to work reliably, you need to define a holding disk (although it
can be on the same storage as the local vtape library).  I personally start
flushing from the holding disk immediately the moment any dump is complete,
as all the data fits on one tape and the S3 upload takes longer than creating
the backups in the first place, but it should work just fine too when
buffering things on the holding disk.

The given S3 configuration assumes you already created the destination bucket
(I per-create them since I do life cycle stuff and cross-region replication,
both of which are easier to set up if you create the bucket by hand).  I also
use a dedicated IAM user for the S3 side of things for both security and
accounting reasons, but that shouldn't impact things.  Additionally, I've found
that the S3 uploads work much more reliably if you set a reasonable part size
and have part caching.  1 GB seems to give a good balance between performance
and reliability.

8<---

define tapetype vtape {
length 16 GB
part-size 1 GB
part-cache-type memory
}

define changer local-vtl {
tapedev "chg-disk:/path/to/local/vtapes"
}

define changer aws {
tapedev 
"chg-multi:s3:example-bucket/slot{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}"
device-property "S3_SSL""YES"
device-property "S3_ACCESS_KEY" "IAM_ACCESS_KEY"
device-property "S3_SECRET_KEY" "IAM_SECRET_KEY"
device-property "S3_MULTI_PART_UPLOAD"  "YES"
device-property "CREATE_BUCKET" "NO"
device-property "S3_BUCKET_LOCATION""us-east-1"
device-property "STORAGE_API"   "AWS4"
}

define storage local {
tapepool "local"
tapetype "vtape"
tpchanger "local-vtl"
}

define storage cloud {
tapepool "s3"
tapetype "vtape"
tpchanger "aws"
}

storage "local"
vault-storage "cloud"

Re: approaches to Amanda vaulting?

[Stefan G. Weichinger]

Am 2017-10-16 um 15:20 schrieb Jean-Louis Martineau:
> Amanda 3.5 can do everything you want only by running the amdump command.
> 
> Using an holding disk:
> 
> * You configure two storages
> * All dumps go to the holding disk
> * All dumps are copied to each storages, not necessarily at the same
> time or in the same run.
> * The dumps stay in holding until they are copied to both storages
> * You can tell amanda that everything must go to both storage or only
> some dle full/incr


So it is possible to set up a mix of "normal" daily backups with
incrementals/fulls and "archive"/vault backups with only the full
backups of a specific day ?

I have requests to do so for a customer, until now we used amanda-3.3.9
and 2 configs sharing most of config and disklist ...

Nathan, the OP of this thread and others (including me) would like to
see actual examples of configuration, a howto or something.

The man page https://wiki.zmanda.com/man/amvault.8.html is a bit minimal
...

Is there anything additional to that manpage and maybe:

http://wiki.zmanda.com/index.php/How_To:Copy_Data_from_Volume_to_Volume

?

stefan

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

On 14/10/17 12:19 PM, Jose M Calhariz wrote:
>
> Hi,
>
> I am too interested in examples of vaulting.
>
> In my case is to duplicate the locals vtapes into a remote S3
> endpoint, for purposes of reliability in case of disaster. If I have
> 50 locals vtapes, I want to have the same 50 vtapes on S3, on a amvault.

Why do you want the same vtapes?
It is impossible, vaulting works by dumps not by tape.

Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Jean-Louis Martineau]

Amanda 3.5 can do everything you want only by running the amdump command.

Using an holding disk:

  * You configure two storages
  * All dumps go to the holding disk
  * All dumps are copied to each storages, not necessarily at the same
time or in the same run.
  * The dumps stay in holding until they are copied to both storages
  * You can tell amanda that everything must go to both storage or only
some dle full/incr

Without holding disk

  * You configure one storage telling it to automatically vault its
dumps to the vault-storage
  * You configure one vault-storage
  * All dumps are dumped to the storage then vaulted to the vault-storage
  * The vault operation can be done later in the same run or in a
different run.
  * All dumps must go to the storage, but you can vault only some dles
full/incr

Don't forget to set a different tapepool for each storage.

On 04/10/17 10:17 AM, Nathan Stratton Treadway wrote:
> We are in the process of adding vaulting to our existing Amanda
> environment, and I am curious to hear/see how other sites have
> approached this.
>
> In particular, I'm curious what policies you have adopted for what gets
> vaulted, and how exactly you have scripted the vaulting so that you are
> sure the correct dumps always get copied the correct number of times,
> etc.
>
> In our situation, our nightly backups are to vtapes on a large internal
> drive, and our plan is to then vault to separate vtapes on external USB
> drives that are rotated physically each business day. So I think we
> don't want to use "vault-storage", since we want to let the nightly
> dumps proceeded without concern for whether the next USB drive is
> available yet.
You want vault-storage, if the next USB drive is not available, then 
nothing will be vaulted but amanda remember what must be vaulted and 
they will be vaulted on the next amdump.
> But what isn't clear is the best way to code a cron job
> to run later in the day, so that it keeps track of which of the nightly
> dumps have already been vaulted v.s. the ones that still need to be.
Amanda remember them, you have nothing to do.

Amanda lack a command to do: vault what is scheduled to be vaulted.
You could try 'amdump CONF badhost'
Since a host that match none of your host is specified, amdump will dump 
nothing, and I think the flush/vault operation will be done
It must be verified and tested.
If you do not want to set vault-storage during the normal amdump, you 
can try the following command to do the vault:
   amdump CONF badhost -ovault-storage=MY-VAULT

Jean-Louis
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

Re: approaches to Amanda vaulting?

[Charles Curley]

On Sat, 14 Oct 2017 17:19:57 +0100
Jose M Calhariz  wrote:

> In my case is to duplicate the locals vtapes into a remote S3
> endpoint, for purposes of reliability in case of disaster.  If I have
> 50 locals vtapes, I want to have the same 50 vtapes on S3, on a
> amvault.

I wonder if rsync wouldn't do this also.

I back up amanda metadata locally. Then from time to time I rsync my
vtapes and metadata to a USB drive for offsite disaster recovery. I have
scripts for all this & can share.

-- 

The right of the people to be secure in their persons, houses, papers,
and effects, against unreasonable searches and seizures, shall not be
violated, and no Warrants shall issue, but upon probable cause,
supported by Oath or affirmation, and particularly describing the
place to be searched, and the persons or things to be seized.
-- U.S. Const. Amendment IV

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

Re: approaches to Amanda vaulting?

[Jose M Calhariz]

Hi,

I am too interested in examples of vaulting.

In my case is to duplicate the locals vtapes into a remote S3
endpoint, for purposes of reliability in case of disaster.  If I have
50 locals vtapes, I want to have the same 50 vtapes on S3, on a amvault.

Kind regards
Jose M Calhariz


On Wed, Oct 04, 2017 at 10:17:22AM -0400, Nathan Stratton Treadway wrote:
> We are in the process of adding vaulting to our existing Amanda
> environment, and I am curious to hear/see how other sites have
> approached this.
> 
> In particular, I'm curious what policies you have adopted for what gets
> vaulted, and how exactly you have scripted the vaulting so that you are
> sure the correct dumps always get copied the correct number of times,
> etc.
> 
> In our situation, our nightly backups are to vtapes on a large internal
> drive, and our plan is to then vault to separate vtapes on external USB
> drives that are rotated physically each business day.  So I think we
> don't want to use "vault-storage", since we want to let the nightly
> dumps proceeded without concern for whether the next USB drive is
> available yet.  But what isn't clear is the best way to code a cron job
> to run later in the day, so that it keeps track of which of the nightly
> dumps have already been vaulted v.s. the ones that still need to be.
> 
> But more generally, I'm just curious to see how various sites have
> implemented vaulting.
> 
> Thanks.
> 
>   Nathan
> 
> 
> Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
> Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
>  GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
>  Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239
> 
> 

-- 
--
Perguntar a um escritor o que acha dos criticos e como
perguntar a um poste como ele se sente a respeito dos
cachorros.
-- John Osborne