Hi NugentS,

Thank you for re-posting your feedback here. I have already forwarded your suggestions to the developers but answering some of your concerns here will benefit other users who share the same experiences. I will try to be as informative as possible on each of your topics:

1. Absolute paths on QNAP

As you have noticed, QNAP does not disclose the real file path in its GUI. This is unfortunate but there is nothing we can do about it. Even their own knowledge base and user forum suggest using the ssh access and command line to find out the real path when needed. That being said, on most of the devices I have seen, creating folders via QNAP web interface places them in '/share/' but my experience is limited. Different QNAP models (OS versions) or different storage types may have different defaults.

The clue given by Pure is just a sample path making it more obvious that you are expected to enter a full path in that text box. It is the same for all installation types.

Just to make it clear for new users: You are expected to provide a storage for your future VM backups (e.g. folder on your NAS device, network share, local folder, any other type of mount point) and to know the full path to that storage (as seen from the machine hosting Pure) so you can enter it in the Pure configuration.

2. & 6. Managing schedules and backup frequency

Backup scheduling in Pure is organised around the concept of Backup windows. A Backup window is a time slot (with a start time and duration) within which you allow a VM to be backed up. This way you can schedule your backups to be performed in the off-peak hours for your system while still allowing Pure to decide the exact backup order for each particular VM, prioritising those that have gone without backups for the longest.

You can think of Backup windows as meetings and VMs as participants. You select one or more VMs, configure the Backup window (start time, duration and frequency), make sure to check 'Automatic backup is enabled', optionally tick the 'Verify after backup' box and that's it. Your VMs will participate in that Backup window - at the appropriate time, Pure will add all those VMs to the backup queue and will start performing backups (optionally followed by verifications) with the promise of not starting a new backup once the Backup window is over. Any VMs that were not backed up due to a lack of time will have higher priority next time. Normally, once the initial round of full backups is over, subsequent backups are much faster but we do have customers with well over 100GB daily changes per VM. Also, there is nothing preventing you from configuring too short of a Backup window for the number of VMs you put inside so Pure will try its best but if you regularly have some VMs missing a Backup window, adjust its length accordingly.

If you need more than one daily backup, simply configure another Backup window for your VM. There is no limit on the number of Backup windows any single VM may participate in except that Backup windows cannot overlap for any single VM.
Example: VM-1 has a BW1 (start 8:00, duration 2h), VM-2 has the same BW1 (8:00, 2h) but also a BW2 (22:00, 4h). If you were to configure another BW3 (start 20:00, 3h) and try applying it to those VMs, VM1 would be ok but VM2 would complain because the new BW3 overlaps with the already scheduled BW2.

One neat feature is that once you configure a Backup window for at least one of your VMs, that Backup window will appear (deselected) in the list of Backup windows for each of the VMs in GUI (Backup Administration -> Basic), allowing you to easily add the same BW to further VMs.

Upcoming changes

What is probably confusing right now is the fact that you cannot immediately delete a Backup window within GUI. Once created, it persists in the list so you can apply it to more VMs. However, once you restart Pure, only those Backup windows that were actually associated with at least one VM will re-appear while the unused ones will be gone. The exception to this rule are the two default backup windows that come preconfigured from the start (bw1 Mon-Fri 00:00, 6h; bw2 Sat 00:00, 48h). You can, of course, still disable them from your VMs.

Another less intuitive behaviour is the fact that when you edit a Backup window (pencil icon), you do not in fact change the selected BW. Instead, you are creating another BW, using the selected BW configuration as a starting point. This was necessary to avoid inadvertently changing the scheduling of other VMs that are potentially sharing the same BW you are trying to modify. Therefore, editing a BW will create a new schedule that is applied only to the selected VM.

The good news is that we have already introduced significant changes to Backup window management which are scheduled for release with Pure version 2.0.7. Most notably, we no longer enforce caution and provide a delete button to remove the selected Backup window from any VMs and immediately delete if from the list without having to wait for a Pure restart. Changing a Backup window configuration will now immediately take effect on all VMs that share the same BW (just as rescheduling a normal meeting would affect all participants whether they like it or not). You are encouraged to use the 'Filter the List of VMs' tab to check which VMs belong to which BW before changing it.

4. Retention

As I mentioned, I have forwarded your remarks to the rest of the development team. For the time being, retention is simple because Pure performs incremental backups in a linear fashion. Currently, our efforts are focused on cloud support but once that is finished, we will consider adding a more complex backup hierarchy as an option.

5. Version mismatch between NAS vendor app store and Archiware Pure web page

