Re: [bareos-users] Problem with latest 14.x Windows File Daemon

[lst_hoe02]

Zitat von Philipp Storz <philipp.st...@bareos.com>:

Hello Andreas,

Am 06.11.2014 13:37, schrieb lst_ho...@kwsoft.de:

Zitat von lst_ho...@kwsoft.de:

Hello,


report from this backup:

06-Nov 11:33 bacula-dir JobId 12934: Start Backup JobId 12934,
Job=SHORT-FS01-CD.2014-11-06_11.33.55_11
06-Nov 11:33 bacula-dir JobId 12934: Using Device "FileStorage" to write.
06-Nov 11:33 bacula-dir JobId 12934: Sending Accurate information.


?? We have not set any Registry Key, so why this is happening

today i tested the latest 14.x Beta Windows FD on a Windows 2003 Server. Installation was trouble free, the test incremental worked fine againt our 13.2.2 Director. But the following was the 06-Nov 11:35 bacula-sd JobId 12934: Volume "A20-DATEI" previously written, moving to end of data. 06-Nov 11:35 bacula-sd JobId 12934: Ready to append to end of Volume "A20-DATEI" size=193470490286 06-Nov 11:33 fs01-fd JobId 12934: Created 46 wildcard excludes from FilesNotToBackup Registry key

not need to be backed up.

(see here:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb891959(v=vs.85).aspx#filesnottobackup)

We use that info in that registry key to automatically exclude those files.

There is a standard registry key in windows where windows itself specifies files and dirs that do

(VSS_WS_STABLE)

(VSS_WS_STABLE)

(VSS_WS_STABLE)

(VSS_WS_STABLE)

(VSS_WS_STABLE)

(VSS_WS_STABLE)

bytes ...



4M files...


06-Nov 11:40 bacula-dir JobId 12934: Bareos bacula-dir 13.2.2 (12Nov13):
  Build OS:               x86_64-pc-linux-gnu ubuntu Ubuntu 12.04 LTS
  JobId:                  12934
  Job:                    SHORT-FS01-CD.2014-11-06_11.33.55_11
  Backup Level:           Incremental, since=2014-11-05 19:15:00

Edition Service Pack 2 (build 3790),Cross-compile,Win32
  FileSet:                "FS01-CD" 2012-10-08 14:40:00
  Pool:                   "SHORT" (From command line)

06-Nov 11:35 fs01-fd JobId 12934: Generate VSS snapshots. Driver="Win32 VSS", Drive(s)="CD" VMP(s)=0 06-Nov 11:35 fs01-fd JobId 12934: VSS Writer (BackupComplete): "System Writer", State: 0x1 06-Nov 11:35 fs01-fd JobId 12934: VSS Writer (BackupComplete): "MSDEWriter", State: 0x1 06-Nov 11:35 fs01-fd JobId 12934: VSS Writer (BackupComplete): "Registry Writer", State: 0x1 06-Nov 11:35 fs01-fd JobId 12934: VSS Writer (BackupComplete): "Event Log Writer", State: 0x1 06-Nov 11:35 fs01-fd JobId 12934: VSS Writer (BackupComplete): "COM+ REGDB Writer", State: 0x1 06-Nov 11:35 fs01-fd JobId 12934: VSS Writer (BackupComplete): "WMI Writer", State: 0x1 06-Nov 11:36 bacula-sd JobId 12934: Elapsed time=00:01:24, Transfer rate=7.617 M Bytes/second 06-Nov 11:36 bacula-sd JobId 12934: Sending spooled attrs to the Director. Despooling 979,709,552 ?? The backup included some ~20 files, but the attributes looks like a full backup of the around Client: "fs01-fd" 14.2.1 (12Sep14) Microsoft Windows Server 2003 R2 Standard

  Catalog:                "MyCatalog" (From Client resource)
  Storage:                "File" (From Pool resource)
  Scheduled time:         06-Nov-2014 11:33:51
  Start time:             06-Nov-2014 11:33:58
  End time:               06-Nov-2014 11:40:19
  Elapsed time:           6 mins 21 secs


Much faster then the typical incremental on this machine :-)


  Priority:               10
  FD Files Written:       3,906,478
  SD Files Written:       3,906,478
  FD Bytes Written:       0 (0 B)
  SD Bytes Written:       639,845,966 (639.8 MB)
  Rate:                   0.0 KB/s
  Software Compression:   None
  VSS:                    yes
  Encryption:             yes
  Accurate:               yes



suggest we only have some 20 files in the backup...
The FD/SD Bytes Written are totaly of??

The FD/SD Files Written looks like the total "full" set for this machine. As said and as the times Is this expected behaviour because the 13.2.2 Director or simply some Beta oddity??

that a lot more files have changed :-(

Ouch, rather Beta i guess. Subsequent incrementals find only one file with 0 bytes despite the fact

Hm, very interesting. Can you please give more info on that?

That should definitely not be the case.

Another point is taht the bareos-fd.exe on the Windows client was using ~850M RAM with version 14, the now again working 13.2.3 has only around 30M RAM usage on the same machine??

This should also not be the case.

Looks like you found some very interesting problems with the windows fd.

Would you please create a bug report on the problems?



Thanks for testing bareos!

best regards,

Philipp

If you could describe a test scenario where we can replay the problems of course would be best

Ok, done:

http://bugs.bareos.org/view.php?id=360

Let me know if you need additional information.

Regards

Andreas

smime.p7s
Description: S/MIME Cryptographic Signature