Profihost 5-Tage-Backup-Funktion für Server

Durch ein Fehlgeschlagenes Update wurde es nötig ein Backup von vor zwei Tagen einzuspielen. Kein Problem dachte ich mir ruf bei Profihost an und lass Dir das Backup einspielen zahlst ja auch jeden Monat 19 Euro dafür und gut. Pustekuchen nachdem ich heute den ganzen Tag mit denen telefoniert habe und mir angeblich Backups vom 08.06, 09.06 und vom 10.06 eingespielt wurde in dem aber teilweise Dateien vom 11.06 sind braucht man nicht viel dazu sagen.

Wer hier denkt mit der Option ist er Sicher ich hab ja für die letzten 5 Tage eine Sicherung der hat sich geschnitten ich kann nur davor warnen! Kommt mir jetzt nicht mit Du hättest vorher… das…

Grüße René

aber das ist doch ok. inkrementell heißt ja > nur die veränderten dateien.

bedeutet das jetzt in einer Sicherung vom 8.6 können auch geänderte Dateien vom 11.6 sein?
Ich hätte das so verstanden das der Stand vom 8.6 in der Datei vom 8.6 nicht mehr geändert wird bis Sie dann nach 5 Tagen gelöscht wird.

Inkrementell bedeutet, dass von einem Basis-Stand die jeweils veränderten Dateien nachgesichert werden. In einem Backup vom Mittwoch sind dann also meinetwegen 85% Dateien vom Montag, 10% vom Dienstag und 5% vom Mittwoch.
Was welche Backupstrateguen genau beinhaltet kann man auf Wikipedia sehr gut nachlesen, der Artikel dort erklärt es einfach und nachvollziehbar.

*** von unterwegs via Tapatalk ***

Moin Rene,
das kann ich nicht bestätigen. Das was domino schreibt, bezieht sich ja zudem nur auf die Art und Weise eines inkrementellen Backups!

Sofern ich bei profihost anrufe und das Backup vom 08.06 verlange, dann sind defintiv auch nur die Daten vom 08.06 eingespielt und KEINE aktuellen Daten! Eskaliere dies nochmals bei profihost - bis jetzt haben wir bereits mehrmals verschiedene Systeme zurück gesichert und rein gar keine Probleme gehabt!

Beste Grüße
Tobias

leider scheint das bei mir nicht der Fall zu sein die haben mir heute Mindestens 10x eine Sicherung eingespielt erst eine vom 10 dann eine vom 9 dann eine vom 8 und immer waren dort Daten von gestern (11) drin die es dort nicht geben dürfte.

Ich habe seit heute Vormittag mit denen Kontakt mir scheint die hatten nur eine…

Ich muss mal kurz intervenieren. Ohne genau zu wissen, was dort los ist, eine “Warnung” für ein Produkt rauszugeben, find ich echt heftig. Nochmal: dieses Forum ist kein Pranger, falls einem irgendwas nicht passt, und solche pauschalen Aussagen können ggf. strafrechtlich relevant sein. Wir bewegen uns hier in einem öffentlichen Raum!

Gruß

@Rene
Wenn du mir eine PN schickst, dann kann ich dir gerne meinen Ansprechpartner mit Kontaktdaten zusenden. Der sollte dir definitiv helfen können!

@marko dann lösch das Brett Bitte.
Ich kann die Überschrift nicht ändern.

Rene, wenn Du nichts dagegen hast, würde ich die Überschrift ändern und den ersten Teil im Eröffnungspost rausnehmen, dann sieht das schon ganz anders aus. Löschen macht ja auch keinen Sinn.

Tipp für den nächsten Fall: Niemals mit Wut im Bauch posten. Erst mal zurücklehnen und tief durchatmen :wink:

Gruß

Bitte ja mach.

Hallo Rene,
hallo Oxid Forum,

