Re: Huge differences in file count after exporting node to a different server

[Zoltan Forray]

Thanks for the confirmation.  I figure it is some kind of
cleanup/timing/orphaned-objects issue.

On Mon, Oct 30, 2017 at 9:32 AM, Robert Talda  wrote:

> Zoltan:
>  For what it is worth, I’ve seen this behavior for years.  I attempted to
> pursue it a couple of times with IBM support but never got anywhere.
>
>  In fact, it just occurred last week//
> OS: Red Hat Enterprise Linux Server release 6.8 (Santiago)
> TSM Server Version 7, Release 1, Level 7.200
>
>
> Source node statistics (from BACKUPS table):
> FSIDType State   Count
> 1 DIR INACTIVE_VERSION353
> 1 DIR ACTIVE_VERSION57355
> 1 FILE INACTIVE_VERSION   1055
> 1 FILE ACTIVE_VERSION   392870
> 2 DIR ACTIVE_VERSION 4161
> 2 FILE ACTIVE_VERSION25751
>
> Target node statistics (from BACKUPS table):
> FSIDType StateCount
> 1 DIR INACTIVE_VERSION706
> 1 DIR ACTIVE_VERSION   114710
> 1 FILE INACTIVE_VERSION   1055
> 1 FILE ACTIVE_VERSION   393246
> 2 DIR ACTIVE_VERSION 4161
> 2 FILE ACTIVE_VERSION25751
>
> Note the duplication of the directories - so obvious, I didn’t pursue.  I
> did look into the additional active files, and many were inconsequential
> (e.g., files named .ds_store; this is a macOS X platform) but there were a
> number of other files with real content.  In this case, the additional
> files were not a problem, so I didn’t pursue further, other than verifying
> that expiration wasn’t running on the source server, so the origin was
> uncertain
>
>
> Robert Talda
> EZ-Backup Systems Engineer
> Cornell University
> +1 607-255-8280
> r...@cornell.edu
>
>
> On Oct 25, 2017, at 3:35 PM, Zoltan Forray  y...@vcu.edu>> wrote:
>
> I am curious if anyone has seen anything like this.
>
> A node was exported (filedata=all) from one server to another (all servers
> are 7.1.7.300 RHEL)
>
> After successful completion (took a week due to 6TB+ to process) and
> copypool backups on the new server, the Total Occupancy counts are the same
> (13.52TB).  However, the file counts are waaay off (original=17,561,816 vs
> copy=12,471,862)
>
> There haven't been any backups performed to either the original (since the
> export) or new node. Policies are the same on both servers and even if they
> weren't, that wouldn't explain the same occupancy size/total.
>
> Neither server runs dedup (DISK based storage volumes).
>
> Any thoughts?
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zfor...@vcu.edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://phishing.vcu.edu/
>
>


-- 
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://phishing.vcu.edu/

Re: Huge differences in file count after exporting node to a different server

[Robert Talda]

Zoltan:
 For what it is worth, I’ve seen this behavior for years.  I attempted to 
pursue it a couple of times with IBM support but never got anywhere.

 In fact, it just occurred last week//
OS: Red Hat Enterprise Linux Server release 6.8 (Santiago)
TSM Server Version 7, Release 1, Level 7.200


Source node statistics (from BACKUPS table):
FSIDType State   Count
1 DIR INACTIVE_VERSION353
1 DIR ACTIVE_VERSION57355
1 FILE INACTIVE_VERSION   1055
1 FILE ACTIVE_VERSION   392870
2 DIR ACTIVE_VERSION 4161
2 FILE ACTIVE_VERSION25751

Target node statistics (from BACKUPS table):
FSIDType StateCount
1 DIR INACTIVE_VERSION706
1 DIR ACTIVE_VERSION   114710
1 FILE INACTIVE_VERSION   1055
1 FILE ACTIVE_VERSION   393246
2 DIR ACTIVE_VERSION 4161
2 FILE ACTIVE_VERSION25751

Note the duplication of the directories - so obvious, I didn’t pursue.  I did 
look into the additional active files, and many were inconsequential (e.g., 
files named .ds_store; this is a macOS X platform) but there were a number of 
other files with real content.  In this case, the additional files were not a 
problem, so I didn’t pursue further, other than verifying that expiration 
wasn’t running on the source server, so the origin was uncertain


Robert Talda
EZ-Backup Systems Engineer
Cornell University
+1 607-255-8280
r...@cornell.edu


On Oct 25, 2017, at 3:35 PM, Zoltan Forray 
> wrote:

I am curious if anyone has seen anything like this.

A node was exported (filedata=all) from one server to another (all servers
are 7.1.7.300 RHEL)

After successful completion (took a week due to 6TB+ to process) and
copypool backups on the new server, the Total Occupancy counts are the same
(13.52TB).  However, the file counts are waaay off (original=17,561,816 vs
copy=12,471,862)

There haven't been any backups performed to either the original (since the
export) or new node. Policies are the same on both servers and even if they
weren't, that wouldn't explain the same occupancy size/total.

Neither server runs dedup (DISK based storage volumes).

Any thoughts?

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://phishing.vcu.edu/

Re: Huge differences in file count after exporting node to a different server

[Richard Cowen]

If you saved or still have the actlog from the time of the export check for 
messages like:

ANR0635I EXPORT NODE: Processing node RCOWEN in domain STANDARD.
ANR0627I EXPORT NODE: Copied 2 file space 0 archive files, 23420 backup files, 
and 0 space managed files.
ANR0629I EXPORT NODE: Copied 299457501 bytes of data.

And similar IMPORT messages.

Richard
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan 
Forray
Sent: Wednesday, October 25, 2017 4:05 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Huge differences in file count after exporting node to a 
different server

There is a small difference but not enough to make that big of a difference in 
file/object-count but not in occupancy.

On Wed, Oct 25, 2017 at 3:43 PM, Sasa Drnjevic <sasa.drnje...@srce.hr>
wrote:

> > Any thoughts?
>
> Directories vs files?
>
> Are you sure the mgmt classes are 100% same?
>
>
> Regards.
>
> --
> Sasa Drnjevic
> www.srce.unizg.hr
>
>
>
>
>
> On 2017-10-25 21:35, Zoltan Forray wrote:
> > I am curious if anyone has seen anything like this.
> >
> > A node was exported (filedata=all) from one server to another (all
> servers
> > are 7.1.7.300 RHEL)
> >
> > After successful completion (took a week due to 6TB+ to process) and 
> > copypool backups on the new server, the Total Occupancy counts are 
> > the
> same
> > (13.52TB).  However, the file counts are waaay off 
> > (original=17,561,816
> vs
> > copy=12,471,862)
> >
> > There haven't been any backups performed to either the original 
> > (since
> the
> > export) or new node. Policies are the same on both servers and even 
> > if
> they
> > weren't, that wouldn't explain the same occupancy size/total.
> >
> > Neither server runs dedup (DISK based storage volumes).
> >
> > Any thoughts?
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator 
> > Xymon Monitor Administrator VMware Administrator Virginia 
> > Commonwealth University UCC/Office of Technology Services 
> > www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing 
> > victim - VCU and other reputable organizations will never use email 
> > to request that you reply with your password, social security number 
> > or confidential personal information. For more details visit 
> > http://phishing.vcu.edu/
> >
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor 
Administrator VMware Administrator Virginia Commonwealth University UCC/Office 
of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be 
a phishing victim - VCU and other reputable organizations will never use email 
to request that you reply with your password, social security number or 
confidential personal information. For more details visit 
http://phishing.vcu.edu/


This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com

Re: Huge differences in file count after exporting node to a different server

[Zoltan Forray]

Those numbers are as of this morning.  There has been no activity on this
node since the export started until about an hour ago (just found out the
original contact/maintainer of the server has left the university and
someone else has taken over).

On Wed, Oct 25, 2017 at 3:52 PM, Harris, Steven <
steven.har...@btfinancialgroup.com> wrote:

> Hi Zoltan
>
> Are the  old server numbers from export time or current time?  If current
> time you may have had some 5 million small files expire in the interim.
>
> Cheers
>
> Steve
>
> Steven Harris
> TSM Admin/Consultant
> Canberra, Australia
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Zoltan Forray
> Sent: Thursday, 26 October 2017 6:35 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: [ADSM-L] Huge differences in file count after exporting node to a
> different server
>
> I am curious if anyone has seen anything like this.
>
> A node was exported (filedata=all) from one server to another (all servers
> are 7.1.7.300 RHEL)
>
> After successful completion (took a week due to 6TB+ to process) and
> copypool backups on the new server, the Total Occupancy counts are the same
> (13.52TB).  However, the file counts are waaay off (original=17,561,816 vs
> copy=12,471,862)
>
> There haven't been any backups performed to either the original (since the
> export) or new node. Policies are the same on both servers and even if they
> weren't, that wouldn't explain the same occupancy size/total.
>
> Neither server runs dedup (DISK based storage volumes).
>
> Any thoughts?
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zfor...@vcu.edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://phishing.vcu.edu/
>
>
> This message and any attachment is confidential and may be privileged or
> otherwise protected from disclosure. You should immediately delete the
> message if you are not the intended recipient. If you have received this
> email by mistake please delete it from your system; you should not copy the
> message or disclose its content to anyone.
>
> This electronic communication may contain general financial product advice
> but should not be relied upon or construed as a recommendation of any
> financial product. The information has been prepared without taking into
> account your objectives, financial situation or needs. You should consider
> the Product Disclosure Statement relating to the financial product and
> consult your financial adviser before making a decision about whether to
> acquire, hold or dispose of a financial product.
>
> For further details on the financial product please go to
> http://www.bt.com.au
>
> Past performance is not a reliable indicator of future performance.
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://phishing.vcu.edu/

Re: Huge differences in file count after exporting node to a different server

[Zoltan Forray]

There is a small difference but not enough to make that big of a difference
in file/object-count but not in occupancy.

