A website backup is incomplete unless its database is backed up properly. PHP applications, WordPress sites, CRM systems, ticketing portals, e-commerce websites, custom applications, and many other web platforms commonly store critical information in MySQL or MariaDB databases.

Hostinger provides tools such as hPanel and phpMyAdmin for database management and backup. These are convenient for occasional exports, but administrators managing multiple databases may prefer a method that is faster, repeatable, scriptable, and independent of a browser.

One practical solution is:

Hostinger Shared Hosting → SSH → mysqldump → compressed SQL backup → SFTP/WinSCP → local Windows storage

This article explains the complete process, starting with manual backups and progressing toward automated backups.

Security note: All website names, usernames, database names, hostnames, IP addresses, and paths in this article are fictional examples. Replace them with the values provided by your hosting account.

1. Why Database Backups Matter

A website usually consists of at least two major components:

Website files, such as:

PHP files
HTML/CSS/JavaScript
Images
Documents
Themes
Plugins
Configuration files
Uploads

and a database, which may contain:

Users
Orders
Customers
Tickets
Posts
Pages
Settings
Transactions
Product information
Application configuration
Logs
Form submissions

Downloading only public_html therefore does not necessarily constitute a complete website backup.

For example, consider:

exampleportal.com

with:

/home/u987654321/domains/exampleportal.com/public_html/

The files may contain the PHP application, but customer and application data could reside in:

u987654321_portaldb

Both components should be protected.

2. Available Database Backup Methods

There are several ways to back up databases from shared hosting.

phpMyAdmin

This is convenient for manually exporting individual databases through a browser.

It is particularly useful when SSH access is unavailable.

However, repeatedly exporting many databases manually becomes inconvenient.

Hostinger Backup Facilities

Hostinger plans may provide hosting backup and restore functionality through hPanel. Availability, retention, and functionality depend on the hosting plan and current Hostinger services.

Provider backups are useful, but organizations may still want an independent copy outside the hosting account.

SSH and mysqldump

This is one of the most useful approaches when SSH access is available.

The workflow is:

MySQL
   ↓
mysqldump
   ↓
SQL file
   ↓
gzip
   ↓
SQL.GZ file
   ↓
SFTP
   ↓
Windows PC / NAS / Backup Storage

WinSCP

WinSCP provides an easy graphical interface for SFTP transfers and also supports scripting.

WinSCP should not be confused with a database backup engine. Its main job here is to transfer the database dump from the server to another system.

3. Requirements

Before proceeding, you should have:

Hostinger hosting account
SSH access enabled
SSH hostname/IP
SSH port
SSH username
SSH password/key
MySQL database name
MySQL username
MySQL password
MySQL hostname
WinSCP installed on Windows

SSH credentials and MySQL credentials may be different.

Do not assume that the password used to log into SSH is the password used by MySQL.

4. Enable SSH Access in Hostinger

Log in to Hostinger hPanel and locate the SSH Access section for the hosting account.

Depending on the current hPanel interface and hosting plan, the exact navigation can vary.

You are looking for information similar to:

SSH Host:     server123.example-host.net
SSH Port:     65002
SSH Username: u987654321
SSH Status:   Enabled

Use the exact host, port, and username shown by Hostinger.

Do not automatically assume:

Port 22

Shared-hosting environments can use a different SSH port.

5. Configure WinSCP

Open WinSCP and create a new site.

Use:

File protocol: SFTP

Host name:
server123.example-host.net

Port:
65002

Username:
u987654321

Password:
************

Then click:

Login

On the first connection, WinSCP may display the SSH server's host-key fingerprint. Verify it against information from the hosting provider when available before accepting it.

Once connected, WinSCP generally displays:

LOCAL WINDOWS COMPUTER       REMOTE HOSTING SERVER

C:\                          /home/...
D:\                          domains/
                             ...

This makes file transfer straightforward.

6. Troubleshooting WinSCP Connection Timeouts

