Use cp to copy a file or directory and keep the original in place. Use mv to move it, or to rename it (a rename is a move to a new name in the same directory). Both commands work the same way in an SSH session on shared hosting or a VPS shell, but where you run them and how much you can touch depends on the kind of hosting you're on.
Basic syntax
Both commands take a source and a destination:
cp source destination mv source destination
Copy a single file into a folder:
cp index.html backup/index.html
Copy a whole directory, recursively, with -r:
cp -r public_html backup_html
mv doesn't need -r for directories, since it changes the directory's location in the filesystem rather than duplicating its contents:
mv old-folder new-folder
Rename a file by "moving" it to a new name in the same place:
mv config.php.bak config.php
Useful flags
-i(interactive) - asks before overwriting an existing file. Worth aliasing on by default if you've ever clobbered something by accident.-n(no-clobber) - the opposite: never overwrites, silently skips instead. Good for scripted copies where you don't want surprises.-v(verbose) - prints each file as it's copied or moved, useful when you're not sure the command matched what you expected.-p(preserve) - keeps the original timestamps, ownership, and permissions on the copy. Without it,cpgives the new file a fresh modification time and your current permissions.
Combine them as needed: cp -riv source/ dest/ copies recursively, asks before overwriting, and shows progress.
Wildcards and multiple files
Both commands accept shell globs. Copy every .log file into an archive folder:
mv *.log logs-archive/
Copy everything except one file by combining cp with a loop or find, since neither command has a built-in exclude flag:
find . -maxdepth 1 -type f ! -name "wp-config.php" -exec cp {} backup/ \;
When the destination is a directory, both commands drop the source files into it by name. When the destination is a filename that doesn't exist yet, they create it. Always double check which case you're in, especially with mv, since there's no confirmation prompt by default and no undo.
Where this matters on shared hosting
On shared and WordPress hosting, your web root is a specific directory under your account, and any files you copy or move need to land there to be served publicly. The File Manager tile on your service page handles copy and move visually if you'd rather not use a shell, and it's the same underlying filesystem, so changes made one way show up the other way immediately.
If you're working over SSH instead, remember you're scoped to your own account, so paths are relative to your home directory unless you use an absolute path. A common mistake is running mv from the wrong working directory and moving a file out of public_html instead of into it, which makes the file stop being served without any error message. Run pwd first if you're not sure where you are.
Where this matters on a VPS
On a VPS, you have root, so cp and mv can touch anything on the filesystem, including system files and other users' directories if you've set up multiple accounts. That's more power and more risk. Moving or overwriting the wrong system file with a careless mv can break services that were running fine a second earlier, and there's no automatic safety net catching it for you. Use -i liberally when you're working outside your application's own directory, and be especially careful with commands that combine wildcards and mv against paths like /etc or /var.
When it goes wrong
If you overwrite a file you needed, check whether it's covered by a recent backup before trying anything else. A JetBackup snapshot on shared hosting or your own VPS backup strategy may have a copy from before the mistake. If you're not sure how to restore one file without rolling back everything else, open a ticket through the portal. Support is real humans who can walk through a targeted restore rather than a full account rollback.