How can I replace failing servers with immutable backups?

[sarnold]

I have a site with some old Linux servers in a SOBR that are configured for immutability for a certain number of days, in addition to the immutable GFS backups that reside on them. The hardware is aging and needs to be replaced, so I've got new Linux servers ready to go. The problem is the fact that a certain number of those backups are immutable.

My thought is to add the new Linux servers into the SOBR, seal the previous extents, then evacuate the old server extents to the new ones, OR, create a new SOBR and use Veeam's backup move functionality to move the backups. The problem is, by nature of some of the backups being immutable, there's some backups that simply won't move.

Do these backups copy to the new server if they're immutable, and simply stay on the existing servers afterwards with a warning that they couldn't be deleted, thus allowing me to have all of the backups on the new servers? Or is my best bet here to simply not move any backups, add the new servers into the SOBR, seal the old server extents, let all backups begin using the new servers, and then once the old backups have aged out, decommission those servers? The problem with the second approach is that I'd have to continue maintaining these failing servers for the duration of the immutable backups, which is over a year...

What's the best way forward?

[david.domask]

Hi sarnold,

Our User Guide described the behavior for evacuating immutable backups, and you are correct -- the data will be copied, but if some backups are still immutable, they will not be cleaned up after the copy. Once the move is complete, then you can proceed to decommission the old repository.

Moving the backups are fine, and since the storage is going to be replaced, I would just move the backups to the new repository, and once you're done, simply decommission the old repository.

[sarnold]

Moving the backups are fine, and since the storage is going to be replaced, I would just move the backups to the new repository, and once you're done, simply decommission the old repository.

Just to confirm, you're thinking create a new SOBR and move between SOBRs? Or add the new repository servers as extents to the existing SOBR and evacuate the old extents?

[david.domask]

I was referring to the Move Backup operation -- evacuate is a very useful feature and can work as well so no opposition to this strategy, but Backup Move allows for more control over the migration process; evacuate will do the same, but is much more "set and forget", and occupies the extents while the evacuation is occurring.