An error such as:

Network error:
Connection to "203.0.113.25" timed out

means the connection failed before authentication completed.

That is different from:

Access denied

or:

Authentication failed

A timeout can result from:

Incorrect SSH hostname/IP
Incorrect SSH port
SSH access not enabled
Network/firewall restrictions
ISP/network connectivity problem
Server-side restrictions
Temporary hosting/server issue

Test the SSH port from Windows PowerShell:

Test-NetConnection server123.example-host.net -Port 65002

Look for:

TcpTestSucceeded : True

If it returns:

TcpTestSucceeded : False

investigate the host, port, SSH status, network, firewall, or hosting environment before troubleshooting the username/password.

7. Open an SSH Terminal

Once SFTP connectivity is confirmed, connect to the server through SSH.

For example:

ssh -p 65002 u987654321@server123.example-host.net

Enter the SSH password when requested.

After successful login, you may see:

u987654321@server:~$

8. Check Whether mysqldump Is Available

Run:

mysqldump --version

Depending on the server environment, you might see a MySQL or MariaDB implementation.

If mysqldump is unavailable, try:

mariadb-dump --version

Use whichever compatible dump utility the hosting environment provides.

9. Obtain the MySQL Credentials

For each database you want to back up, determine:

Database Name
Database Username
Database Password
Database Host

For demonstration purposes:

Database:
u987654321_customerdb

Username:
u987654321_dbadmin

Host:
localhost

These are examples only.

Use the values supplied for your actual Hostinger database.

10. Create a Secure Backup Directory

Do not create database backups inside:

public_html

Instead, create a directory outside the publicly served website directory:

mkdir -p ~/sql_backups

Check it:

ls -ld ~/sql_backups

You can also restrict its permissions:

chmod 700 ~/sql_backups

This is important because SQL dumps can contain extremely sensitive information.

Depending on the application, an SQL dump might contain:

Customer names
Email addresses
Phone numbers
Account information
Configuration data
API-related settings
Password hashes
Application records
Private business information

Database backups should therefore be treated as sensitive data.

11. Create Your First MySQL Backup

A typical dump command is:

mysqldump \
-h localhost \
-u u987654321_dbadmin \
-p \
--single-transaction \
--quick \
--triggers \
u987654321_customerdb \
> ~/sql_backups/customerdb.sql

After pressing Enter, you should see:

Enter password:

Enter the database user's password.

The password will normally not be displayed while typing.

That is expected.

12. Why Use --single-transaction?

For transactional tables such as InnoDB, this option helps obtain a consistent dump without locking tables for the duration of the export in the same way a traditional table-locking dump might.

--single-transaction

This is especially useful for active websites where data may continue to be accessed while the backup runs.

However, it does not provide the same consistency guarantees for non-transactional tables.

13. Why Use --quick?

The option:

--quick

makes mysqldump retrieve rows incrementally rather than buffering an entire large table in memory.

This is useful on hosting environments where available resources may be limited.

14. Why Include Triggers?

Use:

--triggers

to include triggers associated with dumped tables.

For applications that rely on database triggers, backing up only table data and structure without the required triggers can produce an incomplete logical backup.

15. Routines and Events

Some databases may also use stored procedures, functions, or scheduled events.

Where the hosting account has the necessary privileges and the application requires them, options can include:

--routines
--events

For example:

mysqldump \
-h localhost \
-u u987654321_dbadmin \
-p \
--single-transaction \
--quick \
--triggers \
--routines \
--events \
u987654321_customerdb \
> ~/sql_backups/customerdb.sql

On shared hosting, the account may not have privileges for every feature. If the command reports a permission error, do not blindly suppress it. Determine whether the affected objects are actually required and which privileges the hosting environment provides.

16. Check Whether the Backup Was Created

Run:

ls -lh ~/sql_backups/

Example:

-rw------- 1 u987654321 users 42M Jul 26 18:45 customerdb.sql

