Real NFS support for legacy and new backup systems
Currently, even though the word "NFS" is mentioned in both configuration pages of the Legacy and New backup pages, NFS is not actually supported by cPanel. Because of this, issues with the backup system are not being properly supported, as they are seen to be using an NFS mount, and it is automatically blamed.
Please add complete NFS support for backups, including choice of NFSv3 or NFSv4 so that we can create appropriate backup solutions for our end-users to respond to server failures, and disk space usage as necessary.
Additionally, please research appropriate NFS mount options so that the best speed, locking, and failure detection/recovery can be achieved with various NFS mounts and software.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
Could you please elaborate on the errors/problems you're running into with NFS? I personally have had success and know of many others who have had success utilizing NFS mounts to store cPanel & WHM generated backups.
With regard to mount options, cPanel & WHM makes no effort to determine or configure optimal mount options for any drives, NFS or otherwise. In many cases, this would require knowing characteristics that the server itself couldn't possibly know or making wild assumptions. In turn, this is not something we will be pursuing and is something we've historically considered to be the role of the operating system/server owner. It certainly does require some human investigation and intervention to determine ideal mount options. Whatever mount options you have specified in /etc/fstab will, of course, be obeyed when cPanel & WHM issues a mount command (if needed). Simply configure your mount options for your NFS mount to its ideal in /etc/fstab and they will persist.
Could you please elaborate on the errors/problems you're running into with NFS? I personally have had success and know of many others who have had success utilizing NFS mounts to store cPanel & WHM generated backups.
With regard to mount options, cPanel & WHM makes no effort to determine or configure optimal mount options for any drives, NFS or otherwise. In many cases, this would require knowing characteristics that the server itself couldn't possibly know or making wild assumptions. In turn, this is not something we will be pursuing and is something we've historically considered to be the role of the operating system/server owner. It certainly does require some human investigation and intervention to determine ideal mount options. Whatever mount options you have specified in /etc/fstab will, of course, be obeyed when cPanel & WHM issues a mount command (if needed). Simply configure your mount options for your NFS mount to its ideal in /etc/fstab and they will persist.
Could you please elaborate on the errors/problems you're running into with NFS? I personally have had success and know of many others who have had success utilizing NFS mounts to store cPanel & WHM generated backups.
With regard to mount options, cPanel & WHM makes no effort to determine or configure optimal mount options for any drives, NFS or otherwise. In many cases, this would require knowing characteristics that the server itself couldn't possibly know or making wild assumptions. In turn, this is not something we will be pursuing and is something we've historically considered to be the role of the operating system/server owner. It certainly does require some human investigation and intervention to determine ideal mount options. Whatever mount options you have specified in /etc/fstab will, of course, be obeyed when cPanel & WHM issues a mount command (if needed). Simply configure your mount options for your NFS mount to its ideal in /etc/fstab and they will persist.
Could you please elaborate on the errors/problems you're running into with NFS? I personally have had success and know of many others who have had success utilizing NFS mounts to store cPanel & WHM generated backups.
With regard to mount options, cPanel & WHM makes no effort to determine or configure optimal mount options for any drives, NFS or otherwise. In many cases, this would require knowing characteristics that the server itself couldn't possibly know or making wild assumptions. In turn, this is not something we will be pursuing and is something we've historically considered to be the role of the operating system/server owner. It certainly does require some human investigation and intervention to determine ideal mount options. Whatever mount options you have specified in /etc/fstab will, of course, be obeyed when cPanel & WHM issues a mount command (if needed). Simply configure your mount options for your NFS mount to its ideal in /etc/fstab and they will persist.
My 2 cents:
restoreration of a incremental backup can fail because of the design:
It first creates an temporary directory on the same dir where it copies every thing and then the restoration will be started. NFSv4 is very picky of the ownership and then the restoration could fail. Also it costs a lot of bandwidth
If you make an options to select a temporary/working directory on a local disk, this problem is complety resolved.
The bandwidth issue is also with the incremental backup I think. Also a temporary/working dir on a local disk.
For now we mount all the backup dirs for incremental backups on NFSv3 so the restoration doesn't goes wrong.
So in short:
Give us an option to specify a temporary working dir with incremental backup's. It will fix all bandwidth issues and will speed things up and will use the NFS better and more efficient.
My 2 cents:
restoreration of a incremental backup can fail because of the design:
It first creates an temporary directory on the same dir where it copies every thing and then the restoration will be started. NFSv4 is very picky of the ownership and then the restoration could fail. Also it costs a lot of bandwidth
If you make an options to select a temporary/working directory on a local disk, this problem is complety resolved.
The bandwidth issue is also with the incremental backup I think. Also a temporary/working dir on a local disk.
For now we mount all the backup dirs for incremental backups on NFSv3 so the restoration doesn't goes wrong.
So in short:
Give us an option to specify a temporary working dir with incremental backup's. It will fix all bandwidth issues and will speed things up and will use the NFS better and more efficient.
Hello,
i felt into the same problem.
Can I somewhere define a local /tmp directory cause i also have a NFSv3 mount and i can do backups but i can't restore it.
would be nice if you could give me some hints for that problem.
Hello,
i felt into the same problem.
Can I somewhere define a local /tmp directory cause i also have a NFSv3 mount and i can do backups but i can't restore it.
would be nice if you could give me some hints for that problem.
The new 64 backup system makes NFS performance worce.... It is rsyncing between date folders, so the files are requested and then put again on the nfs server. It takes the backup time instead of 3 hours to more then 16 hours!
Why isn't there been any thought on that before you develop this system?
Why do we need NFS:
Because we have fast storage platform for cpanel hosting, we only want to put "production files" as it is expensive solution. Archive storage we don't want on our blade servers, but on a less expensive solution, like a ZFS NFS server. This works like a charm and we out perform most hosters on speed. It is a real enterprise solution
With the current solution we need to have a local backup storage (expensive) and then move it to the archive storage (inexpensive) that we mirror between datacenters. So the new solution costs us real money. And we could lose more data if a server crashes on the local to remote move.
I am also very shocked that your are planning customer grade solutions like Google Drive and Dropbox instead of supporting enterprise solutions like NFS.
The new 64 backup system makes NFS performance worce.... It is rsyncing between date folders, so the files are requested and then put again on the nfs server. It takes the backup time instead of 3 hours to more then 16 hours!
Why isn't there been any thought on that before you develop this system?
Why do we need NFS:
Because we have fast storage platform for cpanel hosting, we only want to put "production files" as it is expensive solution. Archive storage we don't want on our blade servers, but on a less expensive solution, like a ZFS NFS server. This works like a charm and we out perform most hosters on speed. It is a real enterprise solution
With the current solution we need to have a local backup storage (expensive) and then move it to the archive storage (inexpensive) that we mirror between datacenters. So the new solution costs us real money. And we could lose more data if a server crashes on the local to remote move.
I am also very shocked that your are planning customer grade solutions like Google Drive and Dropbox instead of supporting enterprise solutions like NFS.
Replies have been locked on this page!