Questions on Solaris Agent limitations

[uk1984]

Hello dear Veeam Team,

we have the task to backup Solaris (spark) physical servers (hosting OracleDB) and I was presenting Veeam as our backup solution to our Solaris Administrator
and has some questions on the limitation of the Veeam Solaris Agent which with the Veeam Support couldn't help us.


The Solaris Admin in our company has read the following document and is preoccupied because of the limitations.
Perhaps you have solutions or workarounds so he can use the product in a for him useful way…

The issues and limitations are taken from this PDF:
https://www.veeam.com/veeam_agent_oracl ... tes_rn.pdf


## General ##

• Veeam Agent for Oracle Solaris does not back up extended attributes and ACL of backed-up files and directories.
• Veeam Agent for Oracle Solaris backs up and restores sparse files as standard data files.
• Veeam Agent for Oracle Solaris backs up and restores file system snapshots as standard data files.x
• If the overall source data size significantly increases in comparison to the size of the data backed up during the previous backup job session, Veeam Agent for Oracle Solaris will create an active full backup.


## Bare Metal Recovery ##

• Bare metal recovery to dissimilar hardware is not supported.
• Bare metal recovery of SVM configurations is not supported.
• Bare metal recovery from backups created from within non-global zones is not supported.
• Bare metal recovery only from file-level backups created by Veeam Agent version 4.0 or later is supported.
• Bare metal recovery requires a backup that includes the full contents of the root directory (the -- includedirs option must be set to /).
• During bare metal recovery, content of ZFS volumes is not recovered
• Paths longer than 1006 symbols cannot be restored during bare metal recovery and must be restored manually afterwards.
• During bare metal recovery, access (atime), modified (mtime) and changed (ctime) timestamps are reset for all non-empty files or
directories.
• After bare metal recovery, you may need to reset, or close and open the OVMM terminal to resolve any possible issues with its behavior.
• [For Oracle Solaris version 11.4.63.157.1 and later] During bare metal recovery, Veeam Agent cannot restore the bootloader. To fix the issue, you must obtain a patch from Veeam Support.

The red marked passages are the main concerns/talk points.
So I will send you what my Solaris Admin thinks about it.

"So my concern is the bare metal recovery. I have a highly important machine (S7-1 Server, SPARC) running Solaris 11.4. We have to comply 99,99% availability. So in case of a hardware
failure or a human error (like rm * in the wrong directory) I have to be able to get the same machine from the backup. Exactly the same, not nearly the same or something similar.

It is a big point that extended attribute and ACL are not included – because that can make the difference that applications won’t run after a reinstall. So what shall I do in case of emergency with those files?

Also it is a big point for me that it seems that the size of the restore could be ways bigger than the original size was. This seems to be possible as a consequence of “sparse files
are restored as standard files” (here a 1 TB sparse file had some KB before and afterwards 1TB), “file system snapshots as standard files” (ZFS snapshots are just references to the blocks, so they don’t use really filesystem space, but afterwards they seem to take real space… and because of the patching system in newer Solaris versions as Solaris 11 and above there are at least those snapshots present which are taken for the boot environments).

And my big concern, although not mentioned in the document, is that if all above is really true, that the VEEAM Backup also does not backup and restore in bare metal restores the ZFS
Filesystem attributes. So afterward there would not only be no longer quotas, NFS shares, SMB shares but probably also no longer possible to start zones as they need the filesystem flag “zoned”. But respect to the filesystem size I also assume that the “compression” and the “dedub” flag aree ignored. So a bare metal restore would also because of those flags be ways bigger.

Not knowing if the latter is true, at least the sparse and snapshot issue could lead to the situation that the drives which were formerly in use are not sufficient for a bare metal restore.
And worse… I also won’t know how much would be sufficient. So I could buy new drives and afterwards also the new ones could be not enough. So a bare metal restore could lead into a disaster of time and of rights (ACL, extended attributes, ZFS attributes…)

Also it could be a disaster if we don’t receive the same hardware… Solaris is normally able to be installed with all available drivers (full install) so a change of hardware would not affect. Do not know, why a boot image could not use that feature also.

And respect to consistency also a problem will be that atime, mtime and ctime is changed so I do not know how the processes on a recovered machine could work. I for example have cronjobs
deleting files in directories which are older than a distinct time. This would no longer work. And this is just an example with which we could live in some way, but there are worse scenarios in mind.

I just do not know why your software does not use in some kind the OS commands like “zfs send” or something like that to backup the filesystems. You could make simply a snapshot of the
whole system, than zfs send the streams to your backup server and fine. There are all ctime, snapshots, sparse and all the other issues from above preserved. And the restore would be an ISO image of some Solaris (does not have to do something with the system itself) with the VEEAM client software installed, perhaps with the key of the broken machine and then starting from that ISO image a “zfs receive” for all the affected filesystems restoring it from your Backup server. All would be fine, no issues and everyone happy.

So please could you explain what is the expected way to restore a broken machine with bare metal recovery with VEEAM so that the machine is afterwards exactly the same. Is this possible or not."


Would be great if you help me address the concerns of my Solaris Admin.
As of now he does not regard Veeam as very suitable solution.

[VAB]

Hi! While I cannot speak for Veeam, I would strongly advise not to use Veeam Backup for Solaris bare metal recovery. The "Agent for Solaris" is not really tuned to Solaris. It is ported from Linux, and it shows in many places. The agent is ZFS-aware, to the point of not working when it encounters a ZFS feature it does not expect, but it does not appear to leverage ZFS in any way. You can, however, backup your global and non-global zones using Unified Archives in an intermediate step. Create the archive in a staging area, then run a backup job to save the archive file. The global zone can be restored via an Automated Installer server, and the non-global zones can be restored on the machine in question.
If you only have one Solaris machine, you will have to be a bit creative about AI restore...

[PTide]

Hi,

Release notes and User Guide are the primary sources of truth, and are factually correct. We may follow up with workarounds for some of the mentioned concerns shortly.

Thanks!

[uk1984]

Hi there,

our Solaris Admin has also had the idea with the AI server as alternative solution.
But it's a bit of a hassle setting that up for only 2 physical Solaris Servers.
It would be better if we could have fulfilled the requirements completely with Veeam.
Would be great if you could work on those limitations...

I hope the Backup of OracleDB is as good as on Linux, then at least we can use Veeam for that.