Added Tags to All Docs
This commit is contained in:
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**: You may find that you need to adopt a device that was onboarded by a different Veeam Backup & Replication server. Maybe the old server died, or maybe you are restructuring your backup infrastructure, and want a new server taking over the backup responsibilities for the device.
|
||||
|
||||
If this happens, Veeam will complain that the device is managed by a different server. To circumvent this, perform the following changes in the Windows Registry based on the version of Veeam Backup & Replication you are currently using, then try to Update the Agent / Backup the agent again, and it should be successful after the registry changes are made.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
The purpose of this document is to explain the core concepts / terminology of things seen in Veeam Backup & Replication from a relatively high-level. It's more of a quick-reference guide than a formal education.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
There may come a time that you need to free up space in a Veeam Backup & Replication backup repository because you are running out of space. In these cases, you need to manually trim the older backups in a specific way to ensure this is non-destructive.
|
||||
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Proxmox
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
When you migrate virtual machines from Hyper-V (and possibly other platforms) to ProxmoxVE, you may run into several issues, from the disk formats being in `.raw` format instead of `.qcow2`, among other things. One thing in particular, which is the reason for this document, is that if you migrate Rocky Linux from Hyper-V into ProxmoxVE using Veeam Backup & Replication, it will break the storage system so badly that the operating system will not boot.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
## Purpose
|
||||
If you find that you need to migrate cloud backups that are being sent to a server running the Veeam VSCP due to issues like exhausted storage space on existing repositories.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This is meant as a high-level generally-speaking best practice retention policy in most use-cases. This document will generally be pretty bare-bones, but the general idea is the following advanced GFS retention period is generally configured on backup copy jobs, specifically ones that have off-site backups, but can also be used for local backup repositories.
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Veeam
|
||||
- Backup
|
||||
- Disaster Recovery
|
||||
---
|
||||
|
||||
### Symptoms
|
||||
When you try to run a backup to a remote backup server, the backup job fails and gives the following error:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user