A non-zero file size is a useful first check, but file size alone does not prove that a backup is complete or restorable.

You should also check whether mysqldump exited successfully and periodically perform restoration tests.

17. Compress the SQL Backup

SQL dumps often compress extremely well.

Run:

gzip ~/sql_backups/customerdb.sql

The result becomes:

customerdb.sql.gz

Check it:

ls -lh ~/sql_backups/

You might see:

customerdb.sql.gz    8.4M

even though the original SQL dump was much larger.

This is normal.

18. Why Can a Database Dump Be Much Smaller Than the Database Size?

This is an important point.

Suppose the hosting panel reports:

Database size: 380 MB

while the exported SQL dump is:

32 MB

That does not automatically mean data is missing.

The hosting/database storage measurement can include physical structures and overhead that are not represented the same way in a logical SQL dump.

A logical dump primarily contains instructions required to reconstruct database objects and data.

After gzip compression, the difference can become even larger because SQL text and repetitive data often compress efficiently.

Therefore:

Physical database storage
≠
SQL dump size
≠
Compressed SQL dump size

The best validation is a successful test restoration, not comparing file sizes alone.

19. Download the Backup Using WinSCP

Return to WinSCP.

Refresh the remote directory and navigate to:

/home/u987654321/sql_backups/

You should see:

customerdb.sql.gz

On the local side, create a folder such as:

D:\Hosting Backups\

Then copy:

customerdb.sql.gz

from the remote server to the local Windows folder.

You now have an independent local database backup.

20. Use Date-Based Backup Names

Avoid repeatedly overwriting:

customerdb.sql.gz

Use timestamps instead.

For example:

mysqldump \
-h localhost \
-u u987654321_dbadmin \
-p \
--single-transaction \
--quick \
--triggers \
u987654321_customerdb \
| gzip > ~/sql_backups/customerdb_$(date +%Y-%m-%d_%H-%M-%S).sql.gz

This performs dumping and compression in one pipeline.

Possible output:

customerdb_2026-07-26_18-30-00.sql.gz
customerdb_2026-07-27_18-30-00.sql.gz
customerdb_2026-07-28_18-30-00.sql.gz

This is much better for maintaining backup history.

21. Backing Up Multiple Databases

Suppose an account contains:

u987654321_main
u987654321_support
u987654321_store
u987654321_crm

Each database can be dumped separately:

main_2026-07-26.sql.gz
support_2026-07-26.sql.gz
store_2026-07-26.sql.gz
crm_2026-07-26.sql.gz

Separate backups are often convenient because an individual database can be restored without extracting an unnecessarily large combined dump.

On shared hosting, do not assume that:

mysqldump --all-databases

will work.

A shared-hosting MySQL account generally does not have administrative access to every database on the database server.

Back up the databases your hosting account/database users are authorized to access.

22. Automating Downloads with WinSCP

WinSCP supports scripting, which makes it useful for automated SFTP downloads.

A typical architecture is:

Hostinger
    ↓
MySQL Database
    ↓
mysqldump
    ↓
gzip
    ↓
Remote Backup Directory
    ↓
SFTP / WinSCP
    ↓
Windows Backup Directory

Windows Task Scheduler can then launch the backup/transfer process automatically.

For example:

Every day at 11:30 PM

The resulting Windows structure could be:

D:\Hostinger-DB-Backup\
    2026-07-26\
        main.sql.gz
        support.sql.gz
        store.sql.gz

    2026-07-27\
        main.sql.gz
        support.sql.gz
        store.sql.gz

23. Recommended Automated Backup Workflow

A more professional implementation should perform these operations:

1. Start backup job
2. Connect securely
3. Dump database
4. Check dump command result
5. Compress backup
6. Validate compressed archive
7. Download through SFTP
8. Verify local file exists
9. Record backup size
10. Maintain logs
11. Apply retention policy
12. Report failures

Do not delete the server-side copy until the local download has been confirmed successfully, if server storage permits.

