Re: Huge differences in file count after exporting node to a different server
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 Drnjevicwrote: > > 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
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
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 Drnjevicwrote: > > 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
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
> 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
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: DP for MySAP Maintenance releases
Sorry for the confusion. IBM has been putting up a lot of walls lately (e.g. my tape drive firmware was on FTP) so you have to pay/go through Passport. On Wed, Oct 25, 2017 at 10:26 AM, Loon, Eric van (ITOPT3) - KLM < eric-van.l...@klm.com> wrote: > Hi Zoltan! > Patches yes, but maintenance releases seem to be gone... > Kind regards, > Eric van Loon > Air France/KLM Storage Engineering > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Zoltan Forray > Sent: dinsdag 24 oktober 2017 19:08 > To: ADSM-L@VM.MARIST.EDU > Subject: Re: DP for MySAP Maintenance releases > > I just went to: > ftp://service.boulder.ibm.com//storage/tivoli-storage- > management/patches/tivoli-data-protection/r3 > and there are 7-sub-directories labeleled v6211, v6301.to v7131. > > On Tue, Oct 24, 2017 at 9:21 AM, Loon, Eric van (ITOPT3) - KLM < > eric-van.l...@klm.com> wrote: > > > Hi guys, > > Does anybody know what happened to the ftp://service.boulder.ibm.com/ > > storage/tivoli-storage-management/maintenance/tivoli-data-protection/r > > 3 directory? It seems to be gone for quite a while, so no Data > > Protection for MySAP maintenance releases are available for download > > anymore? > > Kind regards, > > Eric van Loon > > Air France/KLM Storage Engineering > > > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee only. > > If you are not the addressee, you are notified that no part of the > > e-mail or any attachment may be disclosed, copied or distributed, and > > that any other action related to this e-mail or attachment is strictly > > prohibited, and may be unlawful. If you have received this e-mail by > > error, please notify the sender immediately by return e-mail, and delete > this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > > its employees shall not be liable for the incorrect or incomplete > > transmission of this e-mail or any attachments, nor responsible for any > delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch > > Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > > > > > > > -- > *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/ > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail or > any attachment may be disclosed, copied or distributed, and that any other > action related to this e-mail or attachment is strictly prohibited, and may > be unlawful. If you have received this e-mail by error, please notify the > sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission > of this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > -- *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: Directory-Container Pool
Hi Murat! Just wait a few hours. There is some lag before the data is removed from the containers. Kind regards, Eric van Loon Air France/KLM Storage Engineering -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Murat ÖRDEKBAY Sent: woensdag 25 oktober 2017 17:25 To: ADSM-L@VM.MARIST.EDU Subject: Directory-Container Pool Hi colleagues, I have Spectrum Protect server 8.1.2. I have a backup on directory-container storage pool. Then I deleted filespace where disk backup is located. But it still takes up space on the directory-xontainer atorage pool. Reusedelay=0 What should i do to delete from containers or data in directory storage pool... Thank you in advance for your answers. Murat For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
Directory-Container Pool
Hi colleagues, I have Spectrum Protect server 8.1.2. I have a backup on directory-container storage pool. Then I deleted filespace where disk backup is located. But it still takes up space on the directory-xontainer atorage pool. Reusedelay=0 What should i do to delete from containers or data in directory storage pool... Thank you in advance for your answers. Murat
Re: DP for MySAP Maintenance releases
Hi Zoltan! Patches yes, but maintenance releases seem to be gone... Kind regards, Eric van Loon Air France/KLM Storage Engineering -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: dinsdag 24 oktober 2017 19:08 To: ADSM-L@VM.MARIST.EDU Subject: Re: DP for MySAP Maintenance releases I just went to: ftp://service.boulder.ibm.com//storage/tivoli-storage-management/patches/tivoli-data-protection/r3 and there are 7-sub-directories labeleled v6211, v6301.to v7131. On Tue, Oct 24, 2017 at 9:21 AM, Loon, Eric van (ITOPT3) - KLM < eric-van.l...@klm.com> wrote: > Hi guys, > Does anybody know what happened to the ftp://service.boulder.ibm.com/ > storage/tivoli-storage-management/maintenance/tivoli-data-protection/r > 3 directory? It seems to be gone for quite a while, so no Data > Protection for MySAP maintenance releases are available for download > anymore? > Kind regards, > Eric van Loon > Air France/KLM Storage Engineering > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. > If you are not the addressee, you are notified that no part of the > e-mail or any attachment may be disclosed, copied or distributed, and > that any other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and delete this > message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for any delay > in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > -- *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/ For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286