The best way to determine the time is to do a mock restore from your backups onto a test machine to see how long it takes.
The issue here with providing any sort of estimate for you is that every server has different hardware, disk space, backup types and speeds for the network. As such, it's impossible to give you any sort of timeframe. The best suggestion would be to simply do a test restore to a machine that has the same specs as existing one to see how long it takes.
Additionally, this will ensure you know what problems may arise during the restore process, and you'll be better prepared on what steps to take when/if something does fail and you have to do a restore.
The issue here with providing any sort of estimate for you is that every server has different hardware, disk space, backup types and speeds for the network. As such, it's impossible to give you any sort of timeframe. The best suggestion would be to simply do a test restore to a machine that has the same specs as existing one to see how long it takes.
Additionally, this will ensure you know what problems may arise during the restore process, and you'll be better prepared on what steps to take when/if something does fail and you have to do a restore.
I have done this for at least 25 people and for myself 5-7 times. I can tell you this is one of those things that really depends on all of the above. also the size of each account. The load on the machine is also important. If it's a bare metal restore from healthy disks, you may aslo consider a fresh OS and then a rsync of the needed files and folders from the old live drive. If it's coming from backups, the speed would all depend on how big the accounts are. What I typically do is restore the larger accounts first. (assuming the load will be less on the system without any traffic flowing) and then gradually restore to the smallest accounts last. I do them in batches typically like this and I typically watch the entire process. It's not fun.
As a minimum, the traditional sysadmin "rule of thumb" is that restores take 2 to 3 times more than the backup time. No way is 1.5 enough. This is of course a "rule of thumb" so, as the wise posters above have said, hardware and system load will change your results a lot. Under some scenarios, I could envisage that reload from cpbackup tarballs could take up to 10x the backup time.
Many of us do rsync backups to cover us in the event of a need for a full restore. We can restore ~35Gb from rsync from another machine in the same DC in a few hours on an idle machine. From memory rsync is an order of magnitude faster than restore from tarball. If I was looking at this, I'd want to rsync to a local disk and then to a remote machine. The data usage for the remote rsync is pretty low as rsync only transfers the changed data. If you're wanting to use this to transfer from an old server to a new server, do the rsync once from the live server, then do another when you do the move - in the same DC a re-rsync of only the changed data takes 15 mins, over about 35Gb of user files.
Check for our script "cpmr" which I'll re-post soon, which does the remote rsync, taking just cpanel and the home dirs, not the OS itself.
BTW, mostly unrelated and hopefully not annoyingly, if you just want to restore a single file check out my cprevert post here from earlier.
Hope this helps...
| Thread starter | Similar threads | Forum | Replies | Date |
|---|---|---|---|---|
| D | Disaster Migration | Backups | 2 | |
| G | Replicate server for disaster recovery? | Backups | 4 | |
|
Incremental local backups plus disaster remote? | Backups | 3 | |
| S | Server backups + disaster recovery | Backups | 3 | |
| N | disaster recovery backup | Backups | 1 |