24. Password Security

Avoid putting a database password directly into command-line scripts such as:

mysqldump -u USER -pMySecretPassword DATABASE

This can expose credentials through scripts, shell history, process information, logs, or accidental sharing.

Interactive execution can use:

-p

and prompt for the password.

For unattended automation, use a secure credential mechanism appropriate to the hosting environment rather than storing plaintext passwords in ordinary .bat, .ps1, or shell files.

25. Never Store SQL Dumps in Public Web Directories

Avoid locations such as:

public_html/backup.sql
public_html/db.sql.gz
public_html/backups/database.sql

A configuration mistake could potentially make such files downloadable through the web.

Prefer a location outside the site's document root, such as:

~/sql_backups/

and apply restrictive permissions where supported.

26. Local Backup Retention

Keeping every daily backup forever may eventually consume substantial disk space.

A possible retention strategy is:

Daily backups:   30 days
Weekly backups:  12 weeks
Monthly backups: 12 months

The appropriate policy depends on database size, business requirements, legal requirements, and available storage.

27. Use the 3-2-1 Backup Principle

For important business databases, consider the 3-2-1 backup principle:

3 copies of data, on 2 different types or locations of storage, with 1 copy kept off-site or otherwise isolated.

For example:

Copy 1:
Live database on hosting

Copy 2:
Windows backup drive/NAS

Copy 3:
Separate cloud/off-site backup

A backup stored only on the same hosting account as the live database does not provide strong protection against account loss or hosting-level incidents.

28. Backup Verification Is Essential

A backup should not be considered reliable merely because:

backup.sql.gz

exists.

At minimum, verify the compressed archive:

gzip -t customerdb.sql.gz

If successful, the command generally returns without an error.

For higher assurance, periodically restore a backup into a separate test database and verify that:

Tables exist
Expected row/data is present
Views are available where required
Triggers are present
Application-critical objects are restored
Character encoding is correct

A successful restoration test is one of the strongest ways to confirm that your backup process is actually useful.

29. Restore a .sql.gz Backup

A compressed dump can be restored to an appropriate destination database with:

gunzip < customerdb.sql.gz | mysql \
-h localhost \
-u u987654321_dbadmin \
-p \
u987654321_restoretest

Be extremely careful with restore commands.

Use a dedicated test database when validating backups. Accidentally restoring into a production database can overwrite or conflict with live data.

30. phpMyAdmin vs SSH/mysqldump vs WinSCP

The tools complement each other.

A particularly useful combination is:

mysqldump + gzip + WinSCP + Windows Task Scheduler

31. Recommended Backup Architecture

For a business website hosted on shared hosting:

                    HOSTING SERVER
                         │
                   MySQL Database
                         │
                     mysqldump
                         │
                       gzip
                         │
                ~/sql_backups/
                         │
                        SFTP
                         │
                      WinSCP
                         │
                 Windows Backup PC
                         │
              D:\Hosting-DB-Backup
                         │
                 ┌───────┴───────┐
                 │               │
                NAS        Cloud/Off-site

This provides more independence than relying exclusively on one backup location.

Frequently Asked Questions

1. Can WinSCP directly back up a MySQL database?

Not by itself. WinSCP is primarily used for secure file transfer. The database should first be exported using a database-aware tool such as mysqldump or mariadb-dump, after which WinSCP can download the resulting file.

2. Is WinSCP suitable for Hostinger shared hosting?

Yes, provided SFTP/SSH access is available for the hosting account and configured correctly.

3. Why does WinSCP show a connection timeout?

Common causes include an incorrect SSH host, incorrect SSH port, disabled SSH access, firewall/network restrictions, or a temporary server/connectivity problem.

4. Can I use port 22?

Use the port Hostinger provides for your SSH account. Do not assume it is 22.

5. Is the SSH password the same as the database password?

Not necessarily. SSH and MySQL are separate services and may use different credentials.