als beteiligter Provider möchten wir den Sachverhalt hier einmal kurz
darlegen.
Vorweg möchten wir uns bei Herrn Steinhaeuser bedanken. Am 12.06.14 war der beschriebene Fall noch nicht abschließend geklärt, sodass die Editierung auch unter diesem Gesichtspunkt sinnvoll war. Vielen Dank für die schnelle Reaktion Marco.

Zum Sachverhalt, der an einigen Stellen sehr technisch wird. Ich versuche das hier einfach darzustellen.
Bei dem vorliegenden Server kommt ein externes 5 Tage Backup zum Einsatz, welches eine Mischung aus inkrementellem und differenziellem Backup ist. Das Backup arbeitet dabei mit sogenannten Hardlinks. Das bedeutet, dass die Datei physikalisch einmal gespeichert ist. Ändert sich die Datei auf BIT Ebene nicht, so wird im Folgebackup ein Hardlink auf diese Datei gesetzt. Liegt die Datei verändert vor, so liegt diese physikalisch 2 Mal vor.

Beispiel:
Backup 4: info.php (Datei vor 5 Tagen, physikalisch gespeichert)
Backup 3: info.php (Datei vor 4 Tagen, unverändert, Hardlink auf Datei in Backup 4)
Backup 2: info.php (Datei vor 3 Tagen, unverändert, Hardlink auf Datei in Backup 4)
Backup 1: info.php (Datei vor 2 Tagen, unverändert, Hardlink auf Datei in Backup 4)
Backup 0: info.php (Datei vor 1 Tag, unverändert, Hardlink auf Datei in Backup 4)

Beispiel 2:

Backup 4: info.php (Datei vor 5 Tagen, physikalisch gespeichert)
Backup 3: info.php (Datei vor 4 Tagen, unverändert, Hardlink auf Datei in Backup 4)
Backup 2: info.php (Datei vor 3 Tagen, verändert, physikalisch gespeichert) Backup 1: info.php (Datei vor 2 Tagen, unverändert, Hardlink auf Datei in Backup 2)
Backup 0: info.php (Datei vor 1 Tag, unverändert, Hardlink auf Datei in Backup 2)

In dem genannten Fall ging es auch speziell darum, wie eine Datei mit dem Zeitstempel vom 11.06.14 in dem Backup vom 09.06.2014 vorhanden sein kann.
Es erscheint auf den ersten Blick merkwürdig, macht aber durch die genannte Kombination Sinn.
Der Zeitstempel wird bei einer Sicherung nicht als Indikator für eine Veränderung gesehen. Das Backup vergleicht die Daten auf BIT Ebene, sodass hier ein Fehler immer ausgeschlossen werden kann. Die Übertragung von einem neuen Zeitstempel in alte Sicherungen ist durch das Backupscript bedingt.
Der Parameter für die Zeitstempelübertragung ist vorhanden, jedoch nicht als Indikator zu sehen.

Beispiel: Eine Datei wird am 11.06.14 heruntergeladen, kopiert, verändert und hochgeladen. Es wird festgestellt, dass die Änderung nicht funktioniert und die ursprüngliche Datei wird hochgeladen. Die Datei hat somit auf BIT Ebene den gleichen Inhalt wie zuvor. ABER: Der Zeitstempel ist auf dem 11.06.14, bedingt durch den Kopiervorgang.

Das Backupscript prüft nun die Daten BIT Weise auf Veränderungen. Die vorhandene und die zu sichernde Datei wird ohne die Angabe eines Zeitstempel(Datum ist dann bei beiden Dateien 1970) verglichen. Es wird festgestellt, dass die Datei auf BIT Ebene unverändert ist. Also wird die vorhandene Datei wieder zurück geschrieben. Dabei muss der Zeitstempel mit übertragen werden. Es wird dabei IMMER der Zeitstempel der zu sichernden Datei genommen (also 11.06.14). Durch die Hardlinks ist dieser Zeitstempel nun in allen Sicherungen vorhanden, obwohl am 09.06.14
der 11.06.14 noch erst bevorstand

Dennoch nehmen wir das Anliegen von Rene ernst. Ein Techniker hat die “betroffenen” Dateien mit einer MD5 HASH-Summer überprüft. Alle Daten (Backup und LIVE System) weisen nachweislich den gleichen HASH Wert auf. Somit war die Datei auf BIT Ebene seit dem 08.06.14 unverändert.

Leider konnten wir die Problematik mit Rene nicht abschließend besprechen. Am 13.06.14 teilte uns Rene mit, dass sein Onlineshop wieder funktioniert. Eine Änderung von unserer Seite aus wurde nicht getätigt. Weitere Fehlerbeschreibungen liegen uns nicht vor, sodass wir den Fall, unabhängig von der technischen Diskussion, intern abgeschlossen haben.

Ich hoffe, dass wir euch den technischen Hintergrund ein wenig erläutern konnten. Manchmal ist die Technik hinter solchen Prozessen nicht so einfach wie es von außen aussieht. Natürlich sind wir für eine Erklärung immer offen. Das Backup kommt bei über 1.000 Servern zum Einsatz und arbeitet durchgängig fehlerfrei. Ein Großteil der Servernutzer haben das dazugehörige technische Verständnis für diese Prozesse nicht, sodass sie uns ihr Vertrauen schenken. Dafür sind wir sehr dankbar.

Für Fragen könnt ihr euch gerne hier im Forum melden.

Viele Grüße

Guten Tag,

Sorry aber auf Bitebene waren die Dateien vom 9.6 und vom 11.06 unterschiedlich weil wir am 11.06 ein Shop update durchgeführt haben was leider in die Hose ging. Deshalb sollte dann die Sicherung vom 09.06 eingespielt werden bekommen haben wir dann mehrmals Dateien mit Bitebene Stand 11.06.
Speziell bemerkt habe ich das an der pkg.info Datei
Der Shop war am 09.06 noch in der Version 4.7.7 am 11.06 Version 4.8.6
Nach der Rücksicherung stand dort immer noch 4.8.6 und der Shop funktionierte nicht.
Die Rücksicherung der Datenbank verlief Problemlos und Ihre Leute waren auch sehr bemüht uns zu helfen.

Mittlerweile ist alles wieder Ok mein dank geht hier auch an Volker Dörk “dem Retter in der Not”.
Bisher war ich eigentlich sehr zufrieden mit Profihost und werde auch dort bleiben denn der Service und die Erreichbarkeit sind vorbildlich und Fehler können passieren…
alles Gut

Grüße René

[QUOTE=Rene;146819]
Der Shop war am 09.06 noch in der Version 4.7.7 am 11.06 Version 4.8.6
Nach der Rücksicherung stand dort immer noch 4.8.6 und der Shop funktionierte nicht.
[/QUOTE]

Es an der (major-)Version des Shops festzumachen ist wohl sehr unglücklich, das diese in der Datenbank steht und nicht in den Dateien.
Das der Shop nicht funktioniert wenn man 4.7.er Dateien an eine 4.8.er Datenbank hängt und umgekehrt ist klar, dazu hat sich zuviel geändert. Wenn man ein Backup einspiel dann sollte man muss man auch den Shop an ein Datenbankbackup hängen (und die ganzen Hürden wie Views etc. beachten).

Immerhin läuft nun wieder alles.

@Firefax

das hatte ich aus der pkg.info und nicht aus dem Admin.
Dort steht die Version auch drin. In der DB stand 4.7.7 in der pkg.info Version 4.8.6 die erst am 11.6. Installiert wurde.

Hallo Rene,

es freut uns, dass Ihr Onlineshop wieder einwandfrei erreichbar ist und Sie mit unserem Service und unserer Erreichbarkeit sehr zufrieden sind.

Bei Fragen können Sie sich gerne an uns wenden.

Viele Grüße aus Hannover.