We are looking at using on-demand sandbox at a customer site to test out some infrastructure build we are implementing. Having never used this feature - I have a couple of questions. I apologize for my ignorance ahead of time!
1. The sandbox will likely be in use for some time - probably at least two to six weeks - to build out and test the infrastructure. Is this a good idea for this type of development? Should we just build everything on an isolated network and not use on-demand sandbox? I cannot find any best practices on longevity for the virtual lab - but it appears to be a short-term solution to test patches/upgrades.
2. The backup jobs that will be used for on-demand sandbox are likely going to be located on a linux immutable repository. We are configuring a "landing-zone" repository where the backups will be written first and probably tiered to the archival immutable storage pretty quickly (a week or two max). Is running the sandbox an issue with immutable storage? My thought on this was that the redirected write cache was the way to go with this. The other option would be to create a copy job to copy the backups to another repository (not scheduled but on-demand) and use that for the virtual lab.
-
- Service Provider
- Posts: 2
- Liked: never
- Joined: Jun 15, 2017 5:07 pm
- Full Name: Michael Keller
- Contact:
-
- Product Manager
- Posts: 14844
- Liked: 3086 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: On-demand Sandbox questions
Hello,
and welcome to the forums.
1. That sounds too long for me depending on the backup job settings. Example: you have 1 week backup retention and try to keep it running for 4 weeks... after a week (depending on the day when you start), the backup files that are the source for the virtual lab don't even exist anymore. Forward incremental with monthly active full gives the longest possible period of unchanged backup files. Backup jobs have precedence over SureBackup jobs. That means, if a backup job applies retention / does merges, the SureBackup job and the sandbox will be stopped. Also remember that the delta of the disk changes can become very large in six weeks.
2. You can run SureBackup / the sandbox from Hardened Repository like from any other repository. Virtual labs can only use backup jobs and storage snapshots (in VMware) as source. Backup copy jobs are not an option today for virtual labs.
I recommend running SureBackup as a small test for better understanding what it does. That makes planning easier.
Best regards,
Hannes
and welcome to the forums.
1. That sounds too long for me depending on the backup job settings. Example: you have 1 week backup retention and try to keep it running for 4 weeks... after a week (depending on the day when you start), the backup files that are the source for the virtual lab don't even exist anymore. Forward incremental with monthly active full gives the longest possible period of unchanged backup files. Backup jobs have precedence over SureBackup jobs. That means, if a backup job applies retention / does merges, the SureBackup job and the sandbox will be stopped. Also remember that the delta of the disk changes can become very large in six weeks.
2. You can run SureBackup / the sandbox from Hardened Repository like from any other repository. Virtual labs can only use backup jobs and storage snapshots (in VMware) as source. Backup copy jobs are not an option today for virtual labs.
I recommend running SureBackup as a small test for better understanding what it does. That makes planning easier.
Best regards,
Hannes
Who is online
Users browsing this forum: No registered users and 57 guests