Run tar -czvf site-backup.tar.gz public_html for a compressed .tar.gz (the standard on Linux servers), or use zip when you need something a Windows user can open without extra tools. Both work the same way whether you're bundling files for download, moving a site between hosts, or making a quick snapshot before you touch something risky.
On shared hosting you'll usually run these commands via SSH (Security > SSH Access in cPanel, with a client of your choice). On a VPS you manage yourself, you typically have broader filesystem access, so it's worth double-checking the path you're pointing at before you run a command.
Creating a tar.gz archive
The standard way to package a site on Linux is a gzip-compressed tarball:
tar -czvf site-backup.tar.gz /home/username/public_htmlBreaking down the flags: c creates an archive, z compresses it with gzip, v prints each file as it's added (verbose, safe to drop for large sites), and f names the output file. The result is a single site-backup.tar.gz you can download, copy elsewhere, or store as a manual backup on most hosting accounts.
To keep the archive from containing the full absolute path (so it extracts cleanly into the current directory instead of recreating /home/username/public_html), cd into the parent folder first and reference the folder by name:
cd /home/username
tar -czvf site-backup.tar.gz public_htmlExcluding files you don't want
Cache folders, log files, and node_modules bloat an archive without adding anything worth keeping. Exclude them with one or more --exclude flags before the source path:
tar -czvf site-backup.tar.gz --exclude='public_html/wp-content/cache' --exclude='*.log' public_htmlCreating a zip archive
If the archive is headed to someone on Windows, or you prefer zip's format, the syntax is similar:
zip -r site-backup.zip public_htmlThe -r flag recurses into subdirectories, which you need for anything beyond a flat folder of files. Add -x to exclude patterns:
zip -r site-backup.zip public_html -x "public_html/wp-content/cache/*"Not every server has zip installed by default; tar is safer to assume is present. On a VPS you manage yourself, install it with your distro's package manager (apt install zip on Debian/Ubuntu, dnf install zip on AlmaLinux) if it's missing.
Extracting an archive
To unpack a tarball back into files:
tar -xzvf site-backup.tar.gzAnd for a zip file:
unzip site-backup.zipExtract into a scratch directory first if you're restoring over a live site, check the contents, then move things into place. Overwriting public_html directly with an extraction you haven't inspected can undo recent work.
Checking archive size before you download
Before pulling a large archive over FTP or SFTP, check its size so you're not surprised mid-transfer:
du -h site-backup.tar.gzIf a site is large enough that a full archive is unwieldy, consider archiving just the parts you need (a specific plugin's uploads folder, a single subdomain) rather than the whole document root.
Where this fits with WordPress and staging
Manual tar/zip archives are a good complement to, not a replacement for, a proper backup routine. If the goal is moving your site to a different platform entirely rather than backing it up, note that archiving files doesn't affect your domain's DNS. That's a separate step, covered in pointing your domain or subdomain to Shopify, Wix, and other services, if that's the direction you're headed.
Shared hosting vs VPS
On shared hosting, you're archiving within your own account, so permissions are rarely an issue and there's no risk of touching another customer's files. On a VPS, broader filesystem access means tar and zip can reach more than your own home directory, which is exactly why care matters: double-check the path you're pointing at before you run the command, especially if you're scripting this as part of a cron job.
If an archive command fails with a permissions error you can't resolve, or a restore didn't come out the way you expected, open a ticket from the portal. It's real people looking at it, not a bot.