Hi Tobias, > On 29. Mar 2019, at 18:23, Tobias Lehr <tobias.l...@me.com> wrote: > > Hallo Andreas, > > sorry das ich mich erst jetzt zu dem Thema melde. Die Woche war dann doch > etwas stressiger und ich komme heute erst zum testen. > > Mit einem einfachen composer update war es leider nicht getan. Da ich ja noch > das alte image genutzt habe, musste ich erst mal php7.3 installieren, bis ich > mir das zusammen gegoogelt hatte, war schon mal abenteuerlich.
Die Vorgehensweise mit apt pinning gehört ins Wiki (falls sie da nicht schon ist). > Allerdings funktionierte dann composer nicht mehr, der Fehler der kam, > scheint mir php7.3 neu dazugekommen zu sein. Also erst mal composer updaten > mit composer self-update, ging auch nicht, wegen einem SHA384 hash, oder so, > also composer manuell laut getcomposer.org <http://getcomposer.org/> > installiert. Mhm. Self-update sollte eigentlich gehen, sonst it’s ein Composer Bug. > Dann lief es und ich konnte während des Fortschritts sehen das dbcopy auf > 1.3.0 upgedatet wurde. > > Aber mein Befehl klappt nicht mehr, da er backup nicht kennt. Ich bin dann > mal davon ausgegangen das es jetzt copy heißt, weil das dbcopy als option > angezeigt hat. Aber wenn ich das ausführe, dann bekomme ich folgende Meldung: > <Bildschirmfoto 2019-03-29 um 18.20.09.png> Analog VZ möchte auch dbcopy eine yaml config. Das Template liegt im etc Ordner. Bitte mach nochmal composer update, die 1.3 war furchtbar buggy. > ich habe keine Ahnung was da falsch sein soll, denn in Line 1 steht nur die > {. Die dbcopy.json ist im Anhang. Dann sollte es aber hoffentlich gehen… Viele Grüße, Andreas > > Gruß Tobias > <dbcopy.json> > >> Am 29.03.2019 um 07:04 schrieb Andreas Goetz <cpui...@gmail.com >> <mailto:cpui...@gmail.com>>: >> >> Hallo Tobias, >> >> Konntest Du das mal probieren? Würde mich freuen zu hören ob es jetzt passt. >> >> Viele Grüße, Andreas >> >> Am 26.03.2019 um 17:55 schrieb Andreas Goetz <cpui...@gmail.com >> <mailto:cpui...@gmail.com>>: >> >>> Ich hab gerade 1.3.1 gepublished, damit sollte es gehen (also composer >>> update verwenden). >>> >>> Viele Grüße, >>> Andreas >>> >>> >>>> On 26. Mar 2019, at 10:15, tobias.l...@me.com <mailto:tobias.l...@me.com> >>>> wrote: >>>> >>>> Hallo, >>>> >>>> Also erst mal vielen Dank an alle Hilfestellungen. >>>> >>>> Ja es geht in diesem konkreten Fall um das kopieren von einem. System auf >>>> ein anderes, allerdings wollte ich das so machen, wie ich im ernstfall >>>> einen restore von einem system auf das selbe system. >>>> >>>> Der Weg über mysql zu mysql geht ja jetzt, und für den weg von sqlite zu >>>> mysql warte ich einfach mal ob die profis was finden und fixen können. >>>> >>>> Gruß Tobias >>>> >>>> >>>> >>>> -------- Ursprüngliche Nachricht -------- >>>> Betreff: Re: [vz-users] Problem beim restore mit dbcopy >>>> Von: Daniel Lauckner >>>> An: "volkszaehler.org <http://volkszaehler.org/> - users" >>>> Cc: >>>> >>>> Hallo, >>>> >>>> >>>> am Dienstag, 26. März 2019 um 09:11 hat Jakob Hirsch geschrieben: >>>> > Oh, du benutzt dbcopy für backup? Ist nicht gerade effizient, für jedes >>>> > Backup eine neue sqlite-Datenbank zu erzeugen... >>>> >>>> Kann gut sein das ich noch bissl aufm Schlauch stehe (es ist erst kurz >>>> nach 9 ;D ), aber der Vorteil von dbcopy ist ja eben das man >>>> inkrementell kopieren kann. Es ist gar nicht nötig jedes mal eine neue >>>> Datenbank anzulegen. Auch nicht bei SQLite. >>>> >>>> > Ich mach das mit mysqldump, z.B. "mysqldump --databases vz > vz.$(date >>>> > +%Y%m%d_%H%M%S).sql" gibt einen dump mit allen Daten (regelmäßig die >>>> > alten dumps löschen nicht vergessen). Kann man dann einfach mit "mysql < >>>> > vz....sql" zurücksichern. >>>> >>>> Sqldump nimmt leider keinerlei Rücksicht auf die Auslastung der >>>> Datenbank und blockiert diese Zeitweise. Auf schwacher Hardware führt >>>> das zu Verlust der zwischenzeitlich geloggten Daten. >>>> >>>> Wobei man fairerweise zugeben muss das sqldump zuverlässiger beim >>>> Restore ist. >>>> >>>> >>>> mfg Daniel >>>> >>> >
