Member Avatar for savedlema

Hi all!

I have developed my application in VB.NET that uses a mysql database. From my application, I can make mysql backups and restore them. When i take a backup, the result is a .sql file which is saved somewhere. But as usual, one can open that sql file with a text editor (like notepad++) and see everything, database structure (tables) and data stored in tables. One can also make changes to the data in this sql file and restore it to the mysql server and thereby, be able to change the database contents of a live mysql server.

Due to the nature of some of the information contained in the tables of this database, I would't like to give the normal user an opportunity to even discover what's on my database.

How can I achieve this? Is there a way of producing a file of other extension/type rather than .sql that can't be opened by text editors, but at the same time reserve the ability to restore the database?

Thanks for any input.

  • 5 Contributors
  • 4 Replies
  • 340 Views
  • 2 Weeks Discussion Span
  • Latest Post Latest Post by jwenting

Dani AI

Generated

As described, a mysqldump .sql is plain text and therefore visible and editable if an account can read it. Replies from , , and point toward access controls and OS-level encryption as important first steps. Complementing those, the most effective approach is to ensure backups are created as encrypted artifacts and to harden the restore workflow so plaintext never sits in a world-readable location.

Examples that keep plaintext off disk and preserve direct restore capability:

mysqldump -u root -p --databases mydb | gpg --symmetric --cipher-algo AES256 -o mydb.sql.gpg
gpg -d mydb.sql.gpg | mysql -u root -p

On Windows, an encrypted 7‑Zip archive (AES‑256) or encrypting the dump stream inside the VB.NET app are valid alternatives. A minimal VB.NET pattern (write IV, then encrypt the dump stream) looks like:

Using aes As Aes = Aes.Create()
    aes.Key = Convert.FromBase64String(keyB64)
    aes.GenerateIV()
    Using fout As New FileStream("backup.enc", FileMode.Create)
        fout.Write(aes.IV, 0, aes.IV.Length)
        Using cs As New CryptoStream(fout, aes.CreateEncryptor(), CryptoStreamMode.Write)
            Using fin As New FileStream("backup.sql", FileMode.Open)
                fin.CopyTo(cs)
            End Using
        End Using
    End Using
End Using

Key management and workflow controls are the critical pieces. Keys must not be hard-coded; protect them with DPAPI, the OS key store, or a dedicated secrets manager. Use signatures or HMACs so restores detect tampering. Prefer streaming decrypt→restore to avoid creating plaintext files. Maintain restricted restore privileges, rotate keys, keep an encrypted offsite copy, and perform periodic restore verification. Obscuring file extensions or hiding folder names is insufficient on its own—combine strict access control, strong encryption, and audited restore processes to prevent disclosure or unauthorized modification.

Recommended Answers

All 4 Replies

Member Avatar for Mike Askew

Can you not just restrict access to the folder holding your backups via user permissions on the OS?

commented: Ok, thank you. +2
Member Avatar for drjohn

Perhaps you could avoid telling users the name of the back-up folder and the file name, as well as restricting access to that folder. And place an index.html file in the folder with nothing in it, or saying something like silly like a link to the home page, so users cant see a file listing for the folder.

commented: Thank you drjohn for that trick! +2
Member Avatar for jwenting

sql files ARE text files. The only way to prevent people from reading them is to make sure they don't have access to whereever they're stored.

commented: Thank jwenting, I will work on that +2
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.