Venezuela’s Earthquake Disaster Raises Urgent Questions About Urban Resilience and Emergency Preparedness
#VenezuelaEarthquake #DisasterRecovery #Caracas #EmergencyResponse #InfrastructureResilience
https://eng.harbouchanews.com/2026/06/venezuelas-earthquake-disaster-raises.html
Disaster Recovery Test Checklist: What to Capture Before You Start
This article is a practical checklist of the evidence to capture before you click Restore. A disaster recovery test should not begin with someone clicking Restore. It should begin with evidence. Here is a common way these tests go sideways. The team books a window, restores a VM, watches it boot, and calls the test a success. Please see Upgrading Azure AD Connect to Microsoft Entra Connect Sync, and PCI Driver Error: Connection to Deployment Share could not be made.
A week later, management asks which restore point was used, whether it met the recovery objective, and whether the application actually worked. The team did not capture the answers, because everyone was focused on the restore itself.
A disaster recovery test is not only about whether a server boots. It is about proving what existed before the test, what you selected to recover, what changed during the test, and whether the result met the recovery objective.
Please see Steps to Fix the “Invalid OS GUID” Error in MDT, Faulting SecHealthUI: Resolve Windows Defender Notification, and how to Update Your AMD Radeon Display Adapter Driver.
Key Takeaways
Capture evidence before the restore begins, not after the test is over. A VM that boots is not proof that the application recovered. Validate the application and its dependencies.
Why Capture Evidence Before a Disaster Recovery Test?
A baseline tells you what the environment looked like before you touched it. Without it, you cannot tell whether a problem you hit during the test was caused by the recovery or was already present.
Evidence proves the backup existed and was healthy before the test. If a job failed the night before and nobody noticed, you want to know that before you start, not after a failed restore. Captured state supports audit and management review. When someone asks whether the recovery met the objective, you answer with records instead of memory.
A baseline makes rollback easier. If you need to undo a change, you already know what the original configuration was. Evidence reduces confusion during troubleshooting. When three people are staring at a recovered system that will not start a service, the pre-test notes tell you what normal looked like.
Capturing the environment first also helps you avoid accidental production impact. Writing down the production IP addresses, hostnames, and DNS records before the test forces you to plan around them.
Finally, a clean set of evidence becomes a reusable test record. The next test starts from a documented baseline instead of a blank page.
Please see How to update Proxmox VE to the latest version 9.2.3 today, Secure Boot 2023 Compliance Across WinPE, MDT, WDS, and ADK: Boot Chain Alignment and PXE Validation [Final Part], and how to Fix an error occurred while attempting to start selected VM on Hyper-V.
Capture the Environment Inventory
Before the test, capture the current state of the environment you are protecting. Screenshot or export the following:
The labels differ by platform. On VMware vSphere you are looking at clusters, hosts, datastores, and port groups. On Hyper-V you have hosts, virtual switches, and VHDX files. On Proxmox VE you have nodes, storage, and Linux bridges. On Nutanix AHV you have a cluster, hosts, and AHV networks. For cloud workloads, capture the equivalent: instance configuration, attached storage, and the virtual network or subnet.
Capture the view that matches your platform. The goal is a clear record of what existed, not a product tutorial.
Capture this from the main cluster or environment overview screen. For VMware vSphere, use the cluster summary view. For Hyper-V, use Failover Cluster Manager or Hyper-V Manager. For Proxmox VE, use the Datacenter or node summary view. For Nutanix AHV, use the Prism cluster overview. The goal is to show the starting state of the platform before any recovery action begins. Capture the VM inventory from the hypervisor, cloud console, or backup platform before the test starts. Include the workloads in scope for the recovery test, their current power state, and enough context to prove which systems were protected. Redact hostnames or customer names if needed. Capture the configuration view for one representative workload in scope. Show vCPU, memory, virtual disks, and network adapters. This screenshot helps prove the pre-test configuration in case the restored VM has different resources, missing disks, or incorrect network placement.Please see Failed to Upgrade VIHR Component: Failed to open deployer Service Management Port, The Backup Was Safe: The Data Center Was not: A Real-World Lesson About Hidden Data Center Risks and Governance Failures, and Enterprise Tape Library Administration: Control Path, Firmware, Media Management and Tape Operations.
Capture the Backup Platform State
Now capture the state of the backup system itself. This is the evidence that your recovery source was healthy before you started.
Veeam is a common example here, but the same evidence applies to any backup platform. Whatever product you use, you want proof that the job ran, the restore points exist, the repository is healthy, and any immutability or encryption is in the expected state.
Capture the main dashboard or overview screen in the backup console before starting the restore. For Veeam, this could be the console overview, jobs view, or recent session status area. For other platforms, capture the equivalent health or status screen showing the backup environment was available before the test.Capture the job history or session history for the workload being tested.
The screenshot should show the last successful backup run, the job name, completion time, and status. This proves the recovery source was valid before the test began.Capture the restore point selection screen before choosing the restore point.
The image should show the available restore points for the workload, including date and time. This gives the recovery team evidence that the selected restore point existed before the test. Capture the backup repository, storage target, or object storage capacity view. Show available free space, repository status, and any health indicator that proves the backup source was usable. Redact repository names, paths, bucket names, or infrastructure details if they expose the real environment. Also capture the restore target storage separately if the restore will write to a datastore, volume, or cloud disk target.Capture the immutability or retention lock view only if the backup platform or repository exposes it safely.
This may come from the backup console, hardened repository settings, object storage bucket settings, or appliance dashboard. Do not expose bucket names, access keys, tenant IDs, or repository paths.Please see How to Repair a Corrupt SQL Server Database Without Data Loss, Azure Application Gateway: Practical Configuration Guide, and Azure Managing Subscriptions with PowerShell: From Login-AzAccount to Resource Control and Private Endpoint Verification for Azure File Share”.
Document the Restore Point Selection
The restore point you choose decides what you actually recover. Record it precisely:
After the test, you should be able to answer one question without hesitation: did we recover from the restore point we intended to use? If you cannot answer that, the test result is hard to trust.
Capture the final selected restore point before launching the restore. The screenshot should clearly show the workload name and restore point timestamp. This is the evidence that answers, “Which backup did we actually choose?”Capture the details pane, restore wizard summary, or restore point properties view that shows the selected restore point date, time, source job, and consistency type if available.
This is especially useful when comparing the selected restore point against the RPO.Document Recovery Objectives and Success Criteria
Write down what success looks like before the test, not after.
Example success criteria
The VM boots, and Services start.
A disaster recovery test is not successful just because a VM powers on. A booted VM with a dead application, a stale data set, or a broken dependency is a failed test that looks like a passing one. Decide in advance which of the criteria above must be met.
Please see Azure Arc for SQL Server PAYG: Installation, Connectivity Requirements and Operational Best Practices, how to Assign a Public IP to Azure Virtual Machine (VM), and how to Upgrade Veeam ONE to 13.0.2.6723 to Address Security Fixes.
Capture Application and Infrastructure Dependencies
Many disaster recovery tests fail because the restored workload depends on something that is not in the test. The server itself is fine. What it needs to talk to is missing. Map the dependencies before the test:
A restored application server may boot successfully and still fail if it cannot reach DNS, authenticate against Active Directory, connect to its database server, or check out a license.
Time matters too. In Active Directory environments, Kerberos authentication depends on synchronized clocks. If the test network cannot reach a valid time source and the recovered systems drift too far, authentication can fail.
Decide how each dependency will be satisfied in the test: recovered alongside the workload, stubbed with a test service, or provided by an isolated copy.
Capture the written dependency map, runbook section, whiteboard diagram, spreadsheet, or recovery order table. This does not need to be a product UI screenshot. The goal is to show which systems depend on Active Directory, DNS, databases, file shares, license servers, or other services.Capture a sanitized DNS view or a lab version of the required records.
This could come from Windows DNS Manager, cloud DNS, an internal DNS appliance, or a test DNS server. Avoid exposing real internal zones, production hostnames, customer domains, or public records.Capture only the specific firewall rules needed for the test, not the entire firewall rule base.
Use a lab firewall, sanitized export, or filtered rule view where possible. The screenshot should prove that required application ports and isolation rules were reviewed before the test.Please see Fix Vulnerable Veeam Backup and Replication 13.0.1.2067 and Earlier, how to upgrade Veeam One from v12 to v13, and Integrate Trellix ePolicy Orchestrator with a Syslog Server.
Capture the Test Network Design
Network isolation is one of the most important pre-test items. Get it wrong and the test can affect production. Review this section carefully before any recovered system is powered on. Capture:
Keep the test isolated
Do not accidentally connect restored systems to the production network unless the recovery plan explicitly requires it and the risks have been reviewed and approved. An isolated test network, sometimes called a bubble or fenced network, lets recovered systems run with their original IP addresses and hostnames without colliding with production.
Why isolation matters
Duplicate IP addresses cause immediate problems. If a recovered server uses the same IP address as a live production server, the result is an address conflict and unreliable connectivity. Duplicate hostnames cause confusion and can break authentication and certificates.
A recovered domain controller deserves extra caution. If it is restored incorrectly or allowed to communicate with production domain controllers during a test, you can create Active Directory replication or recovery problems. Keep domain controller recovery tests isolated unless you are following a validated forest recovery or domain controller recovery procedure.
Production DNS registration is another trap. A recovered system that can reach production DNS may create conflicting or misleading records and send clients to the wrong host. Plan a DNS override inside the test network so name resolution stays contained.
Capture the test network definition from the hypervisor, virtual switch, cloud network, recovery lab, or network virtualization platform. The screenshot should show that recovered workloads will connect to an isolated or fenced test network instead of the production network.Capture the VLAN, subnet, or test network address plan from the network console, hypervisor networking view, or lab documentation.
Redact real subnet details if needed. The purpose is to prove that the test network was planned before restored systems were powered on.Capture the rule that blocks recovered systems from reaching production, or the rule that allows only tightly controlled traffic required for validation.
This should be a narrow, sanitized view. Do not show the full firewall policy, public IP addresses, VPN details, or sensitive network objects. Capture the test DNS configuration used by restored systems. This may be a test DNS zone, hosts file entry, DNS override rule, split DNS view, or isolated domain controller DNS configuration. The goal is to show how name resolution stays inside the test environment and avoids changing production DNS.Please see Veeam Backup and Replication: PowerShell must be Remote Signed, how to Prevent Automatic Driver Updates in Windows and Xen-Orchestra, and how to Switch from IP Addresses to DNS for Backup Infrastructure in VBR.
Validate Access Before the Test
A recovery test can fail before it starts if the one person with the encryption key, the backup console, or the firewall access is unavailable. Confirm access ahead of time. Document who has access to:
Then test that the access actually works before the window opens. A documented account that nobody can log into is not access.
Security note: do not screenshot or publish passwords, tokens, secrets, license keys, customer names, public IP addresses, private infrastructure details, or sensitive diagrams unless they are fully redacted. If a screenshot cannot be safely redacted, recreate it in a lab or omit it. The evidence you keep should prove the test happened correctly, not expose how to break into the environment.
What Not to Capture
Some evidence should not be included in a public article, shared report, or customer-facing document unless it is fully redacted. Do not publish the following without sanitation:
If a screenshot cannot be safely sanitized, recreate the view in a lab or describe the evidence in text.
Create an Evidence Folder
Decide where the evidence goes before the test, not while you are scrambling during it. A simple, consistent folder structure works:
Name files consistently so they sort and make sense later. A date prefix plus a short description works well:
Consistent names turn a pile of screenshots into a usable record. Six months from now, the file name should tell you what it shows without opening it.
Please see How to remove a Repository from Veeam Backup and Replication, how to Update Veeam Backup & Replication to Build 13.0.1.2067, and how to Fix broken Repository Path in Veeam Scale-Out Backup Repository.
Final Pre-Test Checklist
Use this checklist before you click Restore. It stands on its own.
ItemEvidence to CaptureCompleteRecovery scope approvedWritten scope listing systems in and out, approved by the owner[ ]Success criteria documentedRTO, RPO, and pass or fail criteria recorded[ ]Backup job completed successfullyScreenshot of the last successful run for each workload[ ]Restore point selectedRestore point date, time, and source job recorded[ ]Backup repository health checkedRepository status, capacity, and warning state captured[ ]Restore target capacity checkedDatastore, volume, cluster, or cloud target capacity verified[ ]Immutability verified if applicableImmutability or lock status captured[ ]Encryption key access confirmedKey custodian available and key access tested[ ]Test network preparedIsolated network and VLAN or subnet defined and verified[ ]DNS plan documentedDNS override or test DNS strategy written down[ ]Firewall rules reviewedIsolation rules confirmed with no path to production[ ]Credentials verifiedConsole, admin, and break-glass access tested[ ]Application dependencies mappedDependency list and recovery order documented[ ]Stakeholders notifiedNotification sent and window confirmed[ ]Rollback plan documentedSteps to tear down the test environment recorded[ ]Evidence folder createdFolder structure created and ready to fill[ ]Conclusion
A good disaster recovery test produces confidence, not just screenshots. The screenshots and notes are proof that the team understood the starting state, followed a plan, protected production, and validated the result. They turn a one-time exercise into something you can repeat and improve.
Capture evidence before the test, validate the application after the restore, and document what you learned before the next outage makes the test real.
I hope you found this blog post on “Disaster Recovery Test Checklist: What to Capture Before You Start” very useful. Please feel free to leave a comment below.
5/5 - (1 vote) #Backup #businessContinuity #disasterRecovery #DRTesting #HyperV #NutanixAHV #ProxmoxVE #recoveryTesting #RPO #RTO #Veeam #VMwareVSphere
RAPPLER | Philippine & World News | Investigative Journalism | Data | Civic Engagement | Public Interest [Unofficial]2d ago[Kasalikasan] The earthquake that shook Mindanao — and what disaster reporting entails
Concept for Underground Hospital Reveals Atomic Bomb Preparedness
Imagine a hospital hidden beneath the earth, designed to shield patients and staff from the devastating effects of an atomic bomb, with advanced features like Geiger counters and decontamination chambers. This futuristic underground facility could accommodate 700 patients, a full medical team, and…
#AtomicBombPreparedness #UndergroundHospital #EmergencyResponse #DisasterRecovery #InfrastructureDesign
How to Generate a Full #VPS #Backup Using #rclone (Simple 3-Minute Guide)
This article provides a detailed step-by-step description of how to generate a full VPS backup using rclone.
What is rclone?
Rclone is a powerful open-source command-line tool for managing files on cloud storage services and local storage. You can think of it as kind of like "rsync" (the popular file-copying tool), but ...
Continued 👉 https://blog.radwebhosting.com/generate-a-full-vps-backup-using-rclone/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.raddemo.host #googledrive #opensource #onedrive #disasterrecovery
Fast-moving wildfire razes parts of Beacon Hill in Spokane
"[A] fast-moving blaze raced through trees and into the Northwood neighborhood near Spokane Valley on Tuesday," the Spokesman-Review reported. "The wildfire torched over 250 acres with no containment as strong winds continued to push it east during the afternoon."
" fast-moving blaze raced through trees and into the Northwood neighborhood near Spokane Valley on Tuesday," the Spokesman-Review reported. "The wildfire torched over 250 acres with no containment as strong winds continued to push it east during the afternoon."
E poi dicono che non esistono soluzioni di #DisasterRecovery #OpenSource …
How to Generate a Full #VPS #Backup Using #rclone (Simple 3-Minute Guide)
This article provides a detailed step-by-step description of how to generate a full VPS backup using rclone.
What is rclone?
Rclone is a powerful open-source command-line tool for managing files on cloud storage services and local storage. You can think of it as kind of like "rsync" (the popular file-copying tool), but ...
Continued 👉 https://blog.radwebhosting.com/generate-a-full-vps-backup-using-rclone/?utm_source=mastodon&utm_medium=social&utm_campaign=mastodon.social #disasterrecovery #onedrive #opensource #googledrive
Recreate Resources
Related to [[202404071556 Disaster Recovery|Disaster Recovery]] and [[202404071304 Resiliency Overview]]
📖 Read more: https://sajalchoudhary.net/til/recreate-resources/
HarbouchaNews
Eric Black
Sanjay Mohindroo
Analyst207
mastodon.raddemo.host
NorthwestProgressiveInstitute
morrolinux
Rad Web Hosting
Sajal Choudhary