I think in all cases, if you want to manage a cluster of kernels, using the deploy folder is not necesseraly the best idea. Or just use rsync to copy over the changes then ... But having a full back up requires much more than that, it would need the preference services, the config admin, and all other configuration files in the /etc folder. Btw, what's your use case for changing the startup.properties file ?
On Thu, Apr 2, 2009 at 16:45, Charles Moulliard <[email protected]> wrote: > 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 >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
