DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   Web Hosting, web serveri i operativni sistemi (http://www.devprotalk.com/forumdisplay.php?f=11)
-   -   Sta napisati na sajtu kada se pravi backup? (http://www.devprotalk.com/showthread.php?t=3442)

Peca 29. 08. 2007. 05:52

Sta napisati na sajtu kada se pravi backup?
 
Nocu se pravi backup na mom serveru, i baza je nedostupna nekih 4 min.
Sta napisati na sajtu tada, odnosno, kakav html output napraviti a da googlebot i ostali kasvetni search botovi tu stranicu ne indexiraju kao takvu?
Kako staviti botu do znanja da 'saceka', i da ne indexira to obavestenje o pravljenju backup-a koje vide korisnici? :)
Postoji li neki http code koji oznacava da je sadrzaj 'privremen' ?

jablan 29. 08. 2007. 09:06

http://www.checkupdown.com/status/E503.html

Napravi custom 503 stranicu gde ćeš ukratko objasniti o čemu se radi i zamoliti korisnika da navrati malo kasnije (čuvena "odmah se vraćam" poruka).

kaizen 29. 08. 2007. 09:18

Citat:

Originalno napisao jablan (Napišite 41262)
http://www.checkupdown.com/status/E503.html

Napravi custom 503 stranicu gde ćeš ukratko objasniti o čemu se radi i zamoliti korisnika da navrati malo kasnije (čuvena "odmah se vraćam" poruka).

"Dear Googlebot, ... "

Nemanja Avramović 29. 08. 2007. 10:56

Pogledaj ovo: http://www.askapache.com/htaccess/50...available.html

Pedja 29. 08. 2007. 12:26

Heh,ovo moze abue zanimljivo i kao reenej za preterani protok koji rpave botovi. Kad vidis da je bot upitanju, samo mu javis da je site zauzet i napravis delay :)

Petar Marić 29. 08. 2007. 13:42

Citat:

Originalno napisao Pedja (Napišite 41280)
Heh,ovo moze abue zanimljivo i kao reenej za preterani protok koji rpave botovi. Kad vidis da je bot upitanju, samo mu javis da je site zauzet i napravis delay :)

Popi jedno pivo da poništiš dejstvo te kafe ;)

Peca 29. 08. 2007. 15:59

znaci 503, pa ispod custom html.
tnx za odgovor.

pcigre 01. 12. 2007. 21:08

Do sada smo backup radili "na živo" međutim znatno bi nam bezbednije po backup bilo da odbijemo posete za vreme backupa... E sad, nezgodna varijanta je što se backup radi automatski u 5 ujutru...

Ideja koja mi je pala na pamet je sledeća:
- 1 min pre početka backupa cron izvrši skriptu koja promeni .htaccess i stavi onaj koji kaže da je sajt nedostupan i da pokušaju kasnije...
- startuje se backup i šljaka
- kad se završi backup pošalje mail...

E sad dolazim do problema... kako upaliti nazad automatski server? Možda neka extra pametna skripta koja po primanju e-maila aktivira cron da vrati original .htaccess?

Jel izvodljivo ovako nešto ili sam počeo da maštam?

nixa 01. 12. 2007. 22:11

Ajde da ja malo pricam na glas, da li je neko radio sa ZFS backup resenjem.

Generalno jeste to za opensolaris , ali gledao sam recimo da ima portage za gentoo ?

caiser 01. 12. 2007. 22:58

Ja se jos uvek ne bih igrao sa ZFS-om na Linuxu. Koliko god on super radio na Solarisu, Linux port je jos uvek previse svez. :) Uostalom, Linux LVM pruza vrlo lepu mogucnost za backup a to je snapshot. Sve sto je potrebno je da omogucis konzistentnost podataka dok se ne napravi snapshot, sto traje jako kratko (nekoliko sekundi) i backup moze da pocne. Samim tim se i downtime smanjuje sa nekoliko (desetina) minuta na svega par sekundi. Nije bas fancy kao ZFS, ali jako korisno. ;)

ivanhoe 02. 12. 2007. 00:43

Bas sam pravio pre neki dan:
PHP kôd:

<?php
/*--- SETTINGS ---*/
$retry_after 30// In minutes
$message "Site is currently undergoing scheduled maintenance. Please try again in about $retry_after minutes. Sorry for the inconvenience.";
/* ---------------- */

// send 503
header("HTTP/1.0 503 Service Unavailable"); 
header("Retry-After: ". ($retry_after 60) ); 
   
?>
<!doctype html PUBLIC "-//W3C//DTD HTML 4.01//EN" 
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Service Unavailable</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
    <h3 style="color:red">Service Unavailable</h3>
    <p><?= $message ?></p> 
</body>
</html>


nn.nn 02. 12. 2007. 00:48

Citat:

Originalno napisao pcigre (Napišite 47565)
Ideja koja mi je pala na pamet je sledeća:
- 1 min pre početka backupa cron izvrši skriptu koja promeni .htaccess i stavi onaj koji kaže da je sajt nedostupan i da pokušaju kasnije...
- startuje se backup i šljaka
- kad se završi backup pošalje mail...

E sad dolazim do problema... kako upaliti nazad automatski server? Možda neka extra pametna skripta koja po primanju e-maila aktivira cron da vrati original .htaccess?

