You are not logged in.
Pages: 1
Hi,
With regards to _XSIREP replicas, I would like to be able to test them automatically. I thought I'd ask if something has abready been created for the job?
I was thinking a script that does the following:
Change virtual machine settings - memory, cpu, network. (Possibly using an already edited vmx to replace one xsibackup created)
Power on virtual machine.
Wait x seconds.
Take and email screenshot of vm.
Shutdown replica
Thanks
short update. Had a chance to do a replica from a 'powered off' vm. This was carried out to a local fs and then scp'd over to a second esxi server. The replica on the second esxi server booted first time. A basic test but wanted to make sure.
Sorry was just a short post previously. Yes the freeze script stalls without the /y. I have tested that the service stops (I'd put a timeout of 15 seconds into the script and observed the NTDS service was stopped)
I actually believe the issue will occur if I power off the VM can do a cold copy. I think it is something to do with the vm changing exsi host, but I cannot confirm this yet. I have to reduce the ammount of memory and processors for the vm on the backups esxi server. On start I tell esxi I 'moved' the vm rather than copied. When I am able to I'll stop NTDS, power off vm and do a copy and then see if it will start - I don't believe it will. ( I am restricted to when I can take the servers down)
I have a script on each server that I can run from dsrm to make things quick and easy in an emergency but I'd still like to work out what is going on and, of course, boot the replica without a bsod. I will update this thread if and when I find anything else out.
When stopping AD you need to stop a number of other services also. There is an undocumented switch /y that will cope with this.
net stop NTDS /y
Until I worked out what was happening my backups would stall at 'Creating snapshot VM'
---
Current state of play - I have tested a hot replica with quiescing on and still getiing the 2e2 BSOD. That's a head scratcher.
Thanks going to test this.
For info purposes:
Running custom quiescing scripts inside Windows & Linux virtual machines (1006671)
https://kb.vmware.com/s/article/1006671
another follow up.
I have 3 networks using this setup. All have old servers which hold replicas of the production server (essentials 2016 or 2019)
All are using warm replicas.
I tested a boot of a replica and got the c00002e2 bsod which means corrupted AD and server unbootable.
All 3 different networks had same result.
I tested with an internet connection and also using cold replicas, same BSOD.
The following got all 3 servers to boot normally. I haven't checked server integerity further yet.
power on replica
choose moved it
keep tapping f8 and boot dsrm
logon as local admin user = .\administrator & dsrm recovery password
in admin command prompt:
cd C:\Windows\NTDS
del *.log
c:\windows\system32\esentutl.exe /p ntds.dit
(agree to prompt window)
shutdown /r
--- ---
For good measure I also use a script to backup the windows system state every day to a local drive.
There is also a restore script that can be run from DSRM. This is a better method probably but takes hour(s) so is not useful to get a replica up running very quickly.
Still not happy with this and time permitting will look into getting the replicas to boot without a corrupted AD.
Hi,
Old thread but was wondering this morning about the comment to use 6.7 over 7. I know 7 was more complex for you to make work with XSIBackup.
Now we have EOL of 6.7. Was the comment about using 6.7 because it was tried and tested, or was the comment because of added complexity of 7 and therefore possibily less stability?
I have several servers running ESXi 6.7 free. XSIBackup replicates the main VM at night. I have to do warm backups otherwise the AD gets corrupted, but otherwise everything is stable and working as expected. The esxi servers are on small business LAN's and the vm's are MS windows essential server.
I am interested in your thoughts regarding upgrading ESXi to 7 also going forward do you now recommend using ESXi 7 if planning to implement XSI-DC? Thanks
Thanks for that.
point 3 becomes:
3) Connect to ESXi GUI on second server.
Start VMNAME_XSIREP
This VM is now production.
At leisure delete the snapshot VMNAME_XSIREP > xsirep_donotdelete as this was only used for backup purposes.
Hi,
Very simple, I want to document the emergency proceedure should our main production server fail.
Is the following correct - mainly I am confused about the _XSIREP vm.
------
xsibackup-DC is being used to create replicas of the production server on a second esxi server.
If the production server fails the second server has a number of replicas ready to go.
1)If esxi is still working on production server remove the cronjob:
remove cronjob from [xsi-dir]/var/spool/cron/root-crontab
run xsibackup --update-cron
2)Make sure broken production vm is off.
3)Connect to ESXi GUI on second server.
Browse datastore, find the relivent replica's .vmx, right click and register VM.
Then boot this VM.
Unregister the _XSIREP vm that was created for sandbox purposes.
-----
Thanks
further update.
Warm backup worked. server down for a couple of minutes.
I suspect rebooting a windows server regualarly like this will likely break it at some point.
Work ongoing....
(I would like to make it very clear to anyone else reading this. The server was Windows Server Essentials. So only one DC.
On testing replicas I discovered 1) it wouldn't boot due to corrupt AD. 2) I couldn't boot into directory services mode to fix things.
So do not use hot backup of a DC )
Update on this.
Today I tried a boot of 2 replicas. Neither worked.
I was planning on booting and fixing the AD as per previous post.
Neither normal boot or DSRM boot worked on either replica.
I booted via a server iso but it's not possible to fix it this way.
So I have updated my xsibackup config to try a warm backup rather than a hot backup - not something I'm kean on doing but I will give it a try tonight.
Some questions
How does XSIBackup trigger the shutdown in a warm backup - is it via vmtools? What I really want to know is how safe it is.
Also using --quiesce what happens -- does xsibackup ask vmtools to quiesce the system using "VMware Tools Quiescence"?
From DC manual
--backup-how[=hot|war|cold] I like the idea of a war backup!:)
Thanks
Regarding fixing - I have tried this on a repilica. In case anyone else needs this, quick instructions below.
NB only use if you have only one DC
F8 into DSRM (F8 may bring up blue screen first if so choose Boot Normally and keep hitting F8)
Choose Directory Services repair mode
Logon as .\administrator - you need your DSRM admin password.
Make a copy of C:\Windows\NTDS - just in case.
Run > cmd
c:
Cd c:\Windows\NTDS
Del *.log
NTDSUTIL
activate instance ntds
files
info
quit
esentutl /p "c:\windows\ntds\ntds.dit"
md C:\Windows\NTDS\Temp
Cd C:\Windows\NTDS
NTDSUTIL
activate instance ntds
files
info
compact to “C:\Windows\NTDS\Temp”
quit
Cd C:\Windows\NTDS
copy /Y C:\Windows\NTDS\temp\NTDS.dit C:\Windows\NTDS
del *.log
shutdown /r
cross fingers.
I'm keeping a copy of this ont he server just in case
still obviously the best approach is to have a 100% functional DC after restoring.
Couldn't agree more - especially as servers normally die at the wrong times and you need to work on your phone in the middle of the night from a different country whilst at a night club!
Hi,
Is there a way to use XSIBackup DC to sucessfully replicate a MS Windows Domain Controller?
In my case there is only a PDC, no secondaries. So no USM rollbackup to worry about and as no secondaries I can't transfer roles.
Will quiesce work? Or does a warm/cold backup need to be taken?
At the moment I need to use DSRM to make the server functional. Any replicas will get a 0xc00002e2 BSOD on boot.
(e.g. https://community.spiceworks.com/topic/ … 0xc00002e2 )
Thanks
Hi, Thanks for any assistance.
I have a replication running daily for a windows server and wish to implement an offsite backup.
Server size static at 1.2TB
Diff size if 10-40GB+ daily.
Probably averaging around high twenties.
While 50GB remote transfer is manageable overnight, I would prefer to optimise it for offsite backups.
1)The server is a windows server doing AD etc plus file sharing.
I would be surprised if the data changed for than 1GB a day.
I assume the rest of the Diff is created from things like:
Volume shadow copies.
Pagefile
Defragging
Updates
I am correct in guessing the above and is there a document on how to minimise these Diff sizes (without taking a noticeable performance hit)?
2)To avoid a 1.2TB initial transfer can you seed a CBT backup?
By this I mean run an initial CBT backup via SSH to a USB drive on a LAN connected Syncology NAS (1Gb bandwidth). Then transfer the USB drive to the offsite location, copy the backup files into a directory on the remote NAS box. Then reconfigure the XSIBackup-DC job to use the IP and directory on the remote site. Will DC recognise the transferred backup and just transfer a diff?
3) I assume IP transfer (ssh) is the best configuration for a remote site than, say, NFS over vpn?
Thanks again
Thanks for the reply. Note the vdisk used to move the data hadn't been connected to the server VM in months - but it was still on the ESXi host. It had been reattached to the temp VM months ago and was turned off. Whatever happened it was only on deleting the temp VM, and thus the large data transfer disk, the the delta copies started working. Thanks
Update:
I had given up on this and was running full replicas.
Issue cleared after deleting the original VM that had the large virtual disk attached. Now replicas are taking a few minutes rather than a few hours.
(On the server there were 2 VMs - a windows server and temp windows vm for moving data. I had been using a temp VM connected to the old network to transfer data to a seperate virtual disk, I then attached the virtual disk with the data to the virual server to move the data onto the servers virtual disks. After removing the temp disk I had issues. After I deleted the temp VM and associated disks did the replication issue clear)
So, I have 2 VMs on the production host. I switched a virtual drive back and fourth between them, it was used to migrate data. I used the ESXi GUI to disconnect the drive and reconnect it to a different VM. Could this have caused the issue? This was months ago, the drive has not changed vm in weeks.
Are you switching the replicated VM on after a replica cycle?
No. I have wiped out the replica VM and retired several times. The replica host a PL gen8 with ESXi 6.7 U3 is not being touched by anything else.
If you do so you will force a new full syncronization cycle.
To prevent that from happening, you have the --options=R argument which will register the replicated VM and create an empty snapshot to be used as a sandbox. Then you can switch the VM without altering the CID of the base disks. Do not manually remove that snapshot, in fact the snapshot info contains a clear "Do not delete me" notice, let the --replica=cbt manage that snapshot. It will be wiped and recreated on every CBT round.
I am not touching anything on the replica host, just rerunning the xsibackup replica command
in this case
xsibackup --replica=cbt "VMs(DC01)" root@replicahost:22:/vmfs/volumes/datastore1/replicas/2 --options=R
I have just re-run this for a thrid time and it's reporting a full sync again.
Hi.
I saw using vim-cmd that the replica was 2. I removed the VM via ESXi's web gui. Which solved that issue.
I keep getting this erorr
/!\ Some changes were detected in the remote replicated VM a full sync will be performed now. |
| Add --options=R to allow the remote replica to be switched on without triggering a full resync. |
| You may continue to run the CBT job later on, it will restart the CBT chain where it was left. |
| If you don't know why you are receiving this message you should run --reset-cbt=THIS-VM.
I have removed the replica. On the source I have run reset-cbt and then created a new replica in a different directoy on the replica host.
I have now got this error again.
I am using a Synology NAS as a backup, using Synologies backup - which will backup ESXi free using CBT. But this is not to blame as I disabled the backup a week ago. While not the source of the current issue, would using the synology ESXi backup conflict with XSIBackup?
I am now stumped with what to try to get the replica to work with CBT so a full sync isn't required each time. Thanks again.
thanks. The ESXi hosts are both HP flavour 6.7 U3.
I think the locked error is to do with whatever '2' is:
msg = "The specified key, name, or identifier '2' already exists." }
-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
2021-06-01T12:13:39 | Error code 194 at file signal.c, line 194 | Error description: raised SIGTERM (11) (2) in job, num of errors: 11, check error.log
--reset-cbt didn't make a difference, I got a full re-sync but the .locked was not removed on the replica host. The only way I can get a replication is by removing it manually. My trial has now run out so I will have to get the powers that be to purchase before continuing.
The entire output from the last sync:
---//----
[root@:~] /vmfs/volumes/ssd/bin/XSIBackup-DC/xsibackup --replica=cbt "VMs(DC01)" root@replica-host:22:/vmfs/volumes/datastore1/replicas --options=R
|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
||| (c)XSIBackup-Free 1.5.0.5: Backup & Replication Software |||
||| (c)33HOPS, Sistemas de Informacion y Redes, S.L. | All Rights Reserved |||
||-------------------------------------------------------------------------------||
|---------------------------------------------------------------------------------|
(c)Daniel J. Garcia Fidalgo | info@33hops.com
|---------------------------------------------------------------------------------|
System Information: ESXi, Kernel 6 Major 7 Minor 0 Patch 0
-------------------------------------------------------------------------------------------------------------
License: unlicensed trial version, remaining trial time: 01:33:56 | (c)XSIBackup-Free
-------------------------------------------------------------------------------------------------------------
Remote system: ESXi
-------------------------------------------------------------------------------------------------------------
PID: 3307063, Running job as: root
-------------------------------------------------------------------------------------------------------------
Remote xsibackup binary found at: /scratch/XSI/XSIBackup-DC/xsibackup
-------------------------------------------------------------------------------------------------------------
(c)XSIBackup-Free replicating data to /vmfs/volumes/datastore1/replicas
-------------------------------------------------------------------------------------------------------------
Performing --replica action
-------------------------------------------------------------------------------------------------------------
Item number 1 in this job
-------------------------------------------------------------------------------------------------------------
DC01 Hardware Version is: 14
-------------------------------------------------------------------------------------------------------------
All snapshots were removed, as DC01 is engaged in a CBT job
-------------------------------------------------------------------------------------------------------------
Virtual Machine Name: DC01
-------------------------------------------------------------------------------------------------------------
Creating snapshot VM : DC01 (powered on)
-------------------------------------------------------------------------------------------------------------
*** Snapshot was successfully created ***
-------------------------------------------------------------------------------------------------------------
Virtual Machine: DC01
-------------------------------------------------------------------------------------------------------------
Backup start date: 2021-06-01T10:26:12
-------------------------------------------------------------------------------------------------------------
2021-06-01 10:26:12 | Backing up 43 files, total size is 1.23 TB
-------------------------------------------------------------------------------------------------------------
NUMBER FILE SIZE PROGRESS
-------------------------------------------------------------------------------------------------------------
1/43 DC01.vmx 3.99 KB | Done 0.00%
-------------------------------------------------------------------------------------------------------------
2/43 DC01-flat.vmdk (CBT 1 full) 120.00 GB | Done 0.00%
-------------------------------------------------------------------------------------------------------------
::: detail ::: 100.00% done | block 122880 out of 122880 | Done 9.78%
-------------------------------------------------------------------------------------------------------------
3/43 DC01.vmdk 562.00 B | Done 9.78%
-------------------------------------------------------------------------------------------------------------
4/43 DC01_1-flat.vmdk (CBT 1 full) 550.00 GB | Done 9.78%
-------------------------------------------------------------------------------------------------------------
::: detail ::: 100.00% done | block 563200 out of 563200 | Done 54.61%
-------------------------------------------------------------------------------------------------------------
5/43 DC01_1.vmdk 567.00 B | Done 54.61%
-------------------------------------------------------------------------------------------------------------
6/43 DC01.vmsd 739.00 B | Done 54.61%
-------------------------------------------------------------------------------------------------------------
7/43 vmx-DC01-2157451611-2.vswp [open excluded]
-------------------------------------------------------------------------------------------------------------
8/43 vmx-DC01-2157451611-1.vswp 94.00 MB | Done 54.61%
-------------------------------------------------------------------------------------------------------------
9/43 DC01.vmx.lck [skipped excluded]
-------------------------------------------------------------------------------------------------------------
10/43 vmware-1.log 430.89 KB | Done 54.61%
-------------------------------------------------------------------------------------------------------------
11/43 DC01.vmx~ 3.96 KB | Done 54.61%
-------------------------------------------------------------------------------------------------------------
12/43 vmware-6.log 15.45 MB | Done 54.61%
-------------------------------------------------------------------------------------------------------------
13/43 DC01.nvram 264.49 KB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
14/43 DC01.vmxf 3.74 KB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
15/43 vmware-2.log 280.10 KB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
16/43 vmware-3.log 310.60 KB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
17/43 vmware.log 275.22 KB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
18/43 vmware-4.log 4.16 MB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
19/43 vmware-5.log 259.37 KB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
20/43 DC01_3-flat.vmdk (CBT 1 full) 20.00 GB | Done 54.62%
-------------------------------------------------------------------------------------------------------------
::: detail ::: 100.00% done | block 20480 out of 20480 | Done 56.25%
-------------------------------------------------------------------------------------------------------------
21/43 DC01_3.vmdk 510.00 B | Done 56.25%
-------------------------------------------------------------------------------------------------------------
22/43 DC01-8098195b.vswp [open excluded]
-------------------------------------------------------------------------------------------------------------
23/43 DC01_1-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
24/43 DC01-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
25/43 DC01.vmsd.tmp 44.00 B | Done 56.25%
-------------------------------------------------------------------------------------------------------------
26/43 DC01_3-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
27/43 DC01.vmx.tmp 3.90 KB | Done 56.25%
-------------------------------------------------------------------------------------------------------------
28/43 DC01-Snapshot60.vmsn 288.38 KB | Done 56.25%
-------------------------------------------------------------------------------------------------------------
29/43 DC01-000001-sesparse.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
30/43 DC01-000001.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
31/43 DC01-000001-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
32/43 DC01_1-000001-sesparse.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
33/43 DC01_1-000001.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
34/43 DC01_1-000001-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
35/43 DC01_3-000001-sesparse.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
36/43 DC01_3-000001.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
37/43 DC01_3-000001-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
38/43 DC01_2-flat.vmdk (CBT 1 full) 500.00 GB | Done 56.25%
-------------------------------------------------------------------------------------------------------------
::: detail ::: 100.00% done | block 512000 out of 512000 | Done 97.00%
-------------------------------------------------------------------------------------------------------------
39/43 DC01_2.vmdk 539.00 B | Done 97.00%
-------------------------------------------------------------------------------------------------------------
40/43 DC01_2-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
41/43 DC01_2-000001-sesparse.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
42/43 DC01_2-000001.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
43/43 DC01_2-000001-ctk.vmdk [skipped excluded]
-------------------------------------------------------------------------------------------------------------
Total size: 1.19 TB | Done 100.00%
-------------------------------------------------------------------------------------------------------------
*** Snapshot was removed ***
-------------------------------------------------------------------------------------------------------------
msg = "The specified key, name, or identifier '2' already exists." }
-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
2021-06-01T12:13:39 | Error code 194 at file signal.c, line 194 | Error description: raised SIGTERM (11) (2) in job, num of errors: 11, check error.log
-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
SIGTERM (11) condition was trapped: check logs for more details
-------------------------------------------------------------------------------------------------------------
Cleaning up...
-------------------------------------------------------------------------------------------------------------
Removed host <tmp> dir OK
-------------------------------------------------------------------------------------------------------------
Removed prog <tmp> dir OK
-------------------------------------------------------------------------------------------------------------
Unlocked backup OK
-------------------------------------------------------------------------------------------------------------
SSH session was closed OK
-------------------------------------------------------------------------------------------------------------
Removed PID OK
-------------------------------------------------------------------------------------------------------------
Thanks for that. Will use that code.
I have a couple of issues that are probably down to my lack of groking this properly. I created replica like so
xsibackup --replica=cbt "VMs(SERVERDC01)" root@replica-esxi:22:/vmfs/volumes/datastore1/replicas --options=R
Ran OK, full sync. Did not touch anything.
Ran the command again 24hrs later and it finished in about 10 mins. (I had to remove .locked in replica directory to get it to run)
Using ESXi web gui on replica host:
Looked at snapshots but could not see any.
Anyhow went ahead and booted the server vm on it's only virtual network. Added a win 10 vm to domain no issues. All looked fine with the server at the glance I took over it. Guess I need a script to check the server.
Removed win 10 vm from domain and powered it and the replica server vm down.
Went back to ssh on production server and ran
xsibackup --replica=cbt "VMs(SERVERDC01)" root@replica-esxi:22:/vmfs/volumes/datastore1/replicas --options=R
again.
Again there was a locked file in the replica dir. The VM was off for several minutes and there is nothing else configured on replica host might be causing issues.
After deleting the .locked file xsibackup reported the replica had been modified and is doing a full sync again.
So I am not sure what is happening.
What is causing the .locked file?
Did --options=R not create the snapshot?
I am still trying to make sure I clearly understand what is happening. So this is how I think it operates:
start: On production host xsibackup is run with --replica=cbt & --options=R
A replica vm is created on replica host and a snapshot is created on the replica host also.
When the replica vm is turned on for testing the state of that vm is changed, data is written.
Next time xsibackup runs it removes the snapshot hence setting the replica back to the state it was in when the last replica sync happened. Then the live production VM is synced over to the replica and a new replica snapshot is created for testing. And this process is repeated over and over again until the replica is actually needed.
In the case the replica is needed.
The production system is disconnected from the network to stop an mischief.
Now the relica host becomes the production host.
This really just means the replica VM is powered on, connected to the production network and users let loose.
The original xsibackup job is removed from the failed server - even it it managed to run it would fail anyway.
The original production hardware is replaced / fixed.
To move the production VM back, it's powered off and copied overnight/weekend using Xsibackup from command line to replicate the vm back. Power up the new production vm.
On what is now the replica host again copy VM to USB just in case and delete it from the replica host.
Now go what back to start:
Thanks again.
I'm at the final stages of implementing the system below and would like to sanity check what I am doing and also check that I correctly using XSIbackup DC.
Small business running one windows essentials server (AD, DHCP, DNS, File server etc)
The production host is a second user Proliant Gen 9.
Important: There is a requirement to minimise any downtime should a failure happen, so if possible want a replica ready to switch on.
There is an older ProLiant Gen 8 as backup hardware should the main server host fail. Lets call this the replica host.
There are onsite and offsite NAS boxes for backups - using synology's esxi backup.
Both ESXi hosts are running ESXi 6.7 U3 free.
There is a 10Gbps link between the ESXi hosts.
Both servers have more specs than needed.
XSIBackup DC will only be used for replication.
As replicas can be turned on immediately the plan is to maintain a set of replicas on the replica host.
In case of disaster, if a replica could not be used for DR then we would fall back to the backups.
I am planning to keep 3 replicas on the replica host.
Set cron job to run 9pm
1: Mon & Thurs
/vmfs/volumes/ssd/bin/XSIBackup-DC/xsibackup --replica=cbt "VMs(SERVERDC01)" root@Replica-Host:22:/vmfs/volumes/datastore1/replicas/1 --options=R
2: Tues & Fri
/vmfs/volumes/ssd/bin/XSIBackup-DC/xsibackup --replica=cbt "VMs(SERVERDC01)" root@Replica-Host:22:/vmfs/volumes/datastore1/replicas/2 --options=R
3: Wed & Sat
/vmfs/volumes/ssd/bin/XSIBackup-DC/xsibackup --replica=cbt "VMs(SERVERDC01)" root@Replica-Host:22:/vmfs/volumes/datastore1/replicas/3 --options=R
In case of production host failure there are 3 replicas to choose from:
If down mon morning, 3: Sat 9pm, 2: Fri 9pm, 1: Thurs 9pm
down tues: 1: Mon 9pm, 3: Sat 9pm, 2: Fri 9pm
etc etc
Why 3? There is space is on the server and holding 3 replicas seems more secure than one. For instance if one replica somehow corrupted when needed. There may also be some unforseen need to roll back the server a day or two.
I'd like to have more instantly bootable replicas and wondered is there a way to have say 3 weeks worth - 3 different replicas which have 7 days of snapshots?
In a disaster, if the production host was still running and the XSIBackup-DC job ran would it overwrite a running replica?
I imagine killing the cron job could easily be overlooked in this situation.
Are there any downsides to using the --options=R option? If I understand correctly this would always keep a snapshot that could be turned on as test, but no intervention is required.
In a DR situation would the snapshot be run, becoming the production server, or it be consolidated first? Or would I just delete the snapshot?
(I note that to adhere to Microsofts licensing we'd need an extra server license to be able to test a replica while the production serevr is running, if they remain switched off they wouldn't need an extra license!!!)
Hope that lot makes sense and many thanks.
Thanks for getting back.
Yes, I guess I kind of overlooked the CPU and RAM requirements, just assuming that any modern setup would be more than enough.
Probably specs:
ESX01 Xeon Silver 4210 32gb
ESX02 Xeon E-2224 16Gb (in MicroSvr or ML30 - both HPe cert to ESXi 7.0U1)
LB01 - probably something like an old i5 3rd Gen Optiplex 3010 fitted with new drives. Actually probably no raid or linux software raid. If I get my hands on an old server so much the better.
Will use CentOS, not used it in years/decades. Always went to debian over Red Hat.
No reflection NAS01 will be a CentOS VM. Will allow for easy mounting of backups.
Will use ESXi 6.7. With the above hardware I'll have an upgrade route just in case it's needed a few years down the line.
Point taked re ssd's. Will look into that.
I was a bit confused trying to work out how to check integrity of replicas & backups. Can this be carried out via a cron job every week or so?
In other words is the a hands off way of monitoring the health the replicas and backups ?
I have been reading the manuals etc on the site. I am putting together a solution as outlined below and in diagram:
https://docs.google.com/drawings/d/1nGA … sp=sharing
Have I correctly understood the role XSIBackup-pro / DC will play in this solution? Is Pro same as DC but with 1 license, if so I think I require Pro, otherwise DC.
A company that has a limited budget need to implement a new IT infrastructure.
Due to budget constrains I am trying to keep licensing costs minimumal.
So they will run just Windows Essentials Server 2016, which covers CALs for users and remote desktop gateway.
One remote office with about 40Mbps connection, main office has faster connection.
Remote office workers RDC to systems in main office. Covid / home workers use remote desktop gateway to access pc's in main office.
Given the single windows server there is a requirement for fast recovery in case of it's failure.
Suggested solution. WSE 2016 runs as VM with second VM host on premises.
Second host holds copies of VM that can be spun up if main server fails.
Second host also runs VM that contains backups mainly used for file recovery.
Remote office used for off site backups. Linux box. XSIBackup to handle all these backups.
Head office has main server running ESXi free
HPe ML350 Gen 10, SSD's + SAS for storage.
XSIBackup (pro/dc?) installed
Single VM running WSE 2016 doing all Windows network: AD, DHCP, File sharing, Remote Desktop Gateway
Head office backup server.
Hpe Microserver Gen10, SATA disks RAID5
ESXi installed.
Single VM running a NAS or Linux.
Recpicas on DC01
Choosing ESXi 7 as support covered until 2027.
Would I be better with eariler version or ESXi like 6.5 given issues with 7?
Are there any known issues using XSIBackup to backup and restore Windows Essentials Server 2016, especially given it's role as domain controller?
XSIBackup will:
Create replicas on ESX02
A number of replicas kept in case of ESX01 failure of DC01 crypto - can be spun up immediately.
Create backups to NAS01
Historical backups on NAS01 can be mount for file recovery.
Possibly used in extreme cases to restore DC01
Create Backups on LB01
Office site histroical backups of DC01
Used for file recovery and recovering DC01 in case of loss of head office
SSH tunnel via internet not VPN to increase realitive speed.
For file level recovery, backups mounted via ssh and Winscp'd to DC01.
Does this seem like a sane what of doing things? Am I missing anything.
Many thanks.
Pages: 1