Unfortunately, each of our integration partners has a different application review policy. I assure you that we submit each and every version of Pure to all our NAS partners (currently QNAP, SYNOLOGY and ReadyNAS) as soon as they are released. However, the time necessary for them to approve the app varies greatly from vendor to vendor and also depends on their resource availability. As you have noticed, this time Synology is up to date while QNAP is not, but this is not always the case.

The latest version of Pure can always be found at https://pure.archiware.com/download . Because NAS devices do not allow us to update Pure from within, the best way is to download the appropriate app package for your device and follow the Manual installation steps in our User guide (available on the same web page). Virtual appliance and Linux versions of Pure allow updates from within Pure so you can always stay up to date.

Unsupported Synology Kernel Detected

This means that your version of Synology OS is not fully supported by Pure. In particular, Restore file feature will not work since this requires that the appropriate kernel modules be present. We can compile these modules ourselves but if your device is very old, it is possible we are no longer supporting it.

Multiple instances of Pure in the same vSphere

Running multiple instances of Pure in the same environment is not strictly prohibited but it can lead to unwanted interference. Since neither instance is aware of the others, they will happily backup the same VM simultaneously if you allow them, deleting VM snapshots under each other's feet, tying up virtal disks so the snapshot cannot be properly removed and various other merry surprises. Also, if one of them is performing a backup or a verify of the vCenter VM, it will make that VM unresponsive at times. The Pure performing the backup will be aware of this and will communicate with the ESXi instead but the other one will have connection timeouts.

That being said, now that you know how to create multiple Backup windows you could, with due attention and care, configure two Pure instances to operate within the same vSphere setup as long as they strictly keep out of each other's way.

Sorry for the lack of reply. I have been struggling with something else.

I have been messing with Pure on a variety of platforms. I even tried the Ubuntu App that Archiware distribute which I noticed was unable to back itself up. The Pure Appliance not even appearing in the list of VM's. 

I did however notice that when I trashed the Pure Appliance, and moved to the same version on my Synology, pointing to the same store, then it recovered my backup database (such as it was) from the appliance - which is good

Sean

Hi Sean,

Pure is not seeing itself as a VM and not being able to back up itself per design. We intentionally designed everything so that there really is nothing really important residing on the VM itself. The whole Pure configuration, as you have seen, is kept alongside the backed up data as that is the one place you are bound to keep safe (and if you lost your backup data storage, having Pure config somewhere else won't mean much).

The approach makes a Pure appliance perfectly replaceable. Should you ever need to recover from a serious disaster, you can simply download a fresh copy of Pure off our website, deploy it to your recovery platform, point it to your backup storage and it will continue working exactly where the previous instance left off. This saves you a lot of time (which is bound to be the most precious commodity while you are doing disaster recovery) and makes the recovery process very simple and resilient.

I'm glad that you are discovering Archiware Pure and am looking forward to your feedback.

Marijan

Yeah - I figured that which is one reason I trashed the install and then rebuilt on a different system. I was just a bit surprised it didn't see itself.

I have found pure MUCH more reliable on an old synology, rather than as an appliance on VMWare. I kept getting backup failures on the appliance, but it works great (if slowly, and that's a problem with the synology I think) from the NAS. I was using a remote NFS share on the NAS as a backup target from the appliance and MAY not have been using NFS4 (I don't know and not sure how to tell) but as I prefer running the app away from the system I am trying to backup this is hardly an issue.

I am surprised that the VM version of Pure is less reliable for you. Please make sure you ARE running the version 4 of NFS, as explained here. Executing 'nfsstat -m' should tell you which version you are using (it might show you all supported versions so check which one is actually being used and which ones have 0 calls).

If you continue experiencing any issues once you switch to the correct NFS version, I would be very interested in hearing about them. Let me know and we can arrange for you to send your log files.

Oops - sorry didn't spot this.

I have had to terminate testing on the old Synology. Its just too slow. Reliable but waaaay to slow. To be fair - I did sort of expect this, as its a Synology from 2011 and things have got quicker since then.

I'll have another looking at the appliance and see whats what. Unfortunately I seem to have deleted it, not that it takes long to re-create.

Sean

I think I can put the problem down to lack of NFS4.

I have now specifically set NFS 4 in fstab and the backups seem to be:

1. Reliable in that I have 100% success

2. Much quicker

Yup - backups are a lot more reliable.

I do notice that it tends to fail quite often when backing up the VCSA.

Also, as an aside, - I have a lot more consolidation required warnings than my previous solution. Everytime I check there are normally one or two.