Re: MSQSSQL TDP 6.4 and 7.4.1 : legacy backup do not expire
Hi, Thanks for your reply Efim, We run Full DB backup every night and they happen fine (see log below). The management class is the same for Full bkps and logs bkps. We encounter the issue on all the infrastructure (more than 70 MSSQL instances). FULL DB backup objects and log backup objects have the same behavior, they do not get inactive and thus do not expire I'm quite sure that inactivate manually the objects will generate the expire. But, from our side, that is not a way to rule a production infrastructure and we must find the root cause Have a great day, Emmanuel 10/12/2016 21:25:36 = 10/12/2016 21:25:38 = 10/12/2016 21:25:38 Request : FULL BACKUP 10/12/2016 21:25:38 Database Input List : * 10/12/2016 21:25:38 Group Input List : - 10/12/2016 21:25:38 File Input List : - 10/12/2016 21:25:38 Number of Buffers : 3 10/12/2016 21:25:38 Buffer Size : 1024 10/12/2016 21:25:38 Number of SQL Buffers : 0 10/12/2016 21:25:38 SQL Buffer Size : 1024 10/12/2016 21:25:38 Number of Stripes specified : 1 10/12/2016 21:25:38 Estimate : - 10/12/2016 21:25:38 Truncate Log? : - 10/12/2016 21:25:38 SQL Checksum enabled? : No 10/12/2016 21:25:38 Wait for Tape Mounts? : Yes 10/12/2016 21:25:38 TSM Options File : c:\Program Files\Tivoli\TSM\TDPSql\dsm_H1_TDP.opt 10/12/2016 21:25:38 TSM Nodename Override : - 10/12/2016 21:25:39 Sqlserver : H1\INSTANCE1 10/12/2016 21:25:54 Total SQL backups selected: 10 10/12/2016 21:25:54 Total SQL backups attempted: 4 10/12/2016 21:25:54 Total SQL backups completed: 4 10/12/2016 21:25:54 Total SQL backups excluded: 6 10/12/2016 21:25:54 Total SQL backups inactivated:216 10/12/2016 21:25:54 Total SQL backups deduplicated: 0 10/12/2016 21:25:54 Throughput rate: 8,183.72 Kb/Sec 10/12/2016 21:25:54 Total bytes inspected:52,090,880 10/12/2016 21:25:54 Total bytes transferred: 52,090,880 10/12/2016 21:25:54 Total LanFree bytes transferred: 0 10/12/2016 21:25:54 Total bytes before deduplication: 0 10/12/2016 21:25:54 Total bytes after deduplication: 0 10/12/2016 21:25:54 Data compressed by: 0% 10/12/2016 21:25:54 Deduplication reduction: 0.00% 10/12/2016 21:25:54 Total data reduction ratio: 0.00% 10/12/2016 21:25:54 Elapsed processing time: 6.22 Secs 10/12/2016 21:41:44 == Log file pruned using log retention period of 60 day(s) 10/12/2016 21:41:44 == No log entries pruned 10/12/2016 21:41:46 = -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Efim Envoyé : jeudi 13 octobre 2016 11:45 À : ADSM-L@VM.MARIST.EDU Objet : Re: [ADSM-L] MSQSSQL TDP 6.4 and 7.4.1 : legacy backup do not expire HI, You shows the LOG object but it will deactivated as GROUP object. The GROUP leader is FULL backup. Do you have only ONE active FULL object for this DB? If yes, is the FULL active object is younger than this active LOG? If yes - you can use inactivate (or delete) command for inactivate(delete) log older than last active full and monitor situation. Efim > 13 окт. 2016 г., в 11:10, BOVE Emmanuel (EXT) > написал(а): > > MC_PROD_LOG_SQL
MSQSSQL TDP 6.4 and 7.4.1 : legacy backup do not expire
Hi All, We have a Sev 1 PMR opened at IBM since Monday and at this time still no answer Here is the situation : We have implemented one year ago MSSQL TDP, first in 6.4 and after we migrated to 7.1.4.1 in order to backup MSSQL AlwaysOn instances. Backups (Full and logs) are running fine. We need to be able to keep backups for only 31 days. We only use Legacy backups, no VSS backups at all. Restoration are running 'fine ' (meaning they can be done). But we have faced an issue during the first step when the TDP requests the objects list to the TSM instance. For exemple, it can take up to 6H30 After some investigations it appears that on the TSM instance, none of the objects become inactive. So, none of them expire correctly and by the way reclaimed. For exemple : select NODE_NAME, FILESPACE_NAME, STATE, TYPE, BACKUP_DATE, DEACTIVATE_DATE, CLASS_NAME from backups where NODE_NAME='MYNODE_TDP' will show things like : MYNODE_TDP P\data\0001 ACTIVE_VERSION FILE2015-12-31 17:30:18.00 MC_PROD_LOG_SQL So neither in 6.4 version or 7.1.4.1 version an expiration have occurred. Management class and copygroups : Policy Domain Name: DOM_PROD Policy Set Name: ACTIVE Mgmt Class Name: MC_PROD_LOG_SQL Default Mgmt Class ?: No Description : MC for MSSQL Space Management Technique: None Auto-Migrate on Non-Use: 0 Migration Requires Backup?: Yes Migration Destination: SPACEMGPOOL Last Update by (administrator): ADMIN Last Update Date/Time: 04-09-2014 16:05:23 Managing profile: Changes Pending: No Associated copygroup : Policy Domain Name: DOM_PROD Policy Set Name: ACTIVE Mgmt Class Name: MC_PROD_LOG_SQL Copy Group Name: STANDARD Copy Group Type: Backup Versions Data Exists: 31 Versions Data Deleted: 1 Retain Extra Versions: No Limit Retain Only Version: 31 Copy Mode: Modified Copy Serialization: Static Copy Frequency: 0 Copy Destination: STG_DISK_PRD_DAT Table of Contents (TOC) Destination: Last Update by (administrator): MYADMIN Last Update Date/Time: 04-09-2014 16:12:00 Managing profile: Changes Pending: No So at this time, we have a real production issue : * Impossible to match the requested SLA * An incredible number of objects stored on TSM instance * No idea of the root cause and how to sole the problem Any help would be really appreciated, I will summarize. Have a great day, Emmanuel = Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme falsifie. = This message and any attachments (the "message") are confidential, intended solely for the addresses, and may contain legally privileged information. Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. =
Re: Space reclamation is ended for volume
Hi Mik, In order to preserve the existing backuped data on the volume, I can suggest you this : 1) Put the tape in readOnly mode: upd vol Volume_Name access=reado 2) Protect current valid datas : Move data Volume_name --> It move all good datas, even the ones that have not been copied yet. --> It flags bad files as damaged 3) audit the tape and fix it : audit vol volume_name fix=yes 4) restore the destroyed datas (when a copy of them exist) : restore vol Volume_Name Hope it helps, Emmanuel -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de mik Envoyé : jeudi 12 décembre 2013 11:10 À : ADSM-L@VM.MARIST.EDU Objet : [ADSM-L] Space reclamation is ended for volume Hi Eric van Loon and thanks for the reply, I have already try the audit volume and audit volume fix=yes and no error on th file, i don"t understand. Regars, Mickael. +-- |This was sent by bobpatrick808...@yahoo.fr via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
