You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<sup>\*</sup> Any datastore based on files with the given format, i.e., NFS/SAN or Local.
99
+
<sup>\*</sup> While OpenNebula doesn't support backups for raw images, Veeam will perform a full backup and perform block to block comparison to create it's own incremental.
109
100
110
101
<sup>\**</sup> Supported for LVM-thin environments.
111
102
112
103
## Limitations
113
104
114
-
Here is a list of the known issues and limitations affecting the Veeam integration with OpenNebula:
105
+
Here is a list of the limitations affecting the Veeam integration with OpenNebula:
115
106
116
107
- The KVM appliance in step 4.2 does not include context packages. This implies that in order to configure the networking of an appliance, you must either manually choose the first available free IP in the management network or set up a DHCP service router.
117
108
- Alpine virtual machines cannot be backed up.
118
109
- During image transfers, you may see a warning message stating ``Unable to use transfer URL for image transfer: Switched to proxy URL. Backup performance may be affected``. This is expected and shouldn't affect performance.
119
110
- Spaces are not allowed in Virtual Machine names in the integration, so avoid using them (even if they are allowed in OpenNebula itself), otherwise you may face issues when performing an in-place restores of said VMs.
120
111
112
+
If facing other issues or bugs, we highly encourage to check the Veeam section of the [Known Issues page]({{% relref "../../../software/release_information/release_notes_70/known_issues/#backups---veeam" %}}).
113
+
121
114
## Architecture
122
115
123
116
To ensure a compatible integration between OpenNebula and Veeam Backup, the following components and network configuration are required:
@@ -147,7 +140,25 @@ The minimum hardware specifications are:
147
140
148
141
-**CPU:** 8 cores
149
142
-**Memory:** 16 GB RAM
150
-
-**Disk:** Sufficient storage to hold all active backups. This server acts as a staging area to transfer backups from OpenNebula to the Veeam repository, so its disk must be large enough to accommodate the total size of these backups.
143
+
-**Disk:** Sufficient storage to hold all active backup operations. See more details regarding the storage requirement in the next section.
144
+
145
+
### Storage Requirements
146
+
147
+
The Backup Server acts as a staging area between OpenNebula and the Veeam repository. It must provide enough disk capacity and I/O headroom for active backup and restore operations. Follow these practical guidelines when sizing and configuring storage:
148
+
149
+
-**Primary backup datastore** (`/var/lib/one/datastores/<backup-datastore-id>`): this is where OpenNebula writes VM images and incremental chains before Veeam moves them to its repository. Size this datastore to hold the largest set of concurrently active backups you expect.
150
+
151
+
-**Temporary restore area** (`/var/tmp`): when restoring a VM from a Veeam repository into OpenNebula, the restored image is staged here before being moved to the image datastore. Provision this directory to hold at least the largest single disk being restored (or the sum of concurrently restored disks if you will perform parallel restores). You can change this in the `tmp_images_path` parameter in the configuration.
152
+
153
+
-**Retention and duplicate chains**: the backup will exist both in the OpenNebula backup datastore and in the Veeam repository. If you delete the chain from OpenNebula and Veeam subsequently runs an incremental, Veeam will perform a full backup and reconstruct incrementals itself. This increases transfer time but keeps backups consistent. If storage is constrained, schedule regular cleanup of old backup images in the OpenNebula datastore to free space, understanding that this may force full transfers on the next incremental run.
154
+
155
+
-**Cleanup tooling**: the ovirtapi package includes a helper script to automate cleanup of the backup datastore: `/usr/lib/one/ovirtapi-server/scripts/backup_clean.rb`. You can run this script as the `oneadmin` user or schedule it via cron to maintain a maximum used threshold. Example crontab (daily at 00:00) to cap usage at 50%:
Ensure the `ONE_AUTH` variable is set to a valid OpenNebula `user:password` pair with permission to delete backup images. You may adjust `MAX_USED_PERCENTAGE` to a different threshold if desired.
151
162
152
163
## Veeam Backup Appliance Requirements
153
164
@@ -177,8 +188,6 @@ The backup datastore must be created in the backup server configured in step 1.
177
188
Here is an example of how to create an Rsync datastore in a Host named `backup-host` and then add it to a given cluster:
178
189
179
190
```bash
180
-
onedatastore create /tmp/rsync-datastore.txt
181
-
182
191
cat <<EOF > /tmp/rsync-datastore.txt
183
192
NAME="VeeamDS"
184
193
DS_MAD="rsync"
@@ -191,6 +200,8 @@ RSYNC_HOST="localhost"
191
200
RSYNC_USER="oneadmin"
192
201
SAFE_DIRS="/var/tmp"
193
202
EOF
203
+
204
+
onedatastore create /tmp/rsync-datastore.txt
194
205
```
195
206
196
207
2.2. Add the datastore to the cluster
@@ -204,20 +215,7 @@ SELinux and AppArmor may cause issues in the backup server if not configured pro
204
215
205
216
You can find more details regarding the Rsync datastore in [Backup Datastore: Rsync]({{% relref "../../../product/cluster_configuration/backup_system/rsync.md" %}}).
206
217
207
-
**Sizing recommendations**
208
-
209
-
The backup datastore needs to have enough space to hold the disks of the VMs that are going to be backed up. This introduces a layer of redundancy to the backups, as they will be stored in the OpenNebula Backup datastore and the Veeam Backup storage. This is something inherent to the Veeam integration with oVirt, as further backups of a Virtual Machine will be incremental and only the changed disk regions will be retrieved.
210
-
211
-
If storage becomes a constraint, we recommend cleaning up the OpenNebula Backup datastore regularly in order to minimize the storage requirement, but keep in mind that this will reset the backup chain and force Veeam to perform a full backup and download the entire image during the next backup job.
212
-
213
-
We provide alongside the ovirtapi package the ``/usr/lib/one/ovirtapi-server/scripts/backup_clean.rb`` script to aid in cleaning up the backup datastore. This script can be set up as a cronjob in the backup server with the oneadmin user. The following crontab example will run the script every day at 12:00 am and delete the oldest images until the backup datastore is under 50% capacity:
For the ``/usr/lib/one/ovirtapi-server/scripts/backup_clean.rb`` script to work you need to set the ONE_AUTH environment variable to a valid ``user:password`` pair that can delete the backup images. You may also set the ``MAX_USED_PERCENTAGE`` variable to a different threshold (set to 50% by default).{{< /alert >}}
Copy file name to clipboardExpand all lines: content/software/release_information/release_notes_70/known_issues.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,7 @@ OpenNebula uses the `cirrus` graphical adapter for KVM Virtual Machines by defau
47
47
## Backups
48
48
49
49
- Ceph Incremental Backups: Currently, incremental backups cannot be flattened. Support for this functionality is under development and is expected to be included in the next maintenance release.
50
-
- For Veeam related issues, please referer to the [Veeam (EE) page](../../../product/cluster_configuration/backup_system/veeam.md).
50
+
- There are curently no issues reported from the Veeam integration.
0 commit comments