danielmarschall
commented
11 months ago Fixed:
- SVN Rev 1351: Delete the contents from the tables before starting the import! (Very important, I have forgotten it)
- SVN Rev 1352: Put backup and restore into methods and give boolean flags of what to import/export and what not
- SVN Rev 1353: Add "config" and "log" to the things to be imported/exported, but make it by default OFF
- SVN Rev 1354: Config-Backup should not include the public/private key. Instead, there should be another backup/restore option to export the public/private key pair.
- SVN Rev 1355: Create a JSON schema for the backup format + Reject import if the schema is different
- SVN Rev 1357: During backup restore, check if the user wants to import "X" but the file was not exported with "X" (i.e. "num_dataset" is "n/a"), in that case throw an Exception and do not start the import
- SVN Rev 1359: Option to encrypt the whole export file
- SVN Rev 1359: Now we just need the plugin, the GUI and so on.
- SVN Rev 1359: The GUI should explain that the backup is experimental and not tested with all SQL DBMS providers. Administrators should check the JSON for correctness, etc.
- SVN Rev 1359: During backup and restore we should give the user the possibility to backup/restore objects, or RA, or both?
Rejected ideas:
- Export: Let the user choose if they want to export the decrypted private key, or the encrypted private key (in this case, userdata/privkey_secret.php must stay)... on the other hand... we might overstrain the user with too many options...
- Export private/public key as PFX (but then we need a proper X.509 cert...)
- When restoring the database, automatically make a backup before, so that you can restore it in case you restored something by accident. => Problem: We cannot import and download a new file at the same time (this would be very confusing), and we do not want to save the backup file in userdata/ for security reasons.
Ideas for the future (added to TODO file):
- Using an
INTF_OID_interface let other plugins backup/restore their own data/tables, too.
The next big change will be a backup plugin.
The initial idea was to have a super-backup which includes userdata, userdata_pub and a whole SQL-dump (for all DBMS!) into a ZIP file, but this task is a bit too complex.
Instead, for now we make a backup solution which only includes objects (incl. asn1id and iri) and RAs. Config and Log will not be affected. In fact, the backup and restore procedure will be added to the log. Only saving objects and RA also allows that data is transferred between two systems (e.g. copy all Objects/RA from productive environment to staging environment or vice versa, without touching the config and logs of each system)