PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The safe way to wipe a Linux VPS is to use your hosting provider’s Rebuild/Reinstall control, or delete the instance and provision a new one. Do not run rm -rf against the live root filesystem: the running system, SSH session, mounted volumes, boot files and provider metadata can leave you with a half-erased, inaccessible server rather than a clean installation.
Before erasing anything, make and test clean backups, record every dependency, and decide whether the current public IP must remain. Rebuild normally replaces the VPS disk while retaining the instance; destroy/recreate permanently removes the instance and gives you a wholly new resource. The right choice depends on your provider, the resources attached to the server and whether compromise is suspected.
What “wiping a VPS” actually does
A VPS has two layers that are easy to confuse:
- The guest disk: the operating system, packages, users, application files, databases and local configuration.
- Provider resources: the virtual server record, public or floating IP addresses, snapshots, backups, attached block volumes, firewalls, load balancers and DNS settings.
A provider rebuild generally erases the guest disk and writes a selected operating-system image. DigitalOcean describes its Rebuild action as wiping the Droplet’s disk and replacing it with an image you select. The instance record and, where supported, its public IP remain. A destroy action is different: DigitalOcean says deleting a Droplet permanently and irreversibly destroys it. Some external resources may remain unless you explicitly select them for deletion.
Deleting files from a running VPS is not equivalent to either operation. It does not reliably remove boot data, hidden files, provider metadata, attached volumes or persistence mechanisms, and it can terminate the shell before the command finishes.
#1 Best Overall
Decide whether you need a rebuild or a new server
| Choice | What is replaced | IP and identity | Resources to check | Best fit |
|---|---|---|---|---|
| Rebuild/Reinstall | The VPS boot disk is replaced with the selected image. | Often retains the instance and public IP; confirm with your provider before starting. | Volumes, snapshots, backups, firewalls, floating IPs and load-balancer membership are reviewed separately. | You want a clean OS but need to preserve the server record or address. |
| Destroy and recreate | The instance is permanently deleted; a new instance is provisioned. | Usually receives a new identity and may receive a different IP unless an address resource is retained and reassigned. | Every attached or separately billed resource must be reviewed in the confirmation flow. | You want new provider-side settings, a new server identity or a completely fresh deployment. |
When a rebuild is the practical option
Choose rebuild when the provider supports it and preserving the current public IP matters. This is useful when DNS, allowlists, license bindings or customer integrations already point to that address. A rebuild still requires you to re-create users, packages, services and application configuration from trusted sources.
When destroy-and-recreate is safer
Choose destroy/recreate when you want to eliminate old instance settings, change region or plan, or start with a newly defined resource. Hetzner’s FAQ recommends deleting a server completely and creating a new one for reinstallation because this ensures settings are new and up to date. The same guidance warns that all saved data will be lost, so do not proceed until backups and external resources have been handled.
Free tools Windows power users keep installed
One-click scans. No signup required.
Prepare before touching the erase control
1. Make a complete inventory
Record the server name and ID, region, plan, operating-system image and version, public and floating IP addresses, attached volumes, snapshots, backups, firewalls, load balancers and DNS records. Note DNS TTL values and whether an address is assigned directly to the instance or exists as a separate provider resource.
Also list everything that lives inside the guest:
- Databases, database users and replication settings.
- Application code, uploaded files, media and configuration files.
- Environment variables, API tokens, deployment credentials and encryption keys.
- SSH authorized keys, certificate and private-key locations, and TLS certificates.
- Cron entries, systemd timers, queue workers and scheduled backup jobs.
- Firewall rules, reverse-proxy configuration and service bind addresses.
- Monitoring, alerting, log-shipping and webhook integrations.
Export the inventory to a location that is not the VPS. A note stored only on the server disappears with the disk.
2. Back up data in a restorable form
Take logical database dumps where possible, copy application data and preserve the exact configuration needed to recreate the service. Keep at least one copy outside the provider account or in a separate project. If you use provider snapshots or backups, verify their retention period and whether they are attached to the instance.
Do not treat “backup completed” as proof of recoverability. Restore a representative database dump and a sample of uploaded files on another system, or at minimum inspect the archive and perform a test extraction. DigitalOcean warns that destruction is irreversible and recommends converting backups to snapshots when they must be kept. The confirmation screen is not a substitute for a tested restore.
3. Decide what must happen to the IP and DNS
Write down the current A and AAAA records, reverse-DNS settings, service allowlists and any clients that pin the address. If you rebuild and retain the IP, DNS may not need to change. If you create a new server, lower the DNS TTL ahead of the maintenance window, but remember that resolvers can cache records for longer than the nominal TTL. Keep the old record available until the new service has passed external tests.
4. Separate disk data from provider resources
Removing a server does not necessarily remove every associated object. Review volumes, snapshots, backups, reserved or floating IPs, load balancers and firewall objects individually. DigitalOcean’s destroy workflow asks you to review associated resources; leaving a volume or snapshot behind can preserve data, while deleting one can destroy the only remaining copy.
Provider procedures
DigitalOcean Droplets
DigitalOcean documents two relevant controls:
- Rebuild: open the Droplet’s management page, choose the Rebuild action, select the desired image and confirm. The operation wipes the Droplet disk and writes the selected image. The provider lists IP retention as a reason to use Rebuild.
- Destroy: open the Droplet’s destroy control, review the resources selected for removal and confirm the irreversible deletion. Provision a new Droplet afterward with the image, region and size you require.
DigitalOcean also documents control-panel, doctl and API paths for destroy operations. Use the provider’s current command or endpoint syntax from its documentation rather than copying an old script, and require an explicit confirmation in automation so an incorrect Droplet ID cannot remove production infrastructure.
The provider’s rebuild documentation was verified on 25 August 2026, its destroy documentation on 13 July 2026, and its quickstart on 3 September 2026. Interface labels can change, so check the current confirmation screen and read which snapshots, volumes, backups and IP resources are included.
Hetzner Cloud servers
In the Hetzner Cloud Console, select the server, choose Rebuild, select the desired operating system and confirm. This replaces the server’s disk. If you need a wholly new resource, delete the server and create another one instead; Hetzner recommends that approach when reinstalling so settings are new and up to date.
Before confirming deletion, inspect volumes, primary and floating IPs, backups, snapshots and firewalls. Retain any independent resource you intend to attach to the replacement, and remove it only when you have verified that it is no longer needed.
Rank #4
Hetzner dedicated servers
For a dedicated server managed through Robot, use the Linux installation function in the Robot interface, or boot the machine into the Rescue System and run Hetzner’s installimage workflow. Select the target Linux distribution and review the generated configuration before committing it. Rescue installation is useful when the installed system cannot boot or accept SSH connections, but it still overwrites the selected disks; preserve data first.
A complete wipe-and-rebuild runbook
- Schedule a maintenance window. Stop write-heavy jobs, announce the outage and identify who can approve the final deletion.
- Freeze changes. Disable deployments and background workers so the backup represents a known state.
- Export and verify backups. Dump databases, copy files and configuration, test extraction or restoration and record where the clean copies live.
- Capture dependencies. Record provider IDs, region, plan, image, IPs, DNS, volumes, snapshots, firewalls, load balancers, certificates, cron jobs and external allowlists.
- Choose the operation. Use Rebuild if retaining the instance or IP is important and the provider supports it; otherwise choose destroy/recreate.
- Preserve external resources. In the confirmation screen, deselect volumes, snapshots, backups or IP resources that must survive, and verify that no required object is being removed.
- Run the provider action. Confirm the image and region, then wait for the provider to report completion. Do not interrupt the operation or attempt to log in until the new system is reachable.
- Test the initial console or SSH path. Use the provider console or rescue access if network rules prevent SSH. Confirm that the reported OS, disk layout and hostname match your plan.
- Harden before restoring data. Apply updates, create a normal administrative account, install its SSH public key, configure a firewall and enable monitoring and backups.
- Restore in stages. Restore the database first, then application files and services. Validate each service locally before exposing it publicly.
- Rotate secrets. Replace passwords, API tokens, database credentials, deployment keys and certificates when the old system may have been copied or compromised.
- Cut over and monitor. Update DNS only after local and external checks pass. Watch logs, resource usage, certificate status, scheduled jobs and application errors throughout the first operating period.
First-login hardening
A fresh image is not a finished server. Exact package commands depend on the distribution, but the order matters:
- Apply the distribution’s security updates before installing the application.
- Create a named administrative user with controlled
sudoprivileges; do not perform daily work as root. - Install an SSH public key for that user and test a second session before changing root or password-login settings.
- Configure a host firewall that permits SSH from your administration network and only the application ports that are required.
- Disable unused services, remove temporary installation credentials and check listening sockets.
- Enable provider backups, independent backups and monitoring; verify that alerts reach a real person.
- Set the correct hostname, time zone and time synchronization, then install the application from trusted, pinned sources.
Hetzner’s setup guidance explicitly recommends a non-root user and SSH-key authentication. Do not disable the only working access method until the replacement account has successfully logged in from a separate terminal.
If the VPS was hacked
Assume that credentials and local evidence may have been exposed. A rebuild is preferable to trying to “clean” a compromised live filesystem, because an attacker could have altered binaries, startup jobs, accounts, SSH keys or kernel components.
Best Value
Containment
- Isolate the server with the provider firewall or power it off if evidence preservation is not required.
- Revoke or rotate cloud API keys, deployment tokens, database passwords, SSH keys and TLS private keys that were present on the machine.
- Preserve relevant logs and provider audit records separately if you need an incident timeline or legal evidence.
- Check neighboring systems and CI/CD accounts for reused credentials or unauthorized access.
Rebuild from trusted inputs
Do not restore executables, unknown scripts, shell history or system configuration wholesale from the compromised disk. Reinstall the operating system through the provider, recreate users manually, update packages and restore only verified application data and reviewed configuration. Reissue certificates and secrets rather than copying private material from the old host.
Use console or rescue access when SSH is unavailable
Provider web consoles, Rescue Systems and out-of-band installation tools let you reinstall when the old system will not boot or its firewall blocks SSH. Console access does not make a destructive action reversible; it only provides another path to perform the provider’s documented rebuild or installation process.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Restore and validate the new installation
Restore data in dependency order
- Install the runtime and system packages required by the application.
- Create database users and schemas, then import a verified dump.
- Restore application files and ownership permissions.
- Recreate environment configuration with newly rotated secrets.
- Enable services and scheduled jobs one at a time.
Test locally and externally
- Check service status and logs for startup failures.
- Connect to the database using the application account, not only an administrator account.
- Exercise login, uploads, background jobs, email or webhook delivery and any payment or API integration that the application uses.
- Test HTTPS from outside the VPS, including certificate chain, redirects and IPv6 if an AAAA record exists.
- Confirm firewall behavior from an allowed network and an untrusted network.
- Verify that cron jobs and systemd timers run at the expected times.
Only after these checks should you update DNS or reassign a retained floating IP. Keep the old system or its snapshot isolated until the new server has operated successfully for the period required by your recovery plan.
Common failure modes and fixes
| Symptom | Likely cause | Corrective action |
|---|---|---|
| The SSH session dies while “wiping” | The live root filesystem was being deleted or critical services were stopped. | Use the provider’s Rebuild, Rescue or console workflow instead of deleting files from the running OS. |
| The new server has no expected data | The backup was never restored, or the wrong snapshot, volume or region was selected. | Stop application writes, identify the verified backup and restore it explicitly; do not assume a rebuild carries disk data forward. |
| DNS still reaches the old host | Resolver or browser caching, an unchanged AAAA record or a second DNS provider. | Check authoritative records, both A and AAAA, TTLs and cached responses before changing application settings. |
| SSH access is locked out | The firewall or root-login change was made before a tested key-based account existed. | Use the provider console or Rescue System, correct the firewall and authorized-keys files, and test a second session before tightening access again. |
| Unexpected provider charges continue | A volume, snapshot, backup, floating IP or load balancer survived instance deletion. | Review each resource separately and delete only objects that are no longer needed after confirming backups. |
| The compromise returns after restoration | Compromised credentials, startup files or unreviewed scripts were restored. | Rotate every exposed secret, reinstall from trusted images and restore only reviewed data and configuration. |
Practical decision examples
You need the same public IP
Inventory the address and any dependent allowlists, verify that the provider’s Rebuild action retains it, back up the disk and rebuild in place. If the address is a separate floating or reserved resource, confirm that it will remain attached or can be reassigned before deleting anything.
You are moving to a new region or plan
Create the replacement server first when possible, restore a verified backup, test it using a temporary hostname or direct address, then change DNS. This minimizes downtime and gives you a rollback path. Destroy the old instance only after the new deployment and backup schedule are confirmed.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →The machine was compromised and the IP is blocklisted
A rebuild removes the guest disk but may not change the public address or its reputation. Rotate secrets, investigate the incident and ask the provider about address replacement if the address itself must change. Do not present a clean OS as proof that the network reputation or every external credential has been reset.
Final pre-deletion checklist
- Database and file backups exist outside the VPS and have been tested.
- Secrets, SSH keys, certificates, cron jobs and firewall rules are documented.
- Provider IDs, region, plan, image, IPs, volumes, snapshots and load balancers are recorded.
- DNS A, AAAA, reverse-DNS and TTL details are known.
- You have selected Rebuild or destroy/recreate for a specific reason.
- The confirmation screen clearly shows which resources will be deleted and which will remain.
- A maintenance window, console or rescue path and rollback plan are available.
For a normal reset, provider Rebuild is the controlled way to replace the VPS disk. For a genuinely new server or a compromised host, delete-and-recreate can provide a cleaner boundary, but only after you preserve independent resources and verified backups. In both cases, the work is complete only when the new system is hardened, restored from trusted data and validated from outside the VPS.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
