Video Screencast Help

Linux and Synthetic Backups

Created: 28 May 2010 • Updated: 28 May 2010 | 5 comments

Hello everyone,

I'm trying to get a weekly synthetic full backup of my Linux servers going with Backup Exec 2010 (Media server is Windows 2008).  I've installed the Linux agent and am able to run regular full, incremental & differential backups from the Linux host.  When I create a synthetic backup policy (a copy of the example template generated by Backup Exec) I can run the baseline full backup without any trouble but the incremental backup fails - actually crashes the remote agent is more accruate.  The job runs for about 10 minutes and then fails when the remote agent crashes.  During its run the data transfer rate is only about 200MB/min while a normal job (without the synthetic option checked) achieves about 1GB/min. The error logged is:

Completed status: Failed

Final error: 0xe000ff11 - A communications failure has occurred with a Linux or Unix resource. 
Final error category: Resource Errors

Obviously the above error is simply because the agent has crashed and communication fails. On the console of the Linux server I see:

*** glibc detected *** free(): invalid next size (fast): 0x08234948 ***

I've found that if I uncheck the "Collect additional information for synthetic backup and for true image restore" flag in the incremental job template then the backup runs just fine.  Has anyone else seen this problem?  The Linux agent is running on Debian 4 & 5 systems.  There are a few servers that have completed the incremental job with the synthetic option enabled one night, as scheduled, but then failed the next night.  I know Debian isn't officially supported but am hoping that someone out there has got it working.

I still have to investigate further, i.e. wade through the 22MB log file generated, I will post more info as I acquire it but if anyone out there has any suggestions, any help would be appreciated.

Comments 5 CommentsJump to latest comment

bsapach's picture

This doesn't appear to be an issue with 64bit systems.... still testing though.

bsapach's picture

stack dump during testing - on a 64-bit virtual machine:

*** glibc detected *** /opt/VRTSralus/bin/beremote: free(): invalid pointer: 0x00000000023038f0 ***

