ā12-08-2009 06:21 AM
Hello again,
with performing backup (LMS 3.2 on Solaris 9) the following errors will arise.
dbbackup.log |
---|
/opt/CSCOpx/bin/tar: Removing leading `/' from absolute path names in the archive Apps file : /opt/CSCOpx/backup/manifest/upm/upminfo/datafiles.txt [Tue Dec 8 08:56:54 2009] Archiving the contents of the following directories into /enbw/backup/files/cw_db_backup/0/upm/filebackup.tar [Tue Dec 8 08:56:54 2009] /opt/CSCOpx/hum/conf/upm-snmp.properties /opt/CSCOpx/hum/thresholdscript /opt/CSCOpx/MDC/tomcat/webapps/upm/reports /opt/CSCOpx/MDC/tomcat/webapps/upm/WEB-INF/classes/com/cisco/nm/upm/properti es/common/UPM.properties /opt/CSCOpx/bin/tar: Removing leading `/' from absolute path names in the archive /opt/CSCOpx/bin/tar: Cannot add file /opt/CSCOpx/MDC/tomcat/webapps/upm/reports/virt32841308_657_658_-718594975: No such file or directory /opt/CSCOpx/bin/tar: Cannot add file /opt/CSCOpx/MDC/tomcat/webapps/upm/reports/virt32841308_658_659_1465769167: No such file or directory /opt/CSCOpx/bin/tar: Error exit delayed from previous errors [Tue Dec 8 09:07:30 2009] ERROR(908): Cannot create or back up tar file. Backup cancelled. Verify that you have write-access to this directory. [Tue Dec 8 09:07:30 2009] Backup failed: 2009/12/08 09:07:40 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
Is seems to be problem related to maximal filesize handling of GNUtar implemented in CW2000.
The problem is with tar'ing HUM-Reports in /opt/CSCOpx/MDC/tomcat/webapps/upm/reports, and with reaching
tarfile-size of 2,9GByte error is thrown.
</exxx/backup/files/cw_db_backup/0/upm># ls -lh
total 6126448
-rw-r----- 1 casuser casusers 2.9G Dec 8 09:07 filebackup.tar
</exxx/backup/files/cw_db_backup/0/upm># ls -al
total 6126452
drwxr-x--- 2 casuser casusers 512 Dec 7 14:30 .
drwxr-x--- 11 casuser casusers 512 Dec 7 14:30 ..
-rw-r----- 1 casuser casusers 3135201280 Dec 8 09:07 filebackup.tar
GNUtar-Version
# /opt/CSCOpx/bin/tar --version
tar (GNU tar) 1.13
Copyright (C) 1988, 92,93,94,95,96,97,98, 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by John Gilmore and Jay Fenlason.
Is this a know problem?
Thanks for any thoughts.
Best Regards
Lothar
Solved! Go to Solution.
ā12-09-2009 02:32 PM
This sounds like a race condition. This kind of race can be avoided if you perform an offline backup. That is, shutdown Daemon Manager, then run the backup. This can be done automatically by setting:
BACKUP_OFFLINE=YES
In NMSROOT/conf/backup.properties.
ā12-08-2009 10:38 AM
The problems with large file size should have been fixed a while ago. Besides, this only affected the target file to be tarred, and not the tar file itself. How big are /opt/CSCOpx/MDC/tomcat/webapps/upm/reports/virt32841308_657_658_-718594975 and /opt/CSCOpx/MDC/tomcat/webapps/upm/reports/virt32841308_658_659_1465769167?
ā12-09-2009 05:20 AM
Hi Joe,
thanks for your feedback.
These files to be tarred aren't there directly after backup stops with error.
It seems that some process stores data about reports in that file and when trying to
pack these reports via tar they are delete by any cleanup method.
Does this help.
P.S. Backup usually takes about more than 1hour
ā12-09-2009 02:32 PM
This sounds like a race condition. This kind of race can be avoided if you perform an offline backup. That is, shutdown Daemon Manager, then run the backup. This can be done automatically by setting:
BACKUP_OFFLINE=YES
In NMSROOT/conf/backup.properties.
ā12-10-2009 05:26 AM
Hi Joe,
thanks for this gold-answer.
With that option activated backup is now running.
Thanks for your superb support
Lothar
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide