Using features list as the installation contract is a good idea but in this case, the deploy folder must be forbidden otherwise we will have a gap between the content of the list + what is installed using deploy folder
In resume : startup.properties + features list + folder deploy = list of bundles to be backuped On Thu, Apr 2, 2009 at 4:27 PM, Guillaume Nodet <[email protected]> wrote: > On Thu, Apr 2, 2009 at 16:23, Jamie G. <[email protected]> wrote: > > 1) Backup/recover config files > > > > Interesting, would be a useful feature. > > > > 2) Log rotation (already discussed) > > > > 3) Image of bundles installed.. > > > > This sounds very useful to me, kind of like taking a system snapshot > > that an administrator could roll back to if need be (great when dozens > > of bundles are involved). Would this be another web admin interface > > delivered feature or something we would do via the kernel shell > > interface? I would assume the shell would be the best place for this > > type of administrative function. > > I see a web console as offering the same features than the shell, so > imho, everything available from the web should be available from the > lower level shell also. > > What about building the rollback into the features service ? So that > if the installation fails, it would leave the runtime in the same > state that it was before installing the bundles. If everything is > define by a feature, the state would only be the list of installed > feature which may be way easier to manage. > > > > > On Thu, Apr 2, 2009 at 11:05 AM, Charles Moulliard <[email protected]> > wrote: > >> Concerning the backup strategy, I see two points : > >> > >> 1) Backup/recover config files > >> > >> This can be achieved through web admin interface. A zip file will be > >> generated containing the config files and named according to the current > >> system date. In case of trouble (after parameter modification or > >> reinstallation), the user can reinstall files > >> > >> 2) Log rotation (already discussed) : can be defined in the existing cfg > >> file > >> > >> 3) Keep image of the bundles installed (useful to roll back install of > >> project = sum of bundles) > >> With this feature, the deployer can be roll back an installation in case > of > >> problem > >> > >> Charles > >> > >> > >> On Thu, Apr 2, 2009 at 3:16 PM, Jamie G. <[email protected]> > wrote: > >> > >>> I'd like to know more about the Backup strategy too. Are we looking > >>> for some best practices documentation or something more comprehensive > >>> (such as disaster recovery scenario)? > >>> > >>> We already have some fail over support via the kernel as Guillaume has > >>> noted. > >>> > >>> Cheers, > >>> Jamie > >>> > >>> >> - Backup strategy, > >>> > > >>> > Please explain ? Is this related to > >>> > > >>> > http://servicemix.apache.org/kernel/67-configuring-failover-deployments-available-in-110.html > >>> > ? > >>> > >> > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
