[Bacula-users] Backup Slow NFS (HPE StoreOnce 3620 VTL and NFS)
Hello. I have Bacula 11.X on Debian 10. Postgres. Currently I support an LTO8 tape library and a VTL (HPE StoreOnce 3620) emulating LTO5 for 10TB. Everything works well. The HPE StoreOnce 3620 also has NFS service. Which was allocated 4TB of NFS for Oracle servers (rman). The IP of the NFS is 172.16.2.5 The oracle servers mount that Unit. The data to be backed up is approximately 500Gb to 1TB. The backup transfer rate (NFS) is 5Mb / s, but if another native directory on the filesystem is backed up, the rate is 40MB / s, which means that the backup to the mount point is slow. Mount the Mount point on the same Bacula server. And the result is the same: 5Mb / s. The HPE StoreOnce 3620, add a peer-to-peer network port. 10.29.5.2 (Bacula) dedicated network. and activated dedicated port in HPE StoreOnce 3620 point to point with 10.29.5.3. I thought this would improve as Bacula's mount point would be direct at 10.29.5.3. Unfortunately I have the same result. 5mb / s. Writing to NFS (dd if) is 100MB / s. Is it a topic of reading? or upload it? Regards -- # # Sistema Operativo: Debian # #Caracas, Venezuela # # ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Backup Slow NFS (HPE StoreOnce 3620 VTL and NFS)
Hi. Adjust mount.nfs -o rsize=32768 10.29.5.3:/nas/ /NFS/ add-o rsize=32768 Now Backup rate 150MB/s Is this recommended, what am I doing? rsize is a value for reading On Fri, Nov 26, 2021 at 8:37 AM Jose Alberto wrote: > Hello. I have Bacula 11.X on Debian 10. Postgres. > > Currently I support an LTO8 tape library and a VTL (HPE StoreOnce 3620) > emulating LTO5 for 10TB. Everything works well. > The HPE StoreOnce 3620 also has NFS service. Which was allocated 4TB of > NFS for Oracle servers (rman). > > The IP of the NFS is 172.16.2.5 The oracle servers mount that Unit. The > data to be backed up is approximately 500Gb to 1TB. > The backup transfer rate (NFS) is 5Mb / s, but if another native directory > on the filesystem is backed up, the rate is 40MB / s, which means that the > backup to the mount point is slow. > Mount the Mount point on the same Bacula server. And the result is the > same: 5Mb / s. > > The HPE StoreOnce 3620, add a peer-to-peer network port. 10.29.5.2 > (Bacula) dedicated network. and activated dedicated port in HPE StoreOnce > 3620 point to point with 10.29.5.3. > I thought this would improve as Bacula's mount point would be direct at > 10.29.5.3. Unfortunately I have the same result. 5mb / s. > Writing to NFS (dd if) is 100MB / s. > Is it a topic of reading? or upload it? > > Regards > > > -- > # > # Sistema Operativo: Debian # > #Caracas, Venezuela # > # > -- # # Sistema Operativo: Debian # #Caracas, Venezuela # # ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Backup Slow NFS (HPE StoreOnce 3620 VTL and NFS)
On 11/26/21 08:31, Jose Alberto wrote: Hi. Adjust mount.nfs -o rsize=32768 10.29.5.3:/nas/ /NFS/ add -o rsize=32768 Now Backup rate 150MB/s Is this recommended, what am I doing? rsize is a value for reading This would be a recommended and normal NFS performance tuning step, yes. Though backing up over NFS is still not recommended if you have a choice. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Backup Slow NFS (HPE StoreOnce 3620 VTL and NFS)
RMAN exports are hosted on the NFS server. And Bacula mount NFS peer-to-peer to tape backup. On Fri, Nov 26, 2021 at 1:14 PM Phil Stracchino wrote: > On 11/26/21 08:31, Jose Alberto wrote: > > Hi. > > > > Adjust mount.nfs -o rsize=32768 10.29.5.3:/nas/ /NFS/ > > > > add-o rsize=32768 > > > > Now Backup rate 150MB/s > > > > Is this recommended, what am I doing? > > > > rsize is a value for reading > > > This would be a recommended and normal NFS performance tuning step, yes. > Though backing up over NFS is still not recommended if you have a choice. > > > -- >Phil Stracchino >Babylon Communications >ph...@caerllewys.net >p...@co.ordinate.org >Landline: +1.603.293.8485 >Mobile: +1.603.998.6958 > > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- # # Sistema Operativo: Debian # #Caracas, Venezuela # # ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Tape changers for bacula
On 11/25/21 07:10, Tomasz Świderski wrote: > Do you have any proven tape changers working with Bacula? I am talking > about models that are available on the market. My customers and I have always had good luck with Quantum's SuperLoader3 line of products. Basically, anything that presents itself to the kernel as a /dev/sg device node that can be managed by the standard Linux 'mtx' utility will work. Same goes for the drives. AS long as they present themselves as /dev/stX device nodes, and the LInux 'mt' tool can work with them you will be fine. Just remember to run the btape tests to get the best filesize and block sizes for your drive(s) to get the best performance. Best regards, Bill ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Backup Slow NFS (HPE StoreOnce 3620 VTL and NFS)
On 11/26/21 14:53, Jose Alberto wrote: RMAN exports are hosted on the NFS server. And Bacula mount NFS peer-to-peer to tape backup. If at all possible, it would be preferable to back up the NFS-shared volumes using a file daemon running directly on the NFS host. However, if you can't do that, then the best you can do is tune your NFS mounts for throughput as you have. Increasing both rsize and wsize well beyond the default is standard practice to improve NFS performance. Also consider mounting with -o noatime, nodiratime (if supported). File and directory atime updates don't really get you anything useful, and disabling them reduces overhead. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users