Dragging public_htmlinto an FTP client can produce a reassuringly large folder and still miss the files needed for recovery. Hidden server rules may be omitted, a large upload can time out, or a symlink can send the client into the wrong tree. Plain FTP adds another problem by exposing credentials and data in transit.
For a manual filesystem backup, prefer SFTP with a verified host key. Define the real WordPress root, decide how links and changing files will be handled, save the transfer log, and compare the source with the copy. Remember that files are only half of a complete WordPress recovery point; the database must be captured separately.
What it means
SFTP transfers files through the SSH protocol and protects both authentication and content in transit. It is different from plain FTP and from FTPS. A secure connection, however, does not prove that the correct directories were selected or that every file arrived.
A WordPress file backup normally needs the active web root, wp-content, wp-config.php, hidden server files such as .htaccesswhere used, and any custom directories outside the standard layout. Whether WordPress core is included depends on the recovery plan, but exclusions must be deliberate and documented.
A realistic WordPress example
Before closing a hosting account, an owner downloads public_htmlover hotel Wi-Fi. The client uses plain FTP, hides dotfiles, skips one large media file after a timeout, and follows a symlink into an old release directory. The final folder contains thousands of files, so the owner assumes it is complete.
A second attempt uses SFTP after the host-key fingerprint is confirmed through the hosting panel. The operator identifies the active web root, includes hidden files, records symlinks without recursively copying unrelated targets, and downloads into a new dated directory. The saved report reveals two failed transfers, which are retried and verified before the hosting account is closed.
Why it matters and when to use it
SFTP is useful when the WordPress dashboard is unavailable, a hosting account is being migrated, or a path-level copy is needed independently of a backup plugin. It can also retrieve individual files during incident analysis. It is not a substitute for a database export when the goal is full-site restoration.
Perform the copy during a quiet period or document which files may change while it runs. Uploads, generated caches, logs, and active deployment directories can shift during a long transfer. The recovery package should distinguish required content from disposable cache and temporary data.
A straightforward route for beginners
- Confirm the server name, port, SFTP account owner, and host-key fingerprint through a trusted channel.
- Resolve the active WordPress web root and list custom paths, hidden files, and symlinks before copying.
- Check local free space and download into an empty, dated directory without overwriting a known good copy.
- Save the client log and investigate every failed, skipped, or permission-denied entry.
- Compare file counts and total bytes, then checksum critical files and representative large media.
- Create and verify a matching database export if the package must restore the complete site.
The advanced route
For large trees, generate a server-side manifest where possible and compare it with the local inventory. Treat files modified during the transfer as exceptions to be recopied or captured during a documented freeze. A resumable client should verify completed files rather than trusting offsets blindly.
Set a clear symlink policy: preserve the link, copy its target once, or exclude it with an explanation. Following links recursively can duplicate release trees or leave the intended account boundary. Preserve permissions and timestamps only where the restore procedure needs them, and keep secrets in encrypted storage after download.
Risks, common mistakes, backup, and rollback
Never accept an unexpected SFTP host-key change without verifying it through the provider. Other warning signs are an unclear source root, hidden permission errors, insufficient local disk space, missing logs, and a transfer that reports success despite skipped files. The progress bar is not an integrity check.
If a download is incomplete, keep any earlier valid backup and retry into a separate destination. Do not merge an uncertain copy over the known good set. Before deleting the source account, open configuration files and media from the copy, reconcile every error, and confirm that the accompanying database belongs to the same recovery window.
How AIOWS helps:
AIOWS Backup Manager
AIOWS Backup Manager covers the backup operations it supports inside WordPress. A manual SFTP download remains an external filesystem operation, so its server path, transfer log, exclusions, and verification need to be recorded separately.
The module is still relevant when the SFTP copy forms part of a broader recovery plan. Compare the external file set with the database and file scope expected for the site, and keep the artifacts tied to the same named recovery point. If a supported AIOWS backup job is also used, inspect its result independently rather than assuming the manual copy and module output contain identical paths.
AIOWS cannot verify an SFTP host key, detect files skipped by a desktop client, or repair an incomplete manual transfer. It also cannot make a file-only download a complete WordPress backup without the necessary database. Use Backup Manager for its supported work and treat the SFTP report, source inventory, database export, and restore test as separate evidence.
Related AIOWS articles
- WordPress Site Backup: Files and Database Guide
- Create a WordPress Files Backup Without Missing Critical Paths
- Migrate WordPress with Minimal Downtime and a Controlled Cutover
Conclusion and recommended route
Prefer host-key-verified SFTP, identify the active WordPress paths, include hidden and custom files deliberately, and reconcile the transfer report against an inventory. Pair the finished file set with a compatible database export before calling it a full-site backup.
