1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Hostingplattform: Gitlab nach Backup…

Möchte nicht in der Haut des Admins sein...

  1. Thema

Neues Thema Ansicht wechseln


  1. Möchte nicht in der Haut des Admins sein...

    Autor: Steffo 01.02.17 - 18:39

    Wirklich nicht! Fehler passieren, aber man wird's ihm wohl kaum verzeihen und er sich vll. auch nicht...

  2. Re: Möchte nicht in der Haut des Admins sein...

    Autor: blubby666 01.02.17 - 18:41

    naja 6h sind ja jetzt nicht sooo dramatisch. Der code ist dezentral gespeichert. Das einzige sind halt wiki-seiten, issues und kommentare die flöten gegangen sind. Ärgerlich aber mMn. nicht projektgefährdend.

    Weiß jemand um welchen Zeitraum es sich handelt? In der nacht ist es ja noch undramatischer als tagsüber wenn alle arbeiten.

  3. Re: Möchte nicht in der Haut des Admins sein...

    Autor: Rabbit 01.02.17 - 19:36

    Naja, die haben Anwender weltweit, insofern ist die Zeitzone fast schon wieder egal.

    Die aktuellen Verlustzahlen und die Ursachen haben sie vorbildlichst in einem live einsehbaren Google Doc abgelegt (https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub) und es gibt auf YouTube sogar einen Live-Stream von den Admins, die am Recovery arbeiten.

  4. Re: Möchte nicht in der Haut des Admins sein...

    Autor: avon 01.02.17 - 19:48

    Bei git hat ja eh jeder Entwickler das ganze Repo bei sich, von daher wird sich der Verlust bei den meisten auf ein bisschen Rumfummeln für die neue Synchronisierung beschränken. Und was das Wiki angeht, so kann man das auch schon seit einiger Zeit als eigenes git-Repo herunterladen.

  5. Re: Möchte nicht in der Haut des Admins sein...

    Autor: Rabbit 01.02.17 - 19:54

    Naja, in vielen Projekte und Organisationen sind die Issues und die Diskussionen und Reviews als Teil der Merge Requests schon auch wichtig. Und da sind jetzt 6h verloren gegangen.

  6. Re: Möchte nicht in der Haut des Admins sein...

    Autor: theonlyone 01.02.17 - 20:07

    Passiert immer mal , das wichtigste ist eben das man seine PROD Datenbank ganz offensichtlich als solche kennzeichnet, das nicht irgendein Entwickler glaubt er sei auf der DEV Datenbank und dann mal was wegschmeißt (z.B. eine Rot Einfärbung aller Datenbank Ansichten in einem Tool ist schon mal ganz gut, DEV ist dann halt hell blau, kann jeder direkt erkennen).

    Ansonsten auch ganz nützlich wenn ein Tool nachfragt ob man wirklich den Ordner mit XYZ vielen Dateien "löschen" will , gerade wenn man glaubt es handelt sich dabei um einen "leeren" Ordner ist das auch ein extra Schritt der Sicherheit.

    Der einfache "Drop" auf eine Datenbank geht halt immer, das ist ziemlich gefährlich, auch wenn man backups hat, im Zweifel hat man ziemlich lange Downtime, die man sich eventuell nicht leisten kann (und das wird dann teuer).

    ----

    Ergebnis ist, so viele barrieren auf einer PROD Datenbank einbauen das Fehler immer unwahrscheinlicher werden.

    Wer als Entwickler bewusst böses will wird das natürlich praktisch immer durchführen können.

  7. Re: Möchte nicht in der Haut des Admins sein...

    Autor: Rabbit 01.02.17 - 20:10

    theonlyone schrieb:
    --------------------------------------------------------------------------------
    > Passiert immer mal , das wichtigste ist eben das man seine PROD Datenbank
    > ganz offensichtlich als solche kennzeichnet, das nicht irgendein Entwickler
    > glaubt er sei auf der DEV Datenbank und dann mal was wegschmeißt (z.B. eine
    > Rot Einfärbung aller Datenbank Ansichten in einem Tool ist schon mal ganz
    > gut, DEV ist dann halt hell blau, kann jeder direkt erkennen).

    Handhaben wir in der Firma genau so. Rot eingefärbtes $PS1 für Produktivsysteme, grün für DEV.

    > Ansonsten auch ganz nützlich wenn ein Tool nachfragt ob man wirklich den
    > Ordner mit XYZ vielen Dateien "löschen" will , gerade wenn man glaubt es
    > handelt sich dabei um einen "leeren" Ordner ist das auch ein extra Schritt
    > der Sicherheit.

    Aus genau dem Grund hab ich mir persönlich mittlerweile wieder konsequent die verwendung von "rmdir" anstelle von "rm -r" angewohnt (wenn ich glaube, dass ein Ordner leer sein müsste). Hat auch schon ein paarmal gut geholfen.

  8. Re: Möchte nicht in der Haut des Admins sein...

    Autor: torrbox 01.02.17 - 23:44

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Wirklich nicht! Fehler passieren, aber man wird's ihm wohl kaum verzeihen
    > und er sich vll. auch nicht...


    Ach ich finde man gewöhnt sich ans Fehlermachen. Und zwar nicht nur beim Programmieren. Passiert einfach und das beste was man machen kann ist daraus zu lernen.

  9. Re: Möchte nicht in der Haut des Admins sein...

    Autor: Schattenwerk 02.02.17 - 00:13

    blubby666 schrieb:
    --------------------------------------------------------------------------------
    > naja 6h sind ja jetzt nicht sooo dramatisch. Der code ist dezentral
    > gespeichert.

    Naja, ich branche lokal, arbeite, pushe, merge request und lösche lokal wie online den branch.

    Die Daten sollten dann für immer verloren sein, sofern ich dann lokal nicht nach dem merge pullt habe ;) Kann also auch ärgerlicher sein.

  10. Re: Möchte nicht in der Haut des Admins sein...

    Autor: Gromran 02.02.17 - 00:29

    man hat nicht zwingend alle Branches lokal da liegen...

  11. Re: Möchte nicht in der Haut des Admins sein...

    Autor: theonlyone 02.02.17 - 10:22

    Schattenwerk schrieb:
    --------------------------------------------------------------------------------
    > blubby666 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > naja 6h sind ja jetzt nicht sooo dramatisch. Der code ist dezentral
    > > gespeichert.
    >
    > Naja, ich branche lokal, arbeite, pushe, merge request und lösche lokal wie
    > online den branch.
    >
    > Die Daten sollten dann für immer verloren sein, sofern ich dann lokal nicht
    > nach dem merge pullt habe ;) Kann also auch ärgerlicher sein.

    Selbst dann hat z.B. dein Eclipse immer noch einen lokalen Speicher, den du wohl Minimum gut eine Woche zurück bekommst.

    Also wenn wirklich etwas relevantes dabei ist, dann kannst du das mit dem entsprechenden Know-How auch wieder herstellen.

    Es sei den deine IDE der Wahl tut das alles nicht, dann ist das aber auch deine Schuld ;P

    ----

    Den am Ende, wenn man seine Projekte unterteilt in:

    - lokale Branches für Entwickler (im Zweifel ist irgendwer im Urlaub und hat noch einen lokalen Branch, auf den man im Fall des Falles zugreifen kann)
    - Merges als Versions-Tag vorhalten (z.B. ein "Daily" / "Nightly" Build).
    - Lokale Speicher in der IDE
    - Festplatte Speicherabbild (kann im Zweifel auch die Lösung sein, eher bei deutlich länger zurückliegenden Dingen)

    Und selbst dann hat man ja noch auf seinen verschiedenen Systemen die aktuellen Versionen laufen (PROD wird bei vielen ein doch deutlich älterer Stand sein, wenn hier nur in größeren Abständen neue Versionen eingespielt werden).

    ----

    Geht also etwas wirklich komplett verloren, nur weil GitLab abraucht, hat man in seiner Arbeits-Umgebung wohl etwas falsch gemacht (bzw. kannte seine Möglichkeiten nicht).

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Computacenter AG & Co. oHG, verschiedene Standorte
  2. Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  3. i22 Digitalagentur GmbH, deutschlandweit (Home-Office)
  4. Hochschule Ravensburg-Weingarten Technik I Wirtschaft I Sozialwesen, Weingarten

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 174,45€ (Bestpreis!)
  2. (u. a. Die Brücke: Das Finale für 14,97€, Killjoys: Space Bounty Hunters - finale Staffel für...
  3. (aktuell u. a. E-Sport-Shop mit Angeboten zu Acer Nitro 5, Omen 15, Razer Blade Stealth 13 und...
  4. (u. a. Alphacool NexXxos ST30 240mm Radiator für 38,49€, Alphacool NexXxos XT45 360mm XFlow...


Haben wir etwas übersehen?

E-Mail an news@golem.de