|
yan00s
Moderator
405 Posts |
 Posted - 04 Feb 2013 : 15:41:01
|
quote:
Originally posted by nehickel
Would it be possible for the Database Backup function to include:
1) Backing up all of the Configuration files for the XMM Installation that is currently being used and...
The idea of storing (some) config data along side the database is quite a nice one. I've requested something which (partly) goes into the same direction: http://www.binaryworks.it/forum/topic.asp?TOPIC_ID=10542 ... backup / restore might profit from it. If this gets streamlined it may even help in making XMM more UAC friendly. But...
quote:
Originally posted by nehickel
2) Telling the user what version of XMM that the backup effort came from and is designed to be restored to (it may be possible to restore the files to a great many XMM versions but it will for certain work on the version thay are currently using to create the backup).
... I believe the only reason a program has to care for backups is when it unashamedly alters users' precious data by itself. For all other cases there's dedicated software out there which does a much better job with backup / restore than a Media Manager ever could and should do. All what goes beyond "copy the current db and if wished for related media (covers etc.)" is overkill.
Side note: depending on what else XMM will one day do for us too we may want transaction logs. We're still far away from that day though... 
quote:
Originally posted by nehickel
3) The user should also be given a link at the end of the backup effort that connects the user to the version of XMM they were using so that the XMM installation package can be downloaded to the backup folder.
Item number 3) above will require Ali to keep an online library of the last 20 to 40 installation packages depending on how robust the Backup enhancement is designed to be.
XMM should be aware if a database is compatible with the currently installed program version. I think this is already implemented.
Also, configuration data (eventually) stored with the database should be handled consistently or, alternatively, XMM informs the user which old values will not be restored when a backup gets used. That's it.
While I can see some value in offering a fallback to the previous minor and latest major version (the latter already exists) I don't do so for a big library of XMM versions. 20 full installs would account for over 1 GB on the web server. And what for?
In general one's better of using dedicated backup software. Well, I already said so.  |
. |
 |
|
Enhancing DB Backup to include XMM Cntrl Files
