{"id":925,"date":"2011-01-19T21:34:16","date_gmt":"2011-01-19T16:04:16","guid":{"rendered":"https:\/\/www.host.co.in\/knowledgebase\/?p=925"},"modified":"2026-08-20T13:34:29","modified_gmt":"2026-08-20T08:04:29","slug":"backup-on-a-dedicated-server-using-an-ssh-connection","status":"publish","type":"post","link":"https:\/\/www.host.co.in\/kb\/backup-on-a-dedicated-server-using-an-ssh-connection\/","title":{"rendered":"The Process To Take Backup On A Dedicated Server Using An SSH Connection"},"content":{"rendered":"

If your dedicated server<\/a> doesn’t have a control panel, or you just prefer working from the command line, SSH gives you full control over backing up both your files and your databases. Here’s how to do it properly, that’s actually usable if you ever need to restore from it.<\/p>\n

Before You Start<\/h2>\n

Connect to your server via SSH using your terminal (Mac\/Linux) or a client like PuTTY (Windows):<\/p>\n

bash<\/em>
\nssh username@your-server-ip<\/em><\/p>\n

A quick security note:<\/strong> logging in directly as root works, but it’s better practice to SSH in as a regular sudo-enabled user and use sudo for privileged commands. If your server still only allows root login, consider setting up a separate admin user and disabling direct root SSH access once you’re comfortable with the process.<\/p>\n

How to Back Up a MySQL\/MariaDB Database<\/h2>\n

Export database to .sql file via mysqldump:<\/p>\n

bash<\/em>
\nmysqldump -u your_username -p your_database_name > backup_$(date +%F).sql<\/em><\/p>\n

You’ll be prompted for your MySQL password. The $(date +%F) part of commands automatically adds today’s date at the end of the filename, for example, backup_2026-08-07.sql. Due to which you can easily find the right backup later.<\/p>\n

To back up every database on the server at once:<\/h2>\n

bash<\/em>
\nmysqldump -u your_username -p –all-databases > all_databases_$(date +%F).sql<\/em><\/p>\n

Backing Up Website Files<\/h2>\n

A database backup alone doesn’t back up your actual website files, uploads, or configuration. Use tar to archive a directory:<\/p>\n

bash<\/em>
\ntar -czvf website_backup_$(date +%F).tar.gz \/var\/www\/html<\/em><\/p>\n

This compresses everything in \/var\/www\/html (adjust the path to wherever your website actually lives) into a single .gz file.<\/p>\n

Move the Backup Off the Server<\/h2>\n

This is the step the original process skipped, and it’s the one that actually matters. A backup that lives only on the same server doesn’t protect you if that server has a hardware failure, gets compromised, or is lost entirely. Copy backups somewhere else using scp or rsync:<\/p>\n

bash<\/em>
\nscp backup_2026-08-07.sql user@remote-server:\/path\/to\/backup\/folder\/<\/em><\/p>\n

Or sync a whole backup directory with rsync:<\/p>\n

bash<\/em>
\nrsync -avz \/home\/backups\/ user@remote-server:\/backups\/<\/em><\/p>\n

Automate It With a Cron Job<\/h2>\n

Manual backups get forgotten so automate the backup process:<\/p>\n

bash<\/em>
\ncrontab -e<\/em><\/p>\n

Add a line to run a database backup daily at 2 AM:<\/p>\n

bash<\/em>
\n0 2 * * * mysqldump -u your_username -p’your_password’ your_database > \/home\/backups\/db_$(date +\\%F).sql<\/em><\/p>\n

Note:<\/strong> storing a plaintext password in a cron job isn’t ideal from a security standpoint. Therefore, store credentials in a .my.cnf file with restricted permissions (chmod 600) and omit the password from the command entirely, because it is a more secure approach for it.<\/p>\n

Restoring From a Backup<\/h2>\n

Database:<\/strong>
\nbash<\/em>
\nmysql -u your_username -p your_database_name < backup_2026-08-07.sql<\/em><\/p>\n

Files:<\/strong>
\nbash<\/em>
\ntar -xzvf website_backup_2026-08-07.tar.gz -C \/var\/www\/html<\/em><\/p>\n

Best Practices<\/h2>\n
    \n
  • Follow the 3-2-1 rule: 3 copies of your data, on 2 different types of storage, with at least 1 copy offsite.<\/li>\n
  • Verify your backups occasionally by actually restoring one in a test environment since a backup you’ve never tested is a backup you can’t fully trust.<\/li>\n
  • Back up files and databases separately but on the same schedule, so they stay in sync with each other.<\/li>\n
  • Set a retention policy. Always keep only your recent backups and delete older ones automatically to free up disk space.<\/li>\n
  • Consider a managed option if scripting this yourself isn’t ideal \u2014 our Backup Solutions service handles automated, offsite, encrypted backups without any manual scripting.<\/li>\n<\/ul>\n

    Need Help?<\/h2>\n

    If you are unsure about how to back up your data properly, or facing issues while backing up your data, then reach out to our support team or chat with us.<\/p>\n","protected":false},"excerpt":{"rendered":"

    If your dedicated server doesn’t have a control panel, or you just prefer working from the command line, SSH gives you full control over backing up both your files and your databases. Here’s how to do it properly, that’s actually usable if you ever need to restore from it. Before You Start Connect to your […]<\/p>\n","protected":false},"author":14,"featured_media":6745,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[93,1],"tags":[103,211,402,204],"class_list":["post-925","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dedicated-servers-faq","category-dedicated-web-hosting","tag-backup","tag-dedicated-servers","tag-mysql","tag-ssh"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t