Oddaję do użytku skrypt mojego autorstwa napisany w php, wykonujący kopię synchronizacyjną plików znajdujących się w katalogu podanym jako pierwszy parametr wywołania.

#! /usr/local/bin/php -f
# by Adam Kucza (c) 2007
<?
$x = $_SERVER[”argv”];

if (count($x)==4)
{
//print_r($x);

$rsync = „/usr/local/bin/rsync”;

$srv = $x[1];
$src = $x[2];
$dst = $x[3];

$t = getdate();
//print_r($t);
if (strlen($t[’mon’])<10) $t['mon']="0".$t['mon'];
if (strlen($t['mday'])<10) $t['mday']="0".$t['mday'];
$l = "/var/log/rsync/".$x[1]."_".$t['year']."-".$t['mon']."-".$t['mday']."_".$t['hours'].".".$t['minutes'].".".$t['seconds'];

$o = "";
$o .= "-a ";
$o .= "-v ";
$o .= "-z ";
$o .= "–delete ";
$o .= "–ignore-errors ";
$o .= "–force ";
$o .= "–stats ";
$o .= "–log-file=".$l." ";
//$o .= "–dry-run ";
//$o .= "–modify-window=1 ";
//$o .= "–iconv=UTF-8,CP1251 ";
//$o .= "–blocking-io ";
//$o .= "–delete-after ";
//$o .= "–delete-before ";
//$o .= "–progress ";
//$o .= "–delete-excluded ";
//$o .= "–exclude-from=$EXCLUDES ";
//$o .= "–backup –backup-dir=/$BACKUPDIR -a ";

$z = $rsync." ".$o." ".$src." ".$srv."::".$dst;
echo $z."\n";

system($z);

}
else
{
echo "\nusage: ".$x[0]." server_address source_folder destination_module\n";
echo "\nexample: ".$x[0]." 192.168.1.100 /home/user/ backup_module\n";
}
echo "\n";
?>

Przykład jego wywołania wygląda np. tak:

./rsync.php /home/users/ backup_server

enjoy!

» wpis obejrzano 5918 razy przez 1704 internautów «

Czas na garść informacji o wykonywaniui kopii zapasowych na urządzenach taśmowych w systemie freeBSD.

Proponuję zaprzyjaźnić się z poniższymi poleceniami, które tak naprawdę dotyczą standardowych programów każdego freeBSD.
Przy czym chciałbym dodać, iż parametr -f /dev/sa0 określa urządzenie SCSI Tape Drive.

Kilka poleceń programu mt (magnetic tape manipulating program):

sprawdzenie stanu taśmy (ang. status)

mt -f /dev/sa0 status

kasowanie taśmy (ang. erase)

mt -f /dev/sa0 erase

przewinięcie taśmy (ang. rewind)

mt -f /dev/sa0 rewind

retensja (ang. retension), czyli naciągnięcie taśmy (przewijanie do końca i do początku naciągając taśmę)

mt -f /dev/sa0 retension

wysunięcie taśmy z urządzenia (ang. eject)

mt -f /dev/sa0 offline

Kopię zapasową można wykonać za pomocą znanego już zapewne programu tar (manipulate tape archives):

wykonanie kopii zapasowej (kasuje poprzedni zapis na tasmie):

tar -cv /usr/data/dir
tar -cv /usr/data/dir /usr/data/test

po parametrze -cv, wypisujemy katalogi bądź pliki, które chcemy zarchiwizować

wylistowanie zawartości taśmy

tar -tv

odzyskanie danych z taśmy:

tar -xv
tar -xv usr/data/test/filename.ext

po parametrze -xv, wypisujemy katalogi bądź pliki, które chcemy odzyskać

Dodatkowe informacje

Gdy nię będziemy zalogowani w systemie jako root, wykonując jakiekolwiek operacje na urządzeniu taśmowym dostaniemy komunikat:

mt: /dev/nsa0: Permission denied

Jeśli urządzenie taśmowe będzie puste (bez taśmy wewnątrz), to dostaniemy komunikat:

mt: /dev/nsa0: Device not configured

W przypadku, gdy urządzenie taśmowe będzie wykonywało jakąkolwiek operację na taśmie, a my będziemy chcieli zrobić z nią cokolwiek, dostaniemy następujący komunikat:

mt: /dev/nsa0: Device busy

Natomiast jeśli urządzenie będzie wolne od zadań, po wykonaniu polecenia mt status dostaniemy coś takiego:

Mode Density Blocksize bpi Compression
Current: 0×25:DDS-3 variable 97000 DCLZ
———available modes———
0: 0×25:DDS-3 variable 97000 DCLZ
1: 0×25:DDS-3 variable 97000 DCLZ
2: 0×25:DDS-3 variable 97000 DCLZ
3: 0×25:DDS-3 variable 97000 DCLZ
———————————
Current Driver State: at rest.
———————————
File Number: 0 Record Number: 0 Residual Count 0

Jeśli użyjemy polecenia tar -tv a taśma nie będzie sformatowana, uzyskamy komunikat:

tar: Unrecognized archive format: Inappropriate file type or format

Jeśli skorzystamy z polecenia tar -tv, a taśma będzie czysta zobaczymy coś takiego:

tar: Error opening archive: Error reading „/dev/sa0″: Input/output error

Myślę, że powyższy FAQ przybliży nieco archiwizowanie danych na tasiemkach.

» wpis obejrzano 6059 razy przez 1518 internautów «

Postanowiłem przybliżyć nieco problem związany z rsync.
Podczas synchronizacji widać oraz w logach widzimy błędy identyczne do następujących

[3193] rsync: readlink „jakis_plik” (in intranet) failed: Bad file descriptor (9)
[3193] rsync: recv_generator: failed to stat „jakis_plik” (in intranet): Bad file descriptor (9)
[3197] rsync: stat „jakis_plik” (in intranet) failed: Bad file descriptor (9)
[3197] rsync error: some files could not be transferred (code 23) at main.c(977) [sender=2.6.9]

Czasami nie zawsze pojawiają się tego typu błędy, aczkolwiek administrator widząc readlink … Bad file descriptor (9) zastanawia się czy przypadkiem nie ma uszkodzonego dysku i czy nie jest to błąd odczytu pliku…

W pewnym sensie jest to prawda, bowiem przy konfigurowaniu rsynca należy pamiętać aby system plików (filesystem type) na obu serwerach, a dokładniej na partycjach (źródłowej i docelowej) był dokładnie taki sam.

Mój problem polegał na tym, że zamontowana partycja na serwerze źródłowym posiadała likuksowy system plików ext2fs (subtype=131), a partycja, a raczej rsyncowy moduł docelowy - system plików freebsd (subtype=165).

Stąd te błędy. Korekte systemu plików mozna zrobić „w locie” bez konieczności restartowania serwera, a co ważniejsze - utraty danych (przynajmniej u mnie wszystko pozostało bez zmian).
Dla pewności proponowałbym zrobić uprzednio kopię zapasową danych znajdujących się na partycji, której chcemy zmienić system plików –> przezorny zawsze ubezpieczony.

Zmianę systemu plików dokonujemy następująco:

sysinstall –> configure –> fdisk

Po zamianie ext2fs –> freebsd, wszystko śmiga jak należy i zapominamy o błędach typu bad file descriptor.

» wpis obejrzano 4931 razy przez 1536 internautów «