======= Backtrace: =========
/lib/libc.so.6[0x7f0336ecd928]
/lib/libc.so.6(cfree+0x76)[0x7f0336ecfa36]
/opt/VRTSralus/VRTSvxms/lib/libvfutil.so(vf_newpgn+0x372)[0x7f0335d27d05]
/opt/VRTSralus/VRTSvxms/lib/libmap.so[0x7f0335c13c79]
/opt/VRTSralus/VRTSvxms/lib/libmap.so[0x7f0335c143cf]
/opt/VRTSralus/VRTSvxms/lib/libmap.so(vfx_open_file_name+0x6d)[0x7f0335c14530]
/opt/VRTSralus/VRTSvxms/lib/libvfutil.so(vf_open_file_name+0x8f)[0x7f0335d2b579]
/opt/VRTSralus/bin/libbedsvx.so(_Z15vfmOpenFileNamePKcPP7vfm_objiPiPKv+0xe)[0x7f0339bf285e]
/opt/VRTSralus/bin/libbedsvx.so(_ZN2VX15vx_open_by_nameEPcPPNS_9VX_OBJECTEs+0x13f)[0x7f0339bee28f]
/opt/VRTSralus/bin/libbedsvx.so(_Z16VX_FindFirstFileP16FSYS_HAND_STRUCTPP11HDIR_STRUCTPcS4_PN2VX14VX_FILEFINDBUFEPb+0x389)[0x7f0339be72f9]
/opt/VRTSralus/bin/libbedsvx.so(_Z10FindObjectP16FSYS_HAND_STRUCTP4DBLKPcsit+0xb5)[0x7f0339be7475]
/opt/VRTSralus/bin/libbedsvx.so(_Z13VXX_FindFirstP16FSYS_HAND_STRUCTP4DBLKPwtit+0xb4)[0x7f0339be7884]
/opt/VRTSralus/bin/libbedsvx.so(_Z12VX_FindFirstP16FSYS_HAND_STRUCTP4DBLKPwt+0x44)[0x7f0339be77c4]
/opt/VRTSralus/bin/libndmp_loops.so(_ZN27SpecialObjectsBufferVisitorI11BaseMatcherEclEv+0x74d)[0x7f033909ff5d]
/opt/VRTSralus/bin/libndmp_loops.so(_ZN14BackupDirectorI11BaseMatcher7FsActorE16PerformCDBBackupEv+0x14e)[0x7f03390a3bee]
/opt/VRTSralus/bin/libndmp_loops.so(_ZN14BackupDirectorI11BaseMatcher7FsActorEclEv+0x330)[0x7f033909af60]
/opt/VRTSralus/bin/libndmp_loops.so(_Z12LP_BackupDLEP3BSDP6LP_ENVtPvP16HANDLER_RESPONSE+0x878)[0x7f033909a1b8]
/opt/VRTSralus/bin/libndmp_loops.so(_Z11LP_DoBackupP17NdmpdModuleParams+0x92b)[0x7f03390ad89b]
/opt/VRTSralus/bin/beremote[0x425316]
/opt/VRTSralus/bin/beremote[0x4154e4]
/opt/VRTSralus/bin/libndmpcomm.so[0x7f0338f4587a]
/opt/VRTSralus/bin/libndmpcomm.so(_Z19ndmpProcessRequestsPv+0x23)[0x7f0338f44a43]
/opt/VRTSralus/bin/beremote[0x411943]
/opt/VRTSralus/bin/beremote(_Z11ndmpdSelectP12NdmpdSessioniij+0x2dc)[0x42d03c]
/opt/VRTSralus/bin/beremote[0x4118ca]
/opt/VRTSralus/bin/libvxACEI.so.3(_ZN18ACE_Thread_Adapter8invoke_iEv+0x50)[0x7f033c333ee0]
/opt/VRTSralus/bin/libvxACEI.so.3(_ZN18ACE_Thread_Adapter6invokeEv+0x5a)[0x7f033c333e4a]
/opt/VRTSralus/bin/libvxACEI.so.3(ace_thread_adapter+0x9)[0x7f033c2fbe69]
/lib/libpthread.so.0[0x7f033ae11fc7]
/lib/libc.so.6(clone+0x6d)[0x7f0336f2959d]
======= Memory map: ========
00400000-00452000 r-xp 00000000 03:01 3734831                            /opt/VRTSralus/bin/beremote
00551000-00556000 rw-p 00051000 03:01 3734831                            /opt/VRTSralus/bin/beremote
00556000-005c5000 rw-p 00556000 00:00 0
022a5000-02485000 rw-p 022a5000 00:00 0                                  [heap]
406c6000-406c7000 ---p 406c6000 00:00 0
406c7000-40ec7000 rw-p 406c7000 00:00 0
40ec7000-40ec8000 ---p 40ec7000 00:00 0
40ec8000-416c8000 rw-p 40ec8000 00:00 0
41da5000-41da6000 ---p 41da5000 00:00 0
41da6000-425a6000 rw-p 41da6000 00:00 0
425a6000-425a7000 ---p 425a6000 00:00 0
425a7000-42da7000 rw-p 425a7000 00:00 0
42da7000-42da8000 ---p 42da7000 00:00 0
42da8000-435a8000 rw-p 42da8000 00:00 0
435a8000-435a9000 ---p 435a8000 00:00 0
435a9000-43da9000 rw-p 435a9000 00:00 0
7f0330000000-7f0330021000 rw-p 7f0330000000 00:00 0
7f0330021000-7f0334000000 ---p 7f0330021000 00:00 0
7f03357dd000-7f03357e6000 r-xp 00000000 03:01 896057                     /opt/VRTSralus/VRTSvxms/lib/map/librawp.so
7f03357e6000-7f03358e5000 ---p 00009000 03:01 896057                     /opt/VRTSralus/VRTSvxms/lib/map/librawp.so
7f03358e5000-7f03358e7000 rw-p 00008000 03:01 896057                     /opt/VRTSralus/VRTSvxms/lib/map/librawp.so
7f03358e7000-7f03358f3000 r-xp 00000000 03:01 896056                     /opt/VRTSralus/VRTSvxms/lib/map/libgfsp.so
7f03358f3000-7f03359f3000 ---p 0000c000 03:01 896056                     /opt/VRTSralus/VRTSvxms/lib/map/libgfsp.so
 
# cat /etc/debian_version
5.0.4
# uname -a
Linux web01 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64 GNU/Linux

So apparently it's not strictly on x86 systems, just more likely.

Dev T's picture

Synthetic backup is combining all Incremental backups to one Full backup. Windows based backups works on Archive bit, this is possible in Windows Backups.

Synthetic backup is not possible in Linux/Unix backups as there is no archive bit mechinism in Linux or Unix.....

Conclusion : Linux does not understand Archive Bit so we wont be able to perform Synthetic backups...

 

hope this helps...

Its a best practice to have a "Support Contract" with Symantec...
 

sazz.'s picture

Synthetic backup is possible for LINUX/UNIX

Please read this article http://support.veritas.com/docs/276382 and it will explain how it takes care off archive bit.

You might not have it configured correctly please check the page 879 of admin guide

http://support.veritas.com/docs/276382

Chris Riley's picture

FYI

This is a known issue currently under investigation:

http://support.veritas.com/docs/336079