I feel like I am waiting for a doctor to come out of a room where my wife has been giving birth, and tell me that it's done and all is well... somebody please say something
UPDATE: This thread was moved here from the closed beta forum, so that everyone could see some expected numbers, as well as read through the feedback from users who have been using version 4.0 for over 1 month now.
Replication is working fine.. had a few issues where my previous backup solution ( heeh ) made some snapshots that were not deleted,So I also deleted all my replicas and started afresh and i can report good speed improvement.
OLD VERSION
Total size of VMs to backup: 462.12 GB
Processed size: 462.12 GB
Avg. performance rate: 56 MB/s
Start time: 9/23/2009 4:30:15 AM
End time: 9/23/2009 6:51:20 AM
NEW VERSION
Total size of VMs to backup: 486.12 GB
Processed size: 486.12 GB
Avg. performance rate: 80 MB/s
Start time: 9/23/2009 1:50:38 PM
End time: 9/23/2009 3:34:11 PM
Trevor, thanks - this is great! I guess this improvement is mostly due to native thin-provisioning support in your case.
Is this for vStorage API SAN mode, and compared to VCB SAN mode?
Also, have you tried incremenal passes with changed block tracking (or you are not on ESX4 yet)?
vStorage API SAN mode with block tracking ill do some others passes tonight... in fact ill kick another pass off now but i did play with this earlier and the SAN was gettign over 200m/b as the data hand not been changed.... the SAN has never worked soo hard!
Total VM size: 32.00 GB
Processed size: 32.00 GB
Avg. performance rate: 369 MB/s
Start time: 9/23/2009 4:30:26 PM
End time: 9/23/2009 4:31:55 PM
Obviously no data had changed on this VM so not surprising but ill run soem backups overnight and send you the findings tomorrow. Also i have scrapped my Main FULL nightly backup and use the new AP for that with block change tracking and forward you that info aswell
Woa! First backup of a new VM. WIn2k8 R2 64bit. VM version 7, our whole VMWare environment is already on vSphere.
VM was Thin Provisioned. Presented size is 24GB, but actual space is approx. 8GB.
Initial full resulted in 190MB/s speeds! (obviously because of native thin)
Then put the VM on an 5-hourly backup schedule. Next pass was 435MB/s, then 506MB/s.
Or to put it in another way, complete backup of the 24GB VM took exactly 1 minute and 2 seconds...
Fook mee!!
Our test SAN is really slow, it is always interesting to see statistics from a better hardware. So I am equally impressed, even though these numbers were expected (in theory).
Now for a even better one (for me).
SAN backups of VMs WITH disk exclusions.
Where is this used? On all servers that have their own backup solutions of the data kept on the servers. Examples are database servers and exchange servers. Here we only backup C: via Veeam Backup, and backup the other disks via other backup solutions.
What did we have to do earlier? Exclusion backups were only supported over network. With gigs and gigs of C:-disks to back up, this took a while...
What now? Veeam 4b1 supports disk exclusions even in SAN mode (vSphere API)!!
First backup of our two main mailbox servers. Both C:-drives are 68GB. Avg. speed was 58MB/s. Took 41:30 to complete. These servers are not thin provisioned.
That's right, disk exclusions work "properly" in vStorage API mode (unlike VCB mode, where it pulls down data for all VM disks even if you are backing up only one).
glemmestad wrote:...servers that have their own backup solutions of the data kept on the servers. Examples are database servers and exchange servers...
Quick question about this... why are you doing this, for item-level recoveries, or for something else? What if Veeam Backup could provide appliation item-level recoveries from full image backup, would you still be performing separate backups for some other reasons?
In other words, what should we add to Veeam Backup to make you drop those other tools and do nothing but image-level backups with our product?
Database backups:
- MSSQL - performed via Quest LightSpeed
- Oracle - performed via built-in Oracle-functions
- DB2 - performed via built-in DB2-functions
Exchange backups:
- performed via Legato / BackupExec (in transission at the moment)
I don't know if any of those would be good to have in Veeam; I'd have to have a think about it. I don't mind having those separate.
Showed my manager the speed of the initial backup of the Exchange server (disk exclusions), as mentioned above.
60MB/s now, vs. 15-20MB/s earlier (network).
Incremental (the one that worked) clocked in at 291MB/s.
This is an actual server that have many users changing data.
Before, backup took 1 hour and 15 minutes. Now, incremental backup takes 4 minutes!!!!!
Tried WebUI now. Managed to fire off a backup job from it. Looks very impressive! And what I like most about it is that is lightning fast!
You can deep dive into the various jobs, VMs, and so on. Very easy to use; no manual needed.
Too bad you can't attach pictures here, cause then I could show you how it looks here. Only complaint I have is that seeing as backups are so fast (4-500MB/s) they just show up as up-n-down points on the graph... they're just too quick and hard to graph over time
Glad you are liking it yes, bigger backup jobs will look much better on the graphs!
Alternatively we can slow down backups a little, to make the graphs look nicer for small jobs
Change block tracking with virtual machines, I would dare state, is a totally new way of looking at things. It's literally next generation backups.
The backup of the 666GB VM went off as scheduled today at 6pm.
sfkfil04 - Filserver Konsolidering Success 25.09.2009 18:00:47 25.09.2009 18:15:07 10 10 666,00 GB 666,00 GB 793 MB/s
That's right... 15 minutes... 666GB... insane!
One would think results such as those below would be prohibited by Einstein's theory of Special Relativity. Obviously a workaround to this theory has been discovered by Veeam.
This is exactly what makes our "near-CDP replication" work... if you schedule the replication job to run very often, there will be very little changes between runs, and so you will be able to schedule job to run as often as every 5-15 mins even for huge VMs like this one.
Have to say that when using the vStorage api backup way the speed is improving compared to the old fashioned 'vcb way'. I have been testing several things right now and it looks good so far.
Now I will go on with the web interface and see what this one brings my organization.
Keep you informed
I know I'm behind the curve here, but got everything installed (web ui and all), running backup jobs, and am *extremely* impressed. I've been going through and testing all of the things that have nagged me in the past, and so far it looks like most everything is resolved.
The Web UI daily e-mail was a great touch! Will save my e-mail box.
Few minor constructive critisisms:
-There's a lot of opportunity for offering further help information throughout the program. I could get into details if you're really interested, but for instance, powershell, job variables for notes, snapshot safe removal, vm quiese, integrity checks, etc...
-The scheduling engine for running multiple jobs per day could still offer more precision.