A couple of random notes on the product; if I got something out of place or newer version addresses the issue, let me know.
-Rubrik is a "forever delta" technology, meaning it will do one full backup, then from that point forward only backup the changed blocks. EXCEPT when using another storage device for archiving. So if one is using something 'cheap and deep' in terms of storage, say a Synology NAS, Cloudian, or any S3 blob storage, a full backup will occur every 60 jobs or so. The delta chain gets to be too long and time consuming to traverse, so restores become messy. Rubrik's way around this is collapse all of the deltas, them and make another full backup. Not a big deal except when one has multiple 10TB volumes to backup. When those jobs take over a 24 hour period to ingest the impact to the production infrastructure and other backup windows can be a concern. One way to make this less painful is to scale back the number of backups. IE instead of backing up every 3 hours, which means a new backup would occur every 8 days, change it to backup every 12 hours so it only does a full every 30 days.
-"Direct Backup to Archive" means that the backups are stored directly on the secondary storage vs. being stored on the Rubrik then having old backups age off to secondary storage. Rubrik has a checkbox that can only be chosen when creating a SLA. I will mix up the terminology here but "direct archive" isn't necessarily direct-archive. When setting up the SLA's if one doesn't select this option the most current data is stored on the Rubrik and all of the old changed data is on the archive location. This is great if current and prompt restores are needed, however it does eat into ones storage plans. If the direct archive location is chosen during SLA creation the data bypasses the Rubrik, goes to the archive location, and only the meta-data lives on Rubrik. This option cannot be changed midstream, if one changes their mind the SLA needs to be deleted, the data deleted or aged off, and recreate the SLA and backup the target as if it was new.
NetApp API's: like most storage vendors some of their inner secrets have been exposed to third parties for a more efficient ecosystem. Rubrik is one of them, they can utilize the same NetApp snapshots which greatly cuts down the impact to production, the amount of time of processing to scan for changes, and thus quicker backups. Newer versions of SnapDiff API's, V3, may or may not be open to third parties. Leaving companies like Rubrik out in the cold. Not a horribly huge deal, as the Rubrik will just talk to the NetApp like any other target, but again larger backup windows will be needed and more impact to the infrastructure.
Related to the SnapDiff API's. I forget where the actual short coming is but, Rubrik can only utilize the NetApp API's one a single NetApp SVM (Storage Virtual Machine). Some installs have their NetApp setup for multi-tenancy or have have multiple SVM's for DR purposes.
Not necessarily agent free. Rubrik will talk to VM's using the standard VMware VSS and VM level snapshots, so there isn't a need to touch every VM. This yields crash consistent backups. When it comes to granular restores, and the ability to restore Active Directory components, Exchange and SharePoint items, one needs to have both the Rubrik Agent and Rubrik Service installed. The agent will add an additional Volume Shadow Service driver onto the system so it shouldn't interfere with any other production. Installing the agent can be scripted via PowerShell, to make it less painful; the install of the service requires a few clicks from the Rubrik console.
Backing up VM's twice? When it comes to SQL what sort of recovery options does one want? How much space is available? If the desire for table level restore is needed one needs to Rubrik agent and Service installed. A backup job (aka SLA) will need to be created to point at the SQL server, SQL instance, or individual DB. That works great for DB restores, but what if the "you know what" hits the fan and one needs to bring back them entire VM? Well a second backup/SLA needs to be taken at the Vsphere level. In addition to that, can one afford the to back up the complete VM? Or is space going to be tight so backup just the OS drive/VMDK and maybe the SYS and Logs drives?
If one wants the backups to be encrypted, and I don't know why one wouldn't, one must make that decision during setup. It is an all or nothing setting, and during setup is the ONLY time one can turn it on or off.
