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 <r...@cornell.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 > r...@cornell.edu<mailto:r...@cornell.edu> > > > On Oct 25, 2017, at 3:35 PM, Zoltan Forray <zfor...@vcu.edu<mailto:zforra > 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<http://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/