6. Where should SQL backups be stored on the server?

Prefer a private directory outside public_html, for example:

~/sql_backups/

7. Should I put backups in public_html temporarily?

It is better not to. SQL dumps may contain sensitive information and should not be exposed through a web-accessible directory.

8. Why is my SQL export much smaller than the database size shown by hosting?

A logical SQL dump and physical database storage are measured differently. Database storage may include indexes, allocated pages, fragmentation and overhead. SQL text can also compress significantly.

9. Does a smaller SQL dump mean the backup is incomplete?

Not necessarily. Validate the dump command, archive integrity, expected database objects, and ideally perform a test restore.

10. Can I back up all databases with one command?

Technically MySQL supports options for multiple databases, but shared-hosting privileges may restrict what a database user can access. Backing up each authorized database separately is often easier to manage.

11. Can the process run automatically every night?

Yes. SSH commands, scripts, WinSCP scripting, and Windows Task Scheduler can be combined to create scheduled backups.

12. Can the SQL file be compressed automatically?

Yes. For example:

mysqldump [options] DATABASE | gzip > database.sql.gz

13. What does .sql.gz mean?

It is an SQL dump compressed using gzip.

14. Is .sql.gz better than .sql?

It usually requires much less storage and transfer bandwidth. The uncompressed SQL dump can still be recovered when needed.

15. How frequently should a database be backed up?

It depends on how frequently data changes. A relatively static website might need daily backups, while a busy transactional system may require more frequent backups and a more advanced recovery strategy.

16. Can I delete the remote backup after downloading it?

Yes, but only after confirming the backup process succeeded and the local copy is valid. Keeping a short remote retention period may provide additional protection if storage allows.

17. Can Windows Task Scheduler automate WinSCP?

Yes. WinSCP supports scripting and command-line operation that can be launched by Task Scheduler.

18. Should database passwords be stored inside a BAT file?

Plaintext database passwords in ordinary scripts should be avoided. Use an appropriate protected credential mechanism for unattended jobs.

19. Is phpMyAdmin still useful if SSH backups are configured?

Yes. phpMyAdmin remains useful for database administration, inspection, queries, manual exports, imports, and troubleshooting.

20. What is the best way to know whether my backup really works?

Perform periodic restoration tests into a separate test database. A backup strategy should be evaluated by its ability to restore data, not merely its ability to create files.

Conclusion

For Hostinger shared hosting with SSH access, a strong database backup workflow is:

MySQL/MariaDB → mysqldump → gzip → private server directory → SFTP/WinSCP → Windows storage → secondary/off-site backup

WinSCP provides the transfer layer, while mysqldump or mariadb-dump creates the logical database backup.

For administrators managing several websites or databases, automating the process provides a substantial advantage over manually exporting every database through phpMyAdmin. The automation should include error detection, logging, compression, local verification, retention, and periodic restoration testing.

Most importantly, creating a backup file is only half the job. A backup should be secure, independently stored, monitored, and periodically tested for restoration.

#Hostinger #MySQL #MySQLBackup #DatabaseBackup #WinSCP #SSH #SFTP #mysqldump #MariaDB #SQLBackup #WebHosting #SharedHosting #HostingerHosting #DatabaseSecurity #BackupAutomation #AutomatedBackup #WindowsBackup #TaskScheduler #DatabaseRecovery #DisasterRecovery #SQL #phpMyAdmin #DatabaseExport #DatabaseRestore #BackupStrategy #BackupSecurity #CloudBackup #OffsiteBackup #LocalBackup #ServerBackup #WebsiteBackup #DataProtection #DataRecovery #DatabaseAdmin #SysAdmin #WebAdministrator #ITSupport #ITAdministration #WindowsAdmin #LinuxCommands #SSHAccess #SFTPSecurity #Gzip #SQLDump #BackupVerification #BackupRetention #InnoDB #WebsiteSecurity #ServerManagement #TechGuide