Finally, I disabled compression and cause I do a "to File media" backup (not tape media), I unmarked the "spool data" and "spool attributes" options.
And most of all, I specified a working directory for data spooling cause I was always at 100% of /var directory space in use for spooling VSS datas it was like pulling the hand break every 9GB during a spooled job session -----Message d'origine----- De : Lionel PLASSE [mailto:pla...@cofiem.fr] Envoyé : vendredi 24 décembre 2021 09:05 À : bacula-users@lists.sourceforge.net Objet : Re: [Bacula-users] Restore experience report Hi, Ok thanks for this. I will try some different settings. Maybe I'll send back my conclusions for the tests. And if any advises more, I gladly take them ... Best regards Lionel ------------------------------------------- De : Graham Sparks <g...@hotmail.co.uk> Envoyé : jeudi 23 décembre 2021 18:29 À : bacula-users@lists.sourceforge.net Objet : Re: Restore experience report Hi. The backup speed seems reasonable, and the Bacula manual states that restores can reasonably be as much as one-third of the speed of the equivalent backup (https://www.bacula.org/11.0.x-manuals/en/main/Restore_Command.html#SECTION0028900000000000000000). I notice also that you are restoring to an NTFS partition. I'm restoring to XFS or ext4, so I'm not sure if the filesystem NTFS is causing the slower restore. I also notice that you have a lot of files for only 32GB-- ~200,000 files. I'd probably call these "small" files. The smaller the files, the more noticeable file creation and attribute application 'slow-down' will be during the restore process. As far as I know, "Comm Line" compression should be enabled by default, and is only reported to be "None" if the files are already well-compressed. Another option that might help, but that should also be enabled by default, is the "SpoolAttributes = yes" Job directive. I'm sorry, but I've run out of suggestions at this point. Hopefully someone with more experience of troubleshooting transfer speeds in Bacula might have something more concrete to offer. I'm hoping to update to a USB3 HDD dock, so I'll be keeping an eye on transfer speeds to see what difference this makes. -- Graham ________________________________________ From: Lionel PLASSE <mailto:pla...@cofiem.fr> Sent: 23 December 2021 15:28 To: Graham Sparks <mailto:g...@hotmail.co.uk>; mailto:bacula-users@lists.sourceforge.net <mailto:bacula-users@lists.sourceforge.net> Subject: RE: Restore experience report Thanks Yes it's on a blue usb port. I expected too those kind of speed. I can reach 69614.5 KB/s for a Full backup job for this client (620.6 GB) and 3253.3 KB/s for an other. And I just see that the difference is only there is no software compression for the first and 53% for the second. I will look after the compression settings for the jobs. And anthor fact is that my backup job are made 3 by 3. So Does the concurent job affect the performance with perhaps non sequentiel data on the volume ? I keep sudying the question first with compression settings ---------------------------------- De : Graham Sparks <mailto:g...@hotmail.co.uk> Envoyé : jeudi 23 décembre 2021 16:02 À : mailto:bacula-users@lists.sourceforge.net Objet : Re: Restore experience report Thanks for the info. What sort of backup transfer rates are you getting (from your clients to the USB-3 backup disk)? I back up over a 1Gb/s network to a USB2.0 device and get 42MB/s backup. I also get 25MB/s restore (restoring from USB2.0 to a directly-connected SSD), so I'd expect better for USB-3 without a network bottleneck (perhaps Forgive me if it's a silly question, but is the USB-3 drive definitely connected to a USB-3 (blue, or "SS"-labelled) USB port? Picking some very (very) arbitrary figures, I'd expect your results to be around 100MB/s backup and 50MB/s restore according to the set-up you describe. -- Graham ________________________________________ From: Lionel PLASSE Sent: 23 December 2021 13:53 To: mailto:bacula-users@lists.sourceforge.net <mailto:bacula-users@lists.sourceforge.net> Cc: Graham Sparks <mailto:g...@hotmail.co.uk> Subject: RE: Restore experience report Yes you're right, i explain the situation The targeted disk for restauration is a SATA-II directly connected to the mother board with a SATA cable nor USB nor RAID but directly to the SATA controller, it's a small extension to the front of the computer. The backup media volumes are usb disk volume and stored on USB-3 disks . This USB disk (XFS formatted) contains the volume file and all bsr and backup of bacula conf . It is automatically mounted by linux when plugged on the storage dir . One USB disk file with one media volume file. All my dayly jobs (9jobs for 9 clients) are run on the volume every day : Incremental from Mon to Thu and Differental the Friday and each first Friday it is a Full instead of Diff Bacula-dir sd fd and mariadb are on the same server I restore on the same machine from the USB volumes to the hotplugged SATA disk. I thought that because of all the restauration process has been made on the same server it will be faster ... ------------------ De : Graham Sparks <mailto:g...@hotmail.co.uk> Envoyé : jeudi 23 décembre 2021 14:00 À : mailto:bacula-users@lists.sourceforge.net Objet : Re: Restore experience report Hi, I think a little more info is needed to narrow down whether or not these restore transfer figures are slow in this particular case. How is the hotplug SATA-II restore disk connected (RAID controller, or USB), and is it connected to the bacula server directly, or through a client? Also, where/how is the backup data stored? -- Graham ________________________________________ From: Lionel PLASSE Sent: 23 December 2021 09:35 To: mailto:bacula-users@lists.sourceforge.net <mailto:bacula-users@lists.sourceforge.net> Subject: [Bacula-users] Restore experience report Hello, I just post my full restore experience for performance studying purpose. I use Bacula 9.6.6.3 & - 10.3.30-MariaDB on a Debian 11 buster x64 i5-2320 3Ghz CPU - 32GB ram For the 1st restoration (by baculum wizard interface) FULL on Western Digital Blue 500Gb (DOS partition table and NTFS partition) : Where: /srv Replace: Never Start time: 22-déc.-2021 09:19:43 End time: 22-déc.-2021 12:04:47 Elapsed time: 2 hours 45 mins 4 secs Files Expected: 202,006 Files Restored: 202,027 Bytes Restored: 32,650,343,324 (32.65 GB) Rate: 3296.7 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK ~2h25 of restoration cause there was 3 volumes in use for restoration (FULL/DIFF&INCR) and I didn't noticed the request of changing volume. The rate is a bit slow I think. (max rate was 5 MB/s) I'm performing now an other full resto with a greater size of restoration on a 4TB Westerndigital Violet (GPT & NTFS partition) The rate is curently 10.62 MB/s Feed back the result this afternoon (I hope) What do you think of the performance, is it possible to do better ? knowing that the restored disk is on a hotplug SATA II interface. _______________________________________________ Bacula-users mailing list mailto:Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
