Part 2 of our summer release schedule is days away! Meet IDR v6.15.
IDR v6.15 boasts quality of life improvements and key fixes. This release removes many common procedures by adding in some automation and/or shorter workflow options. We’ve estimated a reduction of roughly 20 steps across multiple, recurring scenarios, which could easily be 200-500 less tasks performed per year per IDR deployment–money in the bank.
Our ability to turn around such a quick and valuable release is due largely to our terrific community of Partners that continue to be a cornerstone of our mission to eradicate downtime and data loss for businesses of all sizes.
And of course, hats off to our Product and Dev teams for their agile performance and turn-around time!
Quality of Life Improvements
NEW: Automated, Online DDFS compact
Previously, admins would receive a warning/error from the monitoring system saying storage limits have been reached or were close to being reached.
Next, the admin would try to free up some space by deleting jobs and/or would contact support for assistance.
Support would then suggest running “compact” to free up the needed space. Doing so requires shutting down the entire appliance and could take days to complete; roughly 1 day per 1TB of freed space.
By automating the DDFS compact task to take place in the background, we’ve eliminated at least 4 steps (per occurrence) and eliminated downtime during such an event.
NEW: Ability to unlock VMware VM migration option from Appliance
Before a VMware VM is protected, we must disable the ability for a VM to be migrated to ensure the backup is successful. Sometimes, the VM doesn’t properly unlock afterwards, requiring the user to manually unlock the VM by either running another backup or going into vCenter.
While we’re still working on an automated resolution, adding an option to unlock a VM from within our system now allows an administrator to manually unlock the VM in 1 step instead of 2 or 3. We’re working to better avoid the issue altogether in later releases.
NEW: Archive Option – Ability to Pin/Unpin Jobs to be ignored by retention policies
Whether due to a hardware refresh, employee turn-over or some other event, it’s important to be able to retain specific backups despite the retention policy set for them by the client. This new “pinning” feature allows administrators to do just that.
First, a vocab review – within Infrascale IDR, a client is created by defining a retention policy and a schedule for a particular machine (virtual or physical). When a backup runs according to the configured client, that’s called a job. Jobs are stored on the primary and/or secondary for as long as the retention policy indicates.
Pinning a job will exclude it from the retention policies set for that client and will default to keeping that job indefinitely–essentially, an archival option.
For example, if you’re decommissioning a machine but you want, need, to keep a backup for it, you’d pin the jobs you want to keep before removing the client. Compliance, maintained.
This is a first step in many to add more flexibility and customization when needing exceptions at the job-level.
Important note* Like retention policies, pinning jobs is done individually for the primary and the secondary (or cloud) appliances; pinning a job on your primary will not auto-pin the same job on the secondary. Be sure to pin jobs on the appliance where you’ll want the archived job to be kept, or both.
Noteworthy
We’ve also added ‘deleting a client’ as a recorded event in audit logs and removed a few clicks from everyone’s life by adding the firmware version on the login screen in addition to the settings area. Strangely but understandably, we slowed down the initiation of a local boot with a 5 second delay so admins have time to smash into safe mode for some debug.
• UPDATE: Audit logging – added “client deletion” as a new event
• UPDATE: Firmware version is now visible on login screen
• UPDATE: Added 5 second delay before localboot (to access safe mode)
• UPDATE: Change filtering logic by dates in all grids on Appliance interface
BUGS SMASHED
• FIXED: Issues restoring DR image backups with multiple disks
Introduced in 6.14, there was a reported issue wherein a second disk on a DR image backup would timeout during a restore, and we’ve squashed this out.
• FIXED: VMware VMs that have not been powered on will not be protected
This is for all you VM templaters out there. If you upload a VM image to the VMware host, as a template, then this template VM would not be protected by our system until it was powered on. Now, admins can protect their VM templates without doing this step.
• FIXED: Incremental Backup fails on VMware VM with a newly added disk
The workaround for this was to run a full after a new disk was added to a VM. That step is no longer needed.
• FIXED: Hyper-V backup jobs hang/freeze
6.14 introduced new parallel processing to handle multiple jobs at one time. Some of our partners reported instances wherein Hyper-V backups would freeze and this has been resolved.
• FIXED: Improved Replication Process
Customers may not have noticed a problem here as the job would restart where it got stuck and, at most, it would appear that a replication job took a bit longer than expected. We resolved this issue so replication jobs are more stable.
• FIXED: False positive – failed verification status after replication
Verification of jobs would appear failed until an automated task would run after the job was completely closed. We’ve changed this verification step to instead be a part of the backup process, eliminating these false positives from alarming administrators and filling up ticketing queues (and the steps that go with closing them).
• FIX: Hyper-V backup fails if the password had been modified
Not bad for less than 2 months since our last release, eh?
What’s Next?
Good news looking to the 6.16 release set for September/October 2018.
Key highlights for 6.16 are VMware 6.7 support and a new Super Agent with setup and configuration improvements.
Thank you!
-The Infrascale Product Team
