Kann Backup nicht erstellen oder zu Backups navigieren

merefield · 11. November 2024 um 07:51

Fehlgeschlagen

Das Backup ist fehlgeschlagen.

Hier ist das Protokoll:

undefined method `start_with?' for nil /var/www/discourse/app/models/site_setting.rb:172:in `use_dualstack_endpoint’
/var/www/discourse/lib/s3_helper.rb:269:in `s3_options' /var/www/discourse/lib/backup_restore/s3_backup_store.rb:14:in `initialize’
/var/www/discourse/lib/backup_restore/backup_store.rb:17:in `new'`

nach einem sehr kürzlichen Rebuild auf den neuesten Stand.

In meinem Fall wird S3 mit einem Standard-AWS-Bucket gehostet.

Könnte das damit zusammenhängen?

hosna · 11. November 2024 um 08:17

Ich verwende Minio Objektspeicher für mein S3 und erhalte diesen Fehler:

rake aborted!
Aws::S3::Errors::Http504Error: Aws::S3::Errors::Http504Error (Aws::S3::Errors::Http504Error)
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.143.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.143.0/lib/aws-sdk-s3/plugins/dualstack.rb:21:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.143.0/lib/aws-sdk-s3/plugins/accelerate.rb:43:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:16:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/seahorse/client/plugins/request_callback.rb:89:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.143.0/lib/aws-sdk-s3/client.rb:11285:in `list_objects_v2'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.143.0/lib/aws-sdk-s3/bucket.rb:1304:in `block (2 levels) in objects'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/plugins/user_agent.rb:28:in `feature'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.143.0/lib/aws-sdk-s3/bucket.rb:1303:in `block in objects'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:101:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:101:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:101:in `block in non_empty_batches'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:52:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:52:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:52:in `block in each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:58:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:58:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.191.3/lib/aws-sdk-core/resources/collection.rb:58:in `each'
/var/www/discourse/lib/tasks/s3.rake:14:in `map'
/var/www/discourse/lib/tasks/s3.rake:14:in `existing_assets'
/var/www/discourse/lib/tasks/s3.rake:210:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:expire_missing_assets
(See full trace by running task with --trace)
I, [2024-11-11T08:02:51.942337 #1]  INFO -- : Checking for stale S3 assets...

I, [2024-11-11T08:02:51.944197 #1]  INFO -- : Terminating async processes
I, [2024-11-11T08:02:51.944334 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 39
I, [2024-11-11T08:02:51.944432 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 107
2024-11-11 08:02:51.944 UTC [39] LOG:  received fast shutdown request
107:signal-handler (1731312171) Received SIGTERM scheduling shutdown...
2024-11-11 08:02:51.945 UTC [39] LOG:  aborting any active transactions
2024-11-11 08:02:51.949 UTC [39] LOG:  background worker "logical replication launcher" (PID 54) exited with exit code 1
2024-11-11 08:02:51.950 UTC [49] LOG:  shutting down
107:M 11 Nov 2024 08:02:51.960 # User requested shutdown...
107:M 11 Nov 2024 08:02:51.960 * Saving the final RDB snapshot before exiting.
2024-11-11 08:02:52.047 UTC [39] LOG:  database system is shut down
107:M 11 Nov 2024 08:02:52.207 * DB saved on disk
107:M 11 Nov 2024 08:02:52.208 # Redis is now ready to exit, bye bye...

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse &amp;&amp; sudo -E -u discourse bundle exec rake s3:expire_missing_assets failed with return #&lt;Process::Status: pid 3550 exit 1&gt;
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets", "sudo -E -u discourse bundle exec rake s3:expire_missing_assets"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
4f601885ffad64bcd29f6dbd06df1f0f86ad301341d40e752df7447809a32eff

@martin

merefield · 11. November 2024 um 23:16

Ein weiteres Problem ist, dass Sie nicht mehr zu Backups navigieren können:

Fehler bei der Berechnung des Berichts `storage_stats`: undefined method `start_with?' for nil
/var/www/discourse/app/models/site_setting.rb:172:in `use_dualstack_endpoint'
/var/www/discourse/lib/s3_helper.rb:269:in `s3_options'

merefield · 11. November 2024 um 23:24

Könnte das der Grund sein?

[7] pry(main)> SiteSetting.Upload.s3_region
=> nil
[8] pry(main)> SiteSetting.s3_region
=> "eu-west-2"
[9] pry(main)>

SiteSetting.Upload.s3_region ist auf meiner Instanz leer, daher wirft starts_with? einen Fehler.

github.com/discourse/discourse

app/models/site_setting.rb

4816e8e0e


      
          
          def self.enable_s3_transfer_acceleration
            if SiteSetting.enable_s3_uploads
              SiteSetting.enable_s3_transfer_acceleration
            else
              GlobalSetting.enable_s3_transfer_acceleration
            end
          end
          
          def self.use_dualstack_endpoint
            SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")
          end
          
          def self.enable_s3_uploads
            SiteSetting.enable_s3_uploads || GlobalSetting.use_s3?
          end
          
          def self.s3_base_url
            path = self.s3_upload_bucket.split("/", 2)[1]
            "#{self.absolute_base_url}#{path ? "/" + path : ""}"
          end

merefield · 11. November 2024 um 23:30

In diesem PR:

github.com/discourse/discourse

FIX: S3 custom endpoint incompatible with dualstack

main ← issue/fix-s3-endpoint-dualstack

opened 12:41AM - 08 Nov 24 UTC

martin-brennan

+22 -5

Followup 0568d36133081e52f25f05585c1a568c3b828d79 S3 itself and other S3-comp…atible providers do not allow using an S3 custom endpoint and dualstack at the same time, so this commit fixes that by not using dualstack when the endpoint is present. c.f. https://meta.discourse.org/t/rebuild-issue-cannot-set-dual-stack-in-combination-with-a-custom-endpoint/334902

Die Spec verwendet SiteSetting.s3_region, aber der Code verwendet SiteSetting.Upload.s3_region

martin · 12. November 2024 um 05:56

@hosna und @merefield, ist SiteSetting.enable_s3_uploads bei euch beiden auf true gesetzt? Wenn ja, sollten wir einfach SiteSetting.s3_region verwenden:

github.com/discourse/discourse

app/models/site_setting.rb

f9d92fa87


      
          def self.s3_region
            SiteSetting.enable_s3_uploads ? SiteSetting.s3_region : GlobalSetting.s3_region
          end

Was ist mit SiteSetting::Upload.enable_s3_uploads, was liefert das bei euch?

Ich könnte eine Korrektur wie diese vornehmen, die die sichere Navigation für s3_region verwendet:

def self.use_dualstack_endpoint
  SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region&.start_with?("cn-")
end

Aber ich möchte verstehen, warum SiteSetting.Upload.s3_region bei euch leer ist.

merefield · 12. November 2024 um 06:40

OK, das wird immer seltsamer, es gibt zwei Einstellungen?

Ich benutze S3 für Backups, aber nicht für Uploads (was eine gültige Wahl ist und seit Jahren so gehandhabt wird?)
Die Aktivierung beider ist durch die Benutzeroberfläche nicht erzwungen.
Ich habe seit Jahren keine Einstellungen geändert.

Somit ist SiteSetting::Upload.s3_region leer, da ich es nicht benutze?

Obwohl als Randbemerkung Uploads unabhängig von den Backups gebündelt werden sollten, aber SiteSetting.s3_region dafür ausreichend sein sollte?

Meine Backups schlagen immer noch fehl

hosna · 12. November 2024 um 11:42

wenn du diese Einstellung meinst, nein, sie ist für mich nicht aktiviert

Ich habe S3 in meiner app.yml-Datei wie folgt konfiguriert:

was hier erwähnt wurde

@martin

omarfilip · 13. November 2024 um 03:03

Ich möchte dasselbe Problem wie oben gemeldet melden. Kein Zugriff auf /admin/backups (Fehler 500), Backup fehlgeschlagen.

S3-Backups sind aktiviert, S3-Uploads nicht – dies ist seit Jahren so und funktioniert erfolgreich.

Fehlerprotokoll

### Nachricht (14 Kopien gemeldet)

Fehler beim Berechnen des Berichts `storage_stats`: undefined method `start_with?' for nil /var/www/discourse/app/models/site_setting.rb:172:in `use_dualstack_endpoint' /var/www/discourse/lib/backup_restore/s3_backup_store.rb:14:in `initialize' /var/www/discourse/lib/backup_restore/backup_store.rb:17:in `new' /var/www/discourse/lib/backup_restore/backup_store.rb:17:in `create' /var/www/discourse/app/models/concerns/reports/storage_stats.rb:10:in `report_storage_stats' /var/www/discourse/app/models/report.rb:269:in `public_send' /var/www/discourse/app/models/report.rb:269:in `block in find' /var/www/discourse/app/models/report.rb:165:in `block in wrap_slow_query' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.1.5/lib/active_record/connection_adapters/abstract/transaction.rb:535:in `block in within_new_transaction' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.1.5/lib/active_support/concurrency/null_lock.rb:9:in `synchronize' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.1.5/lib/active_record/connection_adapters/abstract/transaction.rb:532:in `within_new_transaction' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.1.5/lib/active_record/connection_adapters/abstract/database_statements.rb:344:in `transaction' /var/www/discourse/app/models/report.rb:160:in `wrap_slow_query' /var/www/discourse/app/models/report.rb:267:in `find' /var/www/discourse/app/controllers/admin/reports_controller.rb:97:in `block (2 levels) in bulk' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/actionpack-7.1.5/lib/action_controller/metal/strong_parameters.rb:400:in `block in each_pair' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/actionpack-7.1.5/lib/action_controller/metal/strong_parameters.rb:399:in `each_pair' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/actionpack-7.1.5/lib/action_controller/metal/strong_parameters.rb:399:in `each_pair' /var/www/discourse/app/contro...

### Backtrace

activesupport-7.1.5/lib/active_support/broadcast_logger.rb:134:in `block in error'

activesupport-7.1.5/lib/active_support/broadcast_logger.rb:231:in `block in dispatch'

activesupport-7.1.5/lib/active_support/broadcast_logger.rb:231:in `each'

activesupport-7.1.5/lib/active_support/broadcast_logger.rb:231:in `dispatch'

activesupport-7.1.5/lib/active_support/broadcast_logger.rb:134:in `error'

/var/www/discourse/app/models/report.rb:295:in `rescue in find'

/var/www/discourse/app/models/report.rb:262:in `find'

/var/www/discourse/app/controllers/admin/reports_controller.rb:97:in `block (2 levels) in bulk'

actionpack-7.1.5/lib/action_controller/metal/strong_parameters.rb:400:in `block in each_pair'

actionpack-7.1.5/lib/action_controller/metal/strong_parameters.rb:399:in `each_pair'

actionpack-7.1.5/lib/action_controller/metal/strong_parameters.rb:399:in `each_pair'

/var/www/discourse/app/controllers/admin/reports_controller.rb:76:in `block in bulk'

/var/www/discourse/lib/hijack.rb:64:in `instance_eval'

/var/www/discourse/lib/hijack.rb:64:in `block in hijack'

concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:911:in `callback_on_resolution'

concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:797:in `call_callback'

concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:803:in `call_callbacks'

concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:692:in `resolve_with'

concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:1325:in `resolve'

/var/www/discourse/lib/scheduler/defer.rb:115:in `block in do_work'

rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'

rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'

/var/www/discourse/lib/scheduler/defer.rb:109:in `do_work'

/var/www/discourse/lib/scheduler/defer.rb:97:in `block (2 levels) in start_thread'

### Env

1/14

|hostname|forum-app|
| --- | --- |
|process_id|849|
|application_version|234133bd3b0750b2675a1c2c6745616c899df990|
|HTTP_HOST|forum.glasair-owners.com|
|REQUEST_METHOD|GET|
|HTTP_USER_AGENT|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36|
|HTTP_ACCEPT|application/json, text/javascript, */*; q=0.01|
|HTTP_REFERER|https://forum.glasair-owners.com/admin|
|HTTP_X_FORWARDED_FOR|xxx|
|HTTP_X_REAL_IP|xxx|
|username|xxx|
|time|6:47 pm|
||params null|

Chet_McDoniel · 13. November 2024 um 03:30

Gleiches Problem hier…

pfaffman · 14. November 2024 um 17:07

Nein. Das ist das Problem, da bin ich mir ziemlich sicher. Sie verwenden S3 für Backups, aber nicht für Uploads, was eine ziemlich gängige Konfiguration für Self-Hosters ist. Es ist einfach, S3-Backups zu konfigurieren, und erfordert weder ein CDN noch eine Änderung der YML, um Assets für die Kompilierung hochzuladen.

Es ist leer, weil sie S3 nicht für Uploads verwenden.

      SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")

aus dem obigen GitHub-Link sollte lauten:

      GlobalSettings.use_s3 && SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")

oder vielleicht

      SiteSetting.enable_s3_uploads && SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")

Ich bin mir nicht ganz sicher, wie use_s3 und enable_s3_uploads miteinander verbunden sind.

pfaffman · 14. November 2024 um 17:18

Und ich denke, dass

github.com/discourse/discourse

app/models/site_setting.rb

4816e8e0e


      
              SiteSetting.enable_s3_transfer_acceleration
            else
              GlobalSetting.enable_s3_transfer_acceleration
            end
          end
          
          def self.use_dualstack_endpoint
            SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")
          end
          
          def self.enable_s3_uploads
            SiteSetting.enable_s3_uploads || GlobalSetting.use_s3?
          end
          
          def self.s3_base_url
            path = self.s3_upload_bucket.split("/", 2)[1]
            "#{self.absolute_base_url}#{path ? "/" + path : ""}"
          end
          
          def self.absolute_base_url
            url_basename = SiteSetting.s3_endpoint.split("/")[-1]

wirklich def self.enable_s3_uploads? sein sollte (da es meldet, ob s3_uploads aktiviert sind, anstatt s3-uploads zu aktivieren) und dann

  SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")

sollte sein

  use_s3_uploads? && SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")

Andererseits hat Sam es vor 7 Jahren so genannt, und es scheint, als ob es einfach in Ordnung war.

Also, wie die Funktion jetzt heißt

  use_s3_uploads && SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")

merefield · 14. November 2024 um 18:50

sollte es nicht heißen?:

use_s3_uploads? && !SiteSetting.Upload.s3_endpoint.blank? && !SiteSetting.Upload.s3_region.start_with?("cn-")

also das S3-Upload-Endpunkt ist nicht leer?

hosna · 14. November 2024 um 19:04

aber ich benutze S3 auch für Uploads. Ich habe es in meiner app.yml konfiguriert.

MarcP · 14. November 2024 um 19:29

Ich habe dasselbe Problem. Ich habe mich bei meinem Speicheranbieter angemeldet, um zu prüfen, ob ich die Rechnung bezahlt habe, und das habe ich.

Warum wurde eine solche disruptive Änderung ohne Ankündigung vorgenommen?

Sollen wir jetzt alle Details in app.yml eingeben?

Warum wurden alle Einstellungen aus dem Admin-Backend entfernt? Wie können wir diese Einstellungen wiederherstellen? Ich habe dies vor Jahren einmal eingerichtet und habe keine Ahnung, was mein Schlüssel oder mein Geheimnis ist, und ich bin mir nicht einmal sicher, ob ich dies abrufen kann, ohne den Schlüssel zurückzusetzen (was andere Dienste beeinträchtigen würde, für die ich dieselben S3-Endpunkte verwende).

merefield · 14. November 2024 um 20:12

Ich glaube, die Einstellungen sind immer noch in der Benutzeroberfläche vorhanden (Backup-Speicherort, Häufigkeit, S3-Bucket usw.), sie funktionieren nur nicht mehr wie zuvor.

Ich glaube nicht, dass dies eine beabsichtigte funktionale Änderung ist, sondern dass sie einfach kaputt ist?

Es sollte doch sicherlich noch möglich sein, ein Backup nach S3 zu erstellen, ohne Uploads in S3 speichern zu müssen – dies sind zwei getrennte, wenn auch teilweise zusammenhängende Anwendungsfälle …

Al_Ni · 14. November 2024 um 21:36

Gleiches Problem
Ich habe S3 für Backups verwendet, nicht zum Hochladen

pfaffman · 14. November 2024 um 23:02

Da sie nichts kaputt machen sollte, aber der S3-Code eine ganze Reihe von Sonderfällen unterstützen muss, und es ziemlich schwierig ist, hineinzuspringen und zu sehen, wie groß das Problem wirklich ist, es sei denn, Sie haben diesen Code geschrieben oder seine Entwicklung im Laufe der Jahre verfolgt.

martin · 15. November 2024 um 02:06

Entschuldigung allerseits, ich war ein paar Tage krank. Das sollte das Problem beheben:

github.com/discourse/discourse

FIX: Admin backups erroring because of S3 dualstack

main ← issue/fix-s3-backup-dualstack

opened 01:53AM - 15 Nov 24 UTC

martin-brennan

+30 -10

Followup 0568d36133081e52f25f05585c1a568c3b828d79 Followup 97cf069a061e350edfc5…310266e80e58532a39a4 Due to the S3 dualstack endpoint change, sites with S3 backups configured but _not_ S3 uploads were erroring, with admins unable to access the backups page. This commit fixes the error by not enabling S3 dualstack endpoints if S3 uploads have not been enabled, backups don't need to use them. c.f. https://meta.discourse.org/t/unable-to-backup-or-navigate-to-backups/335899

Ich habe dies lokal mit deaktivierten S3-Uploads und aktivierten S3-Backups vor und nach der Korrektur ausprobiert. Ich konnte denselben Fehler reproduzieren und ihn dann beheben.

omarfilip · 15. November 2024 um 03:42

Erfolgreich neu aufgebaut und gesichert.

Danke @martin .

Thema		Antworten	Aufrufe
Rebuild issue: [Cannot set dual-stack in combination with a custom endpoint.] Bug s3 , fixed	15	296	18. November 2024
Intended path to migrate S3 to local Installation uploads , s3	5	786	13. Mai 2023
Forum rendered unusable Installation s3	10	821	4. September 2023
Restore process cancelled at migrating uploads to S3 step Support	25	2537	24. April 2021
No access to site after set S3 credentials Support	11	833	4. April 2020

Kann Backup nicht erstellen oder zu Backups navigieren

Verwandte Themen