Content preview:  Hmm... Another possibility I can think of is churn while 
you're
    running the backup. If you have your management class's copy serialization
    set to SHRDYNAMIC, SHRSTATIC, or STATIC, the client will try to determine
    if a file is changing while the backup is happening (multiple times in the
    case of SHRSTATIC) and either tell the server not to commit the data, or
   retry the transfer. If there's a retry, I'm not sure how it impacts the bytes
    transferred report at the end. [...]

 Content analysis details:   (0.7 points, 5.0 required)

  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 -0.0 RP_MATCHES_RCVD        Envelope sender domain matches handover relay 
domain
X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
X-Barracuda-Start-Time: 1510242332
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi
X-Barracuda-Scan-Msg-Size: 2835
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.44665
        Rule breakdown below
         pts rule name              description
        ---- ---------------------- 
--------------------------------------------------

Hmm... Another possibility I can think of is churn while you're running the
backup. If you have your management class's copy serialization set to
SHRDYNAMIC, SHRSTATIC, or STATIC, the client will try to determine if a
file is changing while the backup is happening (multiple times in the case
of SHRSTATIC) and either tell the server not to commit the data, or retry
the transfer. If there's a retry, I'm not sure how it impacts the bytes
transferred report at the end.

On Thu, Nov 09, 2017 at 03:30:59PM +0000, Drammeh, Jennifer C wrote:
> Skylar,
>
>    Sorry for the delayed response! No client side compression enabled.
>
>
> Jennifer
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Skylar Thompson
> Sent: Friday, November 03, 2017 2:49 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Question on Collocation
>
> Hi Jennifer,
>
> Do you have client-side compression enabled? I'm not familiar with what the 
> GUI reports, but dsmc will show this in the "Objects compressed by"
> line.
>
> On 11/03/2017 02:06 PM, Drammeh, Jennifer C wrote:
> > I use collocation and I have a node where the System Admin has requested 
> > that his data from a particular node be isolated on tapes by itself. I 
> > created a collocation group and have associated this one node with the new 
> > group. This node had previously been backing up to a different collocation 
> > group. I created a new Policy Domain and associated the node with it as 
> > well. This policy domain is set to send the data direct to tape instead of 
> > going to our diskpool. I also modified the settings on the server to allow 
> > this system to have 2 mount points.
> >
> > I had the SA launch a "full" manual backup from the GUI - using the "Always 
> > Backup" option. Here are the problems I am seeing.
> >
> >
> > 1.       I can see that the system state data when to a tape that was 
> > already used by other nodes (which tells me the collocation is not working)
> >
> > 2.       It only mounted 1 tape in a drive while performing the backup
> >
> > 3.       The metrics at the end showed that it inspected 283 GB of data and 
> > only transferred 175 GB which means it did not actually perform a full 
> > backup.
> >
> > Any ideas to help get a FULL backup of this data alone on a single 1
> > or 2 tapes and ideally using multiple tape drives to speed things up?
> > (for backup and restore)
> >
> > Thanks!
> >
> >
> > Jennifer
>
>
> --
> -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine