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 <rpt4 AT cornell DOT edu> 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):
> FSID Type State Count
> 1 DIR INACTIVE_VERSION 353
> 1 DIR ACTIVE_VERSION 57355
> 1 FILE INACTIVE_VERSION 1055
> 1 FILE ACTIVE_VERSION 392870
> 2 DIR ACTIVE_VERSION 4161
> 2 FILE ACTIVE_VERSION 25751
>
> Target node statistics (from BACKUPS table):
> FSID Type State Count
> 1 DIR INACTIVE_VERSION 706
> 1 DIR ACTIVE_VERSION 114710
> 1 FILE INACTIVE_VERSION 1055
> 1 FILE ACTIVE_VERSION 393246
> 2 DIR ACTIVE_VERSION 4161
> 2 FILE ACTIVE_VERSION 25751
>
> 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
> rpt4 AT cornell DOT edu<mailto:rpt4 AT cornell DOT edu>
>
>
> On Oct 25, 2017, at 3:35 PM, Zoltan Forray <zforray AT VCU DOT
> EDU<mailto:zforra
> y AT VCU DOT 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<http://www.ucc.vcu.edu>
> zforray AT vcu DOT 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
zforray AT vcu DOT 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/
|
