Results 1 to 8 of 8

Thread: Window Client Backup Fails - return error code 260

  1. #1

    Default Window Client Backup Fails - return error code 260

    Hi,

    I am experiencing the following error when trying to backup from a windows client:

    Code:
    tighelaptop.intranet.peteandnicki.com "D:/" lev 0 FAILED [return error code 260]
    sendbackup: start [tighelaptop.intranet.peteandnicki.com:D:/ level 0]
    sendbackup: info BACKUP=pkzip
    sendbackup: info RECOVER_CMD=Extract with zmanda windows client or unzip program
    sendbackup: info end
    | Total bytes written: 2665199270 (2602733KiB, 12396275KiB/s)
    sendbackup: error [return error code 260]
    sendbackup: size 2602733
    sendbackup: end
    The logs on the client shows that Amanda planner/dumper has done a complete file search and starting to dump data to the server. The last few lines of the client logs report:

    Code:
    2572:6792:02:50:450:FS: NTFS: GetAttributes: GetAttributes of d:\admin\appdata\local\zimbra\zdesktop\jetty\logs\access_log.2009-09-17
    2572:6792:02:50:450:FS: NTFS: GetAttributes: GetAttributes is Sucessful
    2572:6792:02:50:450:FS:NTFS:Read Streams:Opening file for reading
    2572:6792:02:50:450:\\?\d:\admin\appdata\local\zimbra\zdesktop\jetty\logs\access_log.2009-09-17
    2572:6792:02:50:451:FS: NTFS: ReadStreams: Reading metadata streams for file d:\admin\appdata\local\zimbra\zdesktop\jetty\logs\access_log.2009-09-17
    2572:6792:02:50:451:FS: NTFS: ReadStreams: Reading metadata stream 3
    2572:6792:02:50:451:FS: NTFS: ReadStreams: Done reading metadata stream 3
    2572:6792:02:50:451:FS: NTFS: ReadStreams: Done reading metadata streams
    2572:8168:02:50:461:Coming out of CompressBackupJobInThread
    2572:6080:02:50:461:SF: Pkzip: EndFormat: Some file is still not closed
    2572:6792:02:50:466:Coming out of Async Thread
    2572:2780:02:50:468:CServiceSessionMgr : Disk list Entry = 02FAC3F0
    2572:2788:02:50:470:RemoveStaleClient : Last error code is 
    2572:2788:02:50:470:The operation completed successfully.
    
    2572:2788:02:50:470:Communication Layer : Connection closed by server.
    The logs on the server are cryptic to me. Watching the log files using tial -f shows me that this is the last message posted before failure occurs - in dumper.debug:

    Code:
    1255343720.745220: dumper: security_streaminit(stream=0x8869a38, driver=0x151860 (BSDTCP))
    1255343720.745238: dumper: security_streaminit(stream=0x8871a70, driver=0x151860 (BSDTCP))
    1255343720.745258: dumper: security_streaminit(stream=0x8879aa8, driver=0x151860 (BSDTCP))
    1255343720.745273: dumper: security_close(handle=0x8858fc0, driver=0x151860 (BSDTCP))
    1255343720.745285: dumper: security_stream_close(0x8861a00)
    1255343720.761468: dumper: Building type 3 (FILE) header of size 32768 using:
    1255343720.761495: dumper: Contents of *(dumpfile_t *)0x80525e0:
    1255343720.761507: dumper:     type             = 3 (FILE)
    1255343720.761518: dumper:     datestamp        = '20091012213047'
    1255343720.761540: dumper:     dumplevel        = 0
    1255343720.761551: dumper:     compressed       = 0
    1255343720.761561: dumper:     encrypted        = 0
    1255343720.761571: dumper:     comp_suffix      = 'N'
    1255343720.761580: dumper:     encrypt_suffix   = 'N'
    1255343720.761590: dumper:     name             = 'tighelaptop.intranet.peteandnicki.com'
    1255343720.761601: dumper:     disk             = 'D:/'
    1255343720.761643: dumper:     program          = 'pkzip'
    1255343720.761654: dumper:     application      = ''
    1255343720.761664: dumper:     srvcompprog      = ''
    1255343720.761674: dumper:     clntcompprog     = ''
    1255343720.761683: dumper:     srv_encrypt      = ''
    1255343720.761693: dumper:     clnt_encrypt     = ''
    1255343720.761702: dumper:     recover_cmd      = 'Extract with zmanda windows client or unzip program'
    1255343720.761713: dumper:     uncompress_cmd   = ''
    1255343720.761725: dumper:     encrypt_cmd      = ''
    1255343720.761735: dumper:     decrypt_cmd      = ''
    1255343720.761744: dumper:     srv_decrypt_opt  = ''
    1255343720.761754: dumper:     clnt_decrypt_opt = ''
    1255343720.761763: dumper:     cont_filename    = ''
    1255343720.761772: dumper:     dle_str          = <dle>
      <program>DUMP</program>
      <disk>D:/</disk>
      <level>0</level>
      <auth>bsdtcp</auth>
      <compress>FAST</compress>
      <record>YES</record>
      <index>YES</index>
    </dle>
    
    1255343720.761783: dumper:     is_partial       = 0
    1255343720.761793: dumper:     partnum          = 0
    1255343720.761802: dumper:     totalparts       = 0
    1255343720.761812: dumper:     blocksize        = 32768
    1255343927.699392: dumper: security_stream_seterr(0x8869a38, EOF)
    1255343927.727736: dumper: security_stream_close(0x8869a38)
    1255343927.727801: dumper: security_stream_seterr(0x8879aa8, EOF)
    1255343927.727814: dumper: security_stream_close(0x8879aa8)
    1255343928.330473: dumper: security_stream_seterr(0x8871a70, EOF)
    1255343928.330530: dumper: security_stream_close(0x8871a70)
    1255343928.330619: dumper: putresult: 10 FAILED
    1255343928.434605: dumper: getcmd: QUIT ""
    1255343928.434702: dumper: pid 24251 finish time Mon Oct 12 21:38:48 2009
    The size of the backup being performed on the client is best summarised by the result of my recent workaround robocopy backup:


    Code:
                    Total    Copied   Skipped  Mismatch    FAILED    Extras
         Dirs :      7641      6854       779         0         8         0
        Files :     53254     48822      4432         0         0         0
        Bytes :  45.457 g  45.052 g  414.92 m         0         0         0
        Times :   1:45:59   1:41:12                       0:00:00   0:04:46
    
        Speed :             7965672 Bytes/sec.
        Speed :             455.799 MegaBytes/min.
    
        Ended : Tue Oct 13 00:36:58 2009
    Backups from windows clients were working in the past. Recent changes to my system:
    - Increase in windows client data from 25GB to 50Gb
    - Upgraded from Fedora Amanda 2.6.0 to RHEL amanda 2.6.0p1.

    Have tried the following to eliminate possible causes:
    - Turned off all firewalls
    - Reinstalled server amanda (on Linux RHEL)
    - Reinstalled client amanda on Windows Machine (Vista)
    - Robo copied all data from Windows client to Linux server, then backed up the data from Linux using amanda (worked) - which seems to confirm I have the disk/tape space
    - Forward and reverse nslookup of server and client from server and client
    - Increased ctimeout, dtimeout and etimeout values in conf
    - Ensured maxdumps is not in amanda.conf (never was)
    - Removed inparrellel option from amanda.conf (was 4)

    Attached are the debug logs and my amanda.conf.

    Thanks in advance.
    Attached Files Attached Files

  2. #2
    Join Date
    Sep 2008
    Posts
    70

    Default

    Hello GreyHairedTiger,
    I check out the client logs, and found that you have been attempting to backup open files, most of which were open during the backup. Backup of these files have failed due to the fact that snapshot creation had failed earlier.

    Can you tell me if VSS Service is disabled or in manual state ? Please toggle the state of the VSS Service (Start -> Run -> services.msc -> Volume Shadow Copy) to manual state, in case disabled.

    If it is manual/automatic, then I would require a copy of the logs to find out why snapshot creation is failing.

    Gokul.

  3. #3

    Default

    Hi Gokul,

    Thank you for your ideas - particularly about the open files - that helped me track down the issue. I solved the problem by uninstalling Zimbra Desktop on the client PC.

    Zimbra Desktop installs itself into the user's data directory, rather than in C\:Program Files. It then installs itself as a service - leaving a lot of files open in the user's data directory. It seems that it has so many files open that Amanda gives up on the backup. Previously, I've had files open on the windows client and amanda would just skip them and produce a "strange dump summary report". It seems the large Zimbra number of open files and/or because they are locked up with a windows service has caused the issue. For now we have dumped Zimbra desktop client (which we weren't too pleased with anyway).

    I first tried your suggestion of turning on the VSS Service. It was disabled, and we set it to automatic. It made no improvement. I have previously run amanda backups (for over 1 year) successfully with VSS disabled. So I am not convinved it is required. If it is, I'd like to see some explaination from the Amanda team at [URL="http://wiki.zmanda.com/index.php/Zmanda_Windows_Client"]http://wiki.zmanda.com/index.php/Zmanda_Windows_Client[/URL].

    Thanks for your help. The generosity of forum users still astounds me. Thank you.

  4. #4
    Join Date
    Sep 2008
    Posts
    70

    Default

    Switching "VSS Service" to "Manual" mode should allow you to take backup of open files through Zmanda Windows Client. In case ,you are still facing problems of open file backups (after switching VSSService to Manual mode) , we would want to take a look at your client logs.

    Gokul.

  5. #5
    Join Date
    Sep 2006
    Posts
    72

    Default

    Quote Originally Posted by GreyHairedTiger View Post
    Hi Gokul,

    Thank you for your ideas - particularly about the open files - that helped me track down the issue. I solved the problem by uninstalling Zimbra Desktop on the client PC.
    Pl. read the answer to Q. 3 of the following FAQ for Zibra Desktop.

    [url]http://wiki.zimbra.com/index.php?title=Synchronizing_Data_on_Yahoo!_Zimbr a_Desktop_FAQ[/url]

    They are asking to shutdown their service before taking any file based backups.
    Last edited by harsha; October 21st, 2009 at 01:32 AM.

  6. #6
    Join Date
    Sep 2006
    Posts
    72

    Default

    Here is the link.

    [url]http://wiki.zimbra.com/index.php?title=Synchronizing_Data_on_Yahoo%21_Zim bra_Desktop_FAQ[/url]
    Last edited by harsha; October 21st, 2009 at 01:37 AM.

  7. #7
    Join Date
    Sep 2006
    Posts
    72

    Default

    [url]http://wiki.zimbra.com/index.php?title=Synchronizing_Data_on_Yahoo%21_Zim bra_Desktop_FAQ[/url]

  8. #8

    Default

    Thank you so much for your feedback and assistance.

    First to Harsha:

    Pl. read the answer to Q. 3 of the following FAQ for Zibra Desktop.
    [url]http://wiki.zimbra.com/index.php?tit...ra_Desktop_FAQ[/url]
    That very article from Zimbra was one of about 3 reasons we decided to dump Zimbra desktop. It is simply not workable/scalable into our environment. Another reason is that Zimbra desktop requires some "post install modification" in order to work on a multi-user windows machines - such machines are typical in enterprise network domains. We've read that the next version of Zimbra desktop will solve the multi-user issue.

    We use Zimbra server, and will probably invest in the outlook connector for now.

    Secondly to Gokul:

    Switching "VSS Service" to "Manual" mode should allow you to take backup of open files through Zmanda Windows Client. In case ,you are still facing problems of open file backups (after switching VSSService to Manual mode) , we would want to take a look at your client logs.
    We tried both "automatic" and "manual" - neither worked. Thank you for your very kind offer to read through our logs. However, we have moved on now, dismantled our test environment and accepted the consequences of moving away from Zimbra desktop.

    Zamanda backup is running without a hitch now - and I must say is pretty terrific software.

    To All Contributors:

    Thanks again for all your help. It really is very much appreciated.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •