Assuming you don't wish to query the data, it would seem logical that the next best priority would be being able to restore the table as efficiently as possible. There are usually supported ways of exporting/importing tables from a database to a file on the disk.
My advice would be to stream the supported format of exported table data directly into a blob. You can then take that data and call upon that same database to "import" as if it were a normal import file from the disk.
The biggest advantage of this approach is that there is literally 0 hassle with typing. The database knows how best to save its own type information. No need to reinvent the wheel.
You should be made aware that this approach may cause problems if you update your database (not likely, but there's still that possibility). So before updating your database, please check that old imports are still accepted in the new version.
Usually these import files are flat files (columns are padded with spaces to guarantee that each column value is found in the same position for each line), and therefore they might occupy a lot more space then the table itself. You might consider zipping the contents first before inserting them, but I'll leave you to decide whether the efficiency/space tradeoff is worth it in your case.