Basierend auf dem discourse_docker-Repository habe ich ein kleines Skript geschrieben, um es in einer Vagrant-Maschine zu automatisieren (führen Sie es mit set -x aus, um zu sehen, was genau passiert)
Habe ich das Backup an den falschen Ort kopiert?
Und was bedeutet die Logzeile Making sure /var/www/discourse/tmp/restores/default/2020-05-13-190832 exists...?
~/infra/discourse on master! ⌚ 21:14:07
$ pwd
/home/pihentagy/infra/discourse
~/infra/discourse on master! ⌚ 21:01:14
$ ./wl.sh start
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ init
+ printf 'Checking out and updating repo…\n'
Checking out and updating repo…
+ cd ..
+ git clone https://github.com/discourse/discourse_docker.git discourse
fatal: destination path 'discourse' already exists and is not an empty directory.
+ printf 'Repo already there\n'
Repo already there
+ cd discourse
+ printf 'Updating repo…\n'
Updating repo…
+ git pull -r
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 5 (delta 2), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/discourse/discourse_docker
3e465a2..49ed141 master -> origin/master
Created autostash: 36aae80
HEAD is now at 3e465a2 Remove all pg12 traces so pg_wrapper doesn't get confused
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 49ed14152971f7f4a7437657987952be44c33c0a.
Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run "git stash pop" or "git stash drop" at any time.
+ printf 'Copying config file…\n'
Copying config file…
+ cp ../resources/discourse.yml containers/
+ echo 'Starting Vagrant machine...'
Starting Vagrant machine...
+ vagrant up
Bringing machine 'dockerhost' up with 'virtualbox' provider...
==> dockerhost: Checking if box 'ubuntu/xenial64' is up to date...
==> dockerhost: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> dockerhost: flag to force provisioning. Provisioners marked to run always will still run.
+ vagrant ssh -c 'cd /vagrant;sudo ./launcher start discourse'
2627afdfbaac
Nothing to do, your container has already started!
Connection to 127.0.0.1 closed.
+ exit 0
~/infra/discourse on master! ⌚ 21:07:56
$ ./wl.sh restore /home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ shift
+ backup=/home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz
+ discourse_backup_dir=shared/standalone/backups/default
+ mkdir --parents shared/standalone/backups/default
+ rsync -P --verbose /home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz shared/standalone/backups/default
icontest-2020-05-12-033823-v20200506044956.tar.gz
390,774,609 100% 317.41MB/s 0:00:01 (xfr#1, to-chk=0/1)
sent 390,870,133 bytes received 35 bytes 156,348,067.20 bytes/sec
total size is 390,774,609 speedup is 1.00
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore'
Restore are now permitted. Disable them with `disable_restore`
Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
You must provide a filename to restore. Did you mean one of the following?
Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore icontest-2020-05-12-033823-v20200506044956.tar.gz'
Starting restore: icontest-2020-05-12-033823-v20200506044956.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2020-05-13-190832 exists...
Copying archive to tmp directory...
EXCEPTION: lib/discourse.rb:90:in `exec': Failed to copy archive to tmp directory.
cp: cannot stat '/var/www/discourse/public/backups/default/icontest-2020-05-12-033823-v20200506044956.tar.gz': No such file or directory
lib/discourse.rb:100:in `execute_command'
lib/discourse.rb:90:in `exec'
lib/discourse.rb:40:in `execute_command'
/var/www/discourse/lib/backup_restore/local_backup_store.rb:42:in `download_file'
/var/www/discourse/lib/backup_restore/backup_file_handler.rb:61:in `copy_archive_to_tmp_directory'
/var/www/discourse/lib/backup_restore/backup_file_handler.rb:21:in `decompress'
/var/www/discourse/lib/backup_restore/restorer.rb:42:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Trying to rollback...
There was no need to rollback
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2020-05-13-190832' directory...
Unpausing sidekiq...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.
Connection to 127.0.0.1 closed.
Vagrant wird nicht unterstützt, aber hier ist trotzdem ein paar Ratschläge.
Ich bin mir nicht sicher, wie rsync funktioniert. Muss der Pfad mit einem Schrägstrich enden? Wenn die Datei im richtigen Verzeichnis landet, stelle sicher, dass die kopierte Datei vom Server lesbar ist.
Kann Vagrant (VirtualBox) also Probleme verursachen?
~/infra/discourse on master! ⌚ 23:22:23
$ tree discourse/shared
discourse/shared
└── standalone
└── backups
└── default
└── icontest-2020-05-12-033823-v20200506044956.tar.gz
3 directories, 1 file
~/infra/discourse on master! ⌚ 23:22:27
$ ls discourse/shared/standalone/backups/default
icontest-2020-05-12-033823-v20200506044956.tar.gz
~/infra/discourse on master! ⌚ 23:22:36
$ ls -l discourse/shared/standalone/backups/default
total 381620
-rw-r--r-- 1 pihentagy pihentagy 390774609 May 13 21:08 icontest-2020-05-12-033823-v20200506044956.tar.gz
Die Datei scheint für alle lesbar zu sein und befindet sich am richtigen Ort. Von innerhalb des discourse-Docker-Containers aus, wo sollte ich das Backup sehen? Ist mein unbeaufsichtigtes Wiederherstellungsskript korrekt, oder sollte ich die Datei in den Docker-Container kopieren? Wenn ja, wohin? (Gibt es vielleicht Anleitungen zur Automatisierung von Discourse von außerhalb [von Docker]?)
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
You must provide a filename to restore. Did you mean one of the following?
Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore icontest-2020-05-12-033823-v20200506044956.tar.gz'
Starting restore: icontest-2020-05-12-033823-v20200506044956.tar.gz
[
Es ist nicht zwingend erforderlich, aber es ist keine gute Praxis, den Pfad nicht mit einem Schrägstrich enden zu lassen, da das Ergebnis davon abhängt, ob das Verzeichnis bereits existiert oder nicht.
Wenn das Zielverzeichnis bereits existiert, ist kein Schrägstrich nötig und die Datei wird in das Verzeichnis kopiert.
Wenn das Zielverzeichnis nicht existiert und kein Schrägstrich am Ende steht, wird die Datei als Datei mit dem Namen ‘default’ kopiert.
Wenn das Zielverzeichnis nicht existiert und ein Schrägstrich am Ende steht, wird das Verzeichnis erstellt und die Datei darin kopiert.
In diesem Fall scheint die Kopierung (durch Zufall) erfolgreich zu sein.
Seltsamerweise ist es vom Host-Dateisystem aus nicht sichtbar. Sollte es das?
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse backup
Backup wird gestartet...
[GESTARTET]
'system' hat das Backup gestartet!
Backup wird als laufend markiert...
Es wird sichergestellt, dass '/var/www/discourse/tmp/backups/default/2020-05-14-121930' existiert...
Es wird sichergestellt, dass '/var/www/discourse/public/backups/default' existiert...
Metadaten werden aktualisiert...
Sidekiq wird pausiert...
Es wird gewartet, bis Sidekiq die laufenden Jobs abgeschlossen hat...
Das öffentliche Schema der Datenbank wird gedumpt...
…
Viele pg_dump-Ausgaben"
…
Sidekiq wird fortgesetzt...
Backup wird finalisiert...
Archiv wird erstellt: discourse-2020-05-14-121930-v20200512064023.tar.gz
Es wird sichergestellt, dass das Archiv noch nicht existiert...
Leeres Archiv wird erstellt...
Daten-Dump wird archiviert...
Uploads werden archiviert...
Temp-Verzeichnis '/var/www/discourse/tmp/backups/default/2020-05-14-121930' wird entfernt...
Archiv wird gzip-komprimiert, dies kann eine Weile dauern...
Der after_create_hook für das Backup wird ausgeführt...
Alte Backups werden gelöscht...
Aufräumen...
'.tar'-Reste werden entfernt...
Backup wird als abgeschlossen markiert...
Festplattenstatistiken werden aktualisiert...
Fertig!
[ERFOLG]
Backup abgeschlossen.
Ausgabedatei befindet sich in: /var/www/discourse/public/backups/default/discourse-2020-05-14-121930-v20200512064023.tar.gz
vagrant@ubuntu-xenial:~$ find / -name discourse-2020-05-14-121930-v20200512064023.tar.gz 2>/dev/null
vagrant@ubuntu-xenial:~$ sudo docer exec -w /var/www/discourse -i discourse discourse enable_restore
sudo: docer: Befehl nicht gefunden
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore
Wiederherstellungen sind nun erlaubt. Deaktiviere sie mit `disable_restore`
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse restore
Du musst einen Dateinamen für die Wiederherstellung angeben. Meintest du eine der folgenden?
discourse restore discourse-2020-05-14-121930-v20200512064023.tar.gz
discourse restore discourse-2020-05-14-121710-v20200512064023.tar.gz
discourse restore discourse-2020-05-14-120436-v20200512064023.tar.gz
Off: Gibt es eine Möglichkeit, Zeilen in Codeblöcken hervorzuheben?
Normalerweise ist /var/discourse/shared/standalone/backups das Verzeichnis, das in Ihrem Container als /var/www/discourse/public/backups sichtbar ist (daher das Wort shared). Ihr rsync-Befehl platziert das Backup in diesem Verzeichnis, um es innerhalb des Containers zugänglich zu machen.
Umgekehrt sollte ein Backup, das der Container in public/backups schreibt, im gemeinsamen Verzeichnis auf Ihrem Host sichtbar sein.
Ich habe oben /var/discourse/shared.... geschrieben. Aber es scheint, dass Sie in ~/infra/discourse arbeiten, also kopieren Sie nach ~/infra/discourse/shared/standalone/backups/default.
Normalerweise ist der Container auf /var/discourse/shared/... gemappt.
Das könnte das Problem sein. Können Sie prüfen, ob Sie ein /var/discourse/shared haben?
Stimmt, aber ich habe das vorerst ignoriert. Übrigens wurde dieses rsync außerhalb der (Vagrant-)Maschine ausgeführt, auf der ich mein Discourse laufen habe.
Aber wie von dir vorgeschlagen, habe ich vorerst Folgendes getan:
vagrant ssh auf die Maschine und von dort aus:
ein Backup erstellt mit sudo docker exec -w /var/www/discourse -i discourse discourse backup
den Dateipfad festgestellt:
Output file is in: /var/www/discourse/public/backups/default/discourse-2020-05-14-125606-v20200512064023.tar.gz
die gesamte Vagrant-Maschine nach dieser speziellen Datei durchsucht, aber nichts gefunden
wenn ich jedoch die Docker-Maschine betrete, ist sie dort:
root@ubuntu-xenial-discourse:/var/www/discourse/public/backups/default# ls
discourse-2020-05-14-120436-v20200512064023.tar.gz discourse-2020-05-14-121930-v20200512064023.tar.gz
discourse-2020-05-14-121710-v20200512064023.tar.gz discourse-2020-05-14-125606-v20200512064023.tar.gz
Meine Frage: Wenn ich ein Backup erstelle, sollte ich es dann auch außerhalb von Docker sehen können?
In der Zwischenzeit habe ich einfach eine Vagrant-Maschine erstellt und von dort aus im Standardverzeichnis /var/discourse ein Git-Clone durchgeführt. Die einzige „Unregelmäßigkeit
Ja, und das ist genau dasselbe wie dein ursprüngliches Problem:
„Wenn du ein Backup außerhalb von Docker hast und es in das gemeinsame Verzeichnis legst, solltest du es innerhalb von Docker sehen
Ich meinte: Ich habe vorerst eine brandneue Vagrant-Maschine erstellt, ohne irgendwelche vorherigen Backups zu kopieren. Ich habe das Bootstrapping durchgeführt und den Docker-Container gestartet. Dann habe ich das Backup erstellt.
Außerhalb der Docker-Maschine ist in der Vagrant-Maschine nichts zu sehen.
Ich glaube, ich habe das Problem gefunden: Ich habe diesen docker-freigegebenen Ordner in der übergeordneten Vagrant-Maschine eingebunden.
Wenn ich dies in meiner Vagrantfile auskommentiere, erscheinen die Backups „magisch" wieder.
Das Problem war also, dass der Vagrant-freigegebene Ordner (nach „oben") und der Docker-freigegebene Ordner (nach „unten") konkurrieren und dadurch ungültig werden.
