[amluto]

> mysqldump does not read historical rows from versioned tables, and so historical data will not be backed up. Also, a restore of the timestamps would not be possible as they cannot be defined by an insert/a user.

Given this caveat, this seems unusable for production systems.

[crazygringo]

Well, conceptually this makes sense for what mysqldump is.

I'm guessing that "backups" would actually have to be live replicas set up from the start, and if the master fails, you convert a replica to master.

In addition, you could perform actual static backups by pausing a replica, backing up the actual table files themselves, then resuming the replica (and it will catch up). In case of total failure, you just dump the table files into a fresh install of MariaDB. (Copying database files is a common technique for migrating data, not just SQL command import/export.)

Is there any reason why these wouldn't work?

[PixyMisa]

Or ZFS snapshots, for example.

From the description it looks like it would be easy to do backups, it's just that mysqldump is not currently aware of temporal tables.

Just use

SELECT * FROM t FOR SYSTEM_TIME ALL;

And export it in an appropriate format.

[crazygringo]

That does, of course, export complete data, but the problem is you can't then import it, because that breaks the entire guarantee about not being able to edit past data.

[PixyMisa]

Ah. There is that.

They really need to create a workaround for that, because sooner or later you will need to migrate your data and right now it's simply impossible.

Edit: Particularly as, reading further, you cannot ALTER a temporal table. Which does make sense, but the problem remains.

[mathnode]

If you are using Mariabackup or a volume snapshot, then you retain the history.