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 6984 razy przez 1692 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 5594 razy przez 1676 internautów «

Od pewnego czasu (w sumie nie wiem jak to się stało), przy uruchamianiu Midnight Commandera dostaję następujący komunikat:

freeBSD# mc
read (subshell_pty…): No such file or directory (2)

Co jest grane?
Otóż dziwnym trafem ustawienia aplikacji mówią nam, że jest problem z tzw. subshell (podpowłoka).
Error i brak możliwości usuchomienia programu występuje nawet po reinstalacji mc.
Najszybszym rozwiązaniem jest uruchamianie Midnight Commandera bez subshella w następujący sposób:

mc -u

Innym rozwiązaniem jest ponowne skompilowanie mc bez shubshella.
Polecam również manuala:

man mc

» wpis obejrzano 4516 razy przez 872 internautów «