This post is more than 5 years old
2 Intern
•
129 Posts
0
562
March 7th, 2012 09:00
CBRM 2.2 on Windows leap year problem
Dear All,
using the CBRM 2.2 on Windows with Networker we ran into a leap year problem. Quarterly we do full backups and the day to day backup is incremental. It seems that CBRM 2.2 has a leap year problem if it is incremental. Since 1st of March we got the following error and backup jobs fails.
nsrndmp_save: NDMP Service Log: E: (134 -0001) Malformed date. For the specified month(2), date(29) must not exceed 28.
Does anybody know where is the last backup date stored (clusterID_BackupLevels file) on the filesystem?
I think If I change this it will work again in the next 4 years. !/4.5.6/images/emoticons/happy.gif|_mce_src=/4.5.6/images/emoticons/happy.gif|___jive_emoticon_name=happy|jivemacro=emoticon|class=jive_macro jive_emote|src=/4.5.6/images/emoticons/happy.gif!
I backed up already the 02.29 files using a time-range backup but this is considered a stand-alone backup.
I does not want to run a full backup because it is a huge amount of data.
In 2008 we did only full backups and did not have this problem, it seems only incremental has this problem.
Thank You!
Krisztian
Satish_Kutty
216 Posts
0
March 7th, 2012 10:00
Hi Krisztian,
I belive that it would be better if you can open a new discssion on the Networker forum since the issue is related to backup.Also the best article I could find related to the issue is given below,hope it helps in resolving the issue.
The cluster_ID_lastBackupDate File
The cluster_ID_lastBackupDate file contains the creation date and timeof the last backed up C-Clip. This date and time are used to identifythe lower boundary range of C-Clips for subsequent level 1 backups.If the cluster_ID_lastBackupDate file is corrupted, and a backup of the
file cannot be restored, do one of the following:
◆ Use the LAST_DATE variable with the next level 1 backup to set
the cluster_ID_lastBackupDate file back to its original value.
◆ Perform a level 0 backup of the Centera cluster.
LAST_DATE Variable The LAST_DATE variable overrides the cluster_ID_lastBackupDate file with a specified date and time that is on or before the date and time of the last known successful backup. It has no other effect on the backup process.
Use the LAST_DATE variable only in the following disaster recovery
situations:
◆ The cluster_ID_lastBackupDate file is missing and a backup of the
file is not available.
◆ Performing a level 0 backup of the Centera cluster is too time consuming.
You can set the LAST_DATE variable in the resource file. For
information about the resource file, refer to Task 2: Configure the
CBRM Resource File on page 3-3.
Important:
◆ If the BEGIN_DATE variable is specified with the LAST_DATE
variable, the cluster_ID_lastBackupDate file is updated with the
value specified in the LAST_DATE variable. However, the
BEGIN_DATE variable overrides the LAST_DATE variable as the
beginning date and time of the range of C-Clips to be backed up.
◆ Ensure that the LAST_DATE variable is used only to recreate the
cluster_ID_lastBackupDate file.
6-6 CBRM Version 2.0.2 Installation and Administrator’s Guide
Disaster Recovery
Set the LAST_DATE Variable
To set the LAST_DATE variable, do the following:
1. Edit the resource file that you created in Task 2: Configure the
CBRM Resource File on page 3-3, to include the LAST_DATE variable.
2. Convert the local date and time for LAST_DATE to Greenwich
Mean Time (GMT).
3. Specify the LAST_DATE variable by using the following format:
LAST_DATE=mm/dd/yyyy,hh:mm:ss where: mm/dd/yyyy contains the digits representing the month, day,
and year, respectively.hh:mm:ss contains the digits representing the hours, minutes,
and seconds, respectively, based on a 24-hour clock.If the time is not included, the default time is 00:00:00.
4. Ensure that the date and time is on or before the date and time of
the last known successful backup.
5. Save the file.
szekelyk
2 Intern
•
129 Posts
0
March 9th, 2012 05:00
Hi,
finally I edited the CLUSTERID_BackupLevels file, and changed the date at INCRBD after 29th February. Now everything is OK, for another 4 years.
Krisztian