How to restore a new or wiped device from S3. Restoring a new or wiped device from S3 is a common recovery scenario, but execution is where most issues occur. Restoring data correctly, validating it, and proving the system works is where discipline matters. In this video, we'll outline a restore process that ensures accuracy, usability, and audit readiness. Before we begin, be sure to subscribe to NinjaOne's IT Video Hub and our YouTube channel for more tech content like this. How to run an S3 restore deleted file operation. Prepare access and target paths. Start by confirming access to the S3 bucket using the AWS CLI. This validates permissions and ensures you can enumerate backup data. Next, identify the correct bucket and prefix where your backups are stored and define where the data will be restored on the new device. Make sure to document both the source and destination paths in a restore manifest. Identify the correct backup set. Connect to S3 using your restore tool or CLI and review available backups. Select the correct version based on timestamp, system name, and recovery requirements. If encryption is enabled, provide the appropriate key before proceeding. Confirm that the region and bucket align with your backup configuration to avoid restoring from the wrong dataset. Restore critical data first. Focus on restoring high-priority data first, so users and systems can resume operations. Start with user profiles, application data, and active working directories. Validate access and functionality as each dataset is restored. As the restore progresses, validate that files are accessible and usable. Once critical systems are operational and users can access their data, you can proceed with restoring less frequently used data in the background. Handle platform-specific backups. If your backup originated from a hosting control panel such as cPanel, Plesk, or DirectAdmin, the restore process changes slightly. These backups often include not just files, but also databases, DNS configurations, and email settings. In this case, you should use the panel's built-in restore tools rather than performing a manual file-level recovery. Once the restore is complete, validate that websites, email services, and DNS resolution are functioning correctly. Validate data and applications. After restoration, verify that data is intact and usable. For instance, you can use this PowerShell command to run file integrity checks. Confirm file permissions and ownership are correct and users can access required data, then launch key applications and services to ensure they operate without errors. In some cases, you may also need to rebuild indexes or caches to restore full functionality. Finally, review logs from your restore tool to identify any skipped or failed items. Document results and improve continuously. A restore isn't complete until it's fully validated and recorded. Capture key metadata such as the restore source, destination paths, timestamps, and the IAM role used. Document any exceptions or skipped files along with the reasons. You should also collect logs, screenshots, and validation outputs that demonstrate a successful restore. Combine these into a single evidence packet and store it with your ITSM ticket or documentation system. When you validate access, prioritize critical data, and document results, you create a repeatable recovery process that reduces risk and improves reliability. For more information, check out our official blog post on how to restore a new or wiped device from S3, linked in the description below.