On Wed, Oct 25, 2017 at 3:43 PM, Sasa Drnjevic 
wrote:

> > Any thoughts?
>
> Directories vs files?
>
> Are you sure the mgmt classes are 100% same?
>
>
> Regards.
>
> --
> Sasa Drnjevic
> www.srce.unizg.hr
>
>
>
>
>
> On 2017-10-25 21:35, Zoltan Forray wrote:
> > I am curious if anyone has seen anything like this.
> >
> > A node was exported (filedata=all) from one server to another (all
> servers
> > are 7.1.7.300 RHEL)
> >
> > After successful completion (took a week due to 6TB+ to process) and
> > copypool backups on the new server, the Total Occupancy counts are the
> same
> > (13.52TB).  However, the file counts are waaay off (original=17,561,816
> vs
> > copy=12,471,862)
> >
> > There haven't been any backups performed to either the original (since
> the
> > export) or new node. Policies are the same on both servers and even if
> they
> > weren't, that wouldn't explain the same occupancy size/total.
> >
> > Neither server runs dedup (DISK based storage volumes).
> >
> > Any thoughts?
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > Xymon Monitor Administrator
> > VMware Administrator
> > Virginia Commonwealth University
> > UCC/Office of Technology Services
> > www.ucc.vcu.edu
> > zfor...@vcu.edu - 804-828-4807
> > Don't be a phishing victim - VCU and other reputable organizations will
> > never use email to request that you reply with your password, social
> > security number or confidential personal information. For more details
> > visit http://phishing.vcu.edu/
> >
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://phishing.vcu.edu/

Re: Huge differences in file count after exporting node to a different server

[Harris, Steven]

Hi Zoltan

Are the  old server numbers from export time or current time?  If current time 
you may have had some 5 million small files expire in the interim.

Cheers

Steve

Steven Harris
TSM Admin/Consultant 
Canberra, Australia

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan 
Forray
Sent: Thursday, 26 October 2017 6:35 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Huge differences in file count after exporting node to a 
different server

I am curious if anyone has seen anything like this.

A node was exported (filedata=all) from one server to another (all servers
are 7.1.7.300 RHEL)

After successful completion (took a week due to 6TB+ to process) and
copypool backups on the new server, the Total Occupancy counts are the same
(13.52TB).  However, the file counts are waaay off (original=17,561,816 vs
copy=12,471,862)

There haven't been any backups performed to either the original (since the
export) or new node. Policies are the same on both servers and even if they
weren't, that wouldn't explain the same occupancy size/total.

Neither server runs dedup (DISK based storage volumes).

Any thoughts?

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://phishing.vcu.edu/


This message and any attachment is confidential and may be privileged or 
otherwise protected from disclosure. You should immediately delete the message 
if you are not the intended recipient. If you have received this email by 
mistake please delete it from your system; you should not copy the message or 
disclose its content to anyone. 

This electronic communication may contain general financial product advice but 
should not be relied upon or construed as a recommendation of any financial 
product. The information has been prepared without taking into account your 
objectives, financial situation or needs. You should consider the Product 
Disclosure Statement relating to the financial product and consult your 
financial adviser before making a decision about whether to acquire, hold or 
dispose of a financial product. 

For further details on the financial product please go to http://www.bt.com.au 

Past performance is not a reliable indicator of future performance.

Re: Huge differences in file count after exporting node to a different server

[Sasa Drnjevic]

> Any thoughts?

Directories vs files?

Are you sure the mgmt classes are 100% same?


Regards.

--
Sasa Drnjevic
www.srce.unizg.hr





On 2017-10-25 21:35, Zoltan Forray wrote:
> I am curious if anyone has seen anything like this.
>
> A node was exported (filedata=all) from one server to another (all servers
> are 7.1.7.300 RHEL)
>
> After successful completion (took a week due to 6TB+ to process) and
> copypool backups on the new server, the Total Occupancy counts are the same
> (13.52TB).  However, the file counts are waaay off (original=17,561,816 vs
> copy=12,471,862)
>
> There haven't been any backups performed to either the original (since the
> export) or new node. Policies are the same on both servers and even if they
> weren't, that wouldn't explain the same occupancy size/total.
>
> Neither server runs dedup (DISK based storage volumes).
>
> Any thoughts?
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zfor...@vcu.edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://phishing.vcu.edu/
>

Huge differences in file count after exporting node to a different server

[Zoltan Forray]

I am curious if anyone has seen anything like this.

A node was exported (filedata=all) from one server to another (all servers
are 7.1.7.300 RHEL)

After successful completion (took a week due to 6TB+ to process) and
copypool backups on the new server, the Total Occupancy counts are the same
(13.52TB).  However, the file counts are waaay off (original=17,561,816 vs
copy=12,471,862)

There haven't been any backups performed to either the original (since the
export) or new node. Policies are the same on both servers and even if they
weren't, that wouldn't explain the same occupancy size/total.

Neither server runs dedup (DISK based storage volumes).

Any thoughts?

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://phishing.vcu.edu/