U principu, backup skript, kad ga jednom pokrene cron, može sve to da odradi. Naravno, zavisi od skripta. :)

Kod mene je to malo drugačije, recimo da .htaccess sadrži nešto ovakvo:

Kôd:

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /maintenance.html [L]

Skript, pri pokretanju, postavi maintenance.html, tako da Apache za svaki novi zahtev šalje njega. Kad se završi backup, samo se obriše fajl i sajt je ponovo vidljiv.

pcigre 02. 12. 2007. 16:44

Citat:

U principu, backup skript, kad ga jednom pokrene cron, može sve to da odradi. Naravno, zavisi od skripta.
Skripta je iz panela koj koristimo, nije "ručno" pisana...

Citat:

Skript, pri pokretanju, postavi maintenance.html, tako da Apache za svaki novi zahtev šalje njega. Kad se završi backup, samo se obriše fajl i sajt je ponovo vidljiv.
Elegantno.

Za sada ćemo koristiti varijantu da cron izvrši skriptu koja menja .htaccess pre početka backupa, počne packup, uradi se backup baze za max 3-4 min, na petom minutu se izvrši cron koji vraća nazad original .htaccess . nije savršeno ali dok ne nađemo način detekcije završetka backupa i izvršavanje akcije tada... mora ovako.

Ostaje još da se sredi skript koj bi po pozivanju menjao .htaccess...

Peca 02. 12. 2007. 17:55

Citat:

Originalno napisao pcigre (Napišite 47565)
Do sada smo backup radili "na živo" međutim znatno bi nam bezbednije po backup bilo da odbijemo posete za vreme backupa... E sad, nezgodna varijanta je što se backup radi automatski u 5 ujutru...

Ideja koja mi je pala na pamet je sledeća:
- 1 min pre početka backupa cron izvrši skriptu koja promeni .htaccess i stavi onaj koji kaže da je sajt nedostupan i da pokušaju kasnije...
- startuje se backup i šljaka
- kad se završi backup pošalje mail...

E sad dolazim do problema... kako upaliti nazad automatski server? Možda neka extra pametna skripta koja po primanju e-maila aktivira cron da vrati original .htaccess?

Jel izvodljivo ovako nešto ili sam počeo da maštam?

moj cron menja samo config.php [podaci za login na bazu]
pre backup-a stavim config.php koji ispise da je backup u toku i 'umre' [die()] :)
onda uradi backup
i onda samo vrati originalni config.php

ne gasim apache uopste.

p.s. za svaki slucaj postavi u cron zasebnu liniju za vracanje originalnog configa, koja ce da se izvrsi recimo 10 min posle backup-a.
evo zasto.
nikad ne znas hoce li backup skripta iz ko zna kog razloga da pukne.
ako pukne - nece stici do linije koja vraca originalni config, i korisnici ce celo jutro da gledaju 'backup u toku'...
zato ce ovaj drugi cron job za svaki slucaj da vrati original, bez obzira da li je vec vracen.

ivanhoe 02. 12. 2007. 17:55

mod_rewite podrzava upotrebu environment variabli, tako da ne morate da menjate ceo .htaccess, dovoljno je da skript exportuje neku $BACKUP_IN_PROGRESS varijablu (bar teoretski, nisam to nikad probao da uradim, ali ne vidim sto ne bi moglo..)

pcigre 02. 12. 2007. 17:58

Citat:

ne gasim apache uopste.
Ni ja ne bi gasio apache, ali bi im dao 503 preko .htaccessa, svima.

pcigre 09. 12. 2007. 23:58

Problem rešen uz Pecinu pomoć kombinaovanu sa odgovorima iz ove i ove teme.

Ipak sam morao da izvedem da se sajt gasi samo tokom backupa baze.

Za slučaj da još nekom zatreba:

backup.sh
Kôd:

#!/bin/bash
rm -f /putanja/Settings.php
cp /putanja/backup.php /putanja/Settings.php
mysqldump -h localhost -u user --password=pass baza |gzip > /putanja/baza_`date +"%Y-%m-%d-%H:%M"`.sql.gz
rm -f /putanja/Settings.php
cp /putanja/Settings-default.php /putanja/Settings.php
echo "Dnevni backup baza sajta" | mail -s "Dnevni backup baza sajta" admin@mail.com

Valjalo bi možda dodati drugačiju poruku kada je operacija iz nekog razloga neuspešna, no ne snađoh se oko toga.

Fajl Settings.php je conf fajl skripte koja se prikada (koji skripta uvek poziva i sadrži parametre za konekciju na bazu). Njega menjam fajlom koj sadrži otprilike ovako nešto:

Kôd:

<?php
 //ob_start();
 header('HTTP/1.1 503 Service Temporarily Unavailable');
 header('Status: 503 Service Temporarily Unavailable');
 header('Retry-After: 600');
 //header('X-Powered-By:');
 ?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>BackUp u toku / BackUp in progress</title>
</head>
<body>
vaše ultra fensi obaveštenje backupa u toku
</body>
</html>

 <?
 exit;
 ?>

Tako tokom backupa niko ne koristi bazu a pretraživači uredno dobiju 503 header da svrate kasnije, a posetioci razumno obaveštenje.

Hvala svima koji su mi pomogli.


Vreme je GMT +2. Trenutno vreme je 07:14.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.