Forum Debian Users Gang

redelek · 2017-02-16 08:38:05

Witam,

Od momentu podjęcia decyzji o zwiększeniu skrzynek użytkowników do 10GB, a dyrektorom do 20GB, żaden backup mi się nie wyrabia podczas nocy.
Do tej pory robiłem to tar-em i było gites, teraz mam już na wszystkich skrzynkach ponad 1T danych i zajmuje to mu ok 1,5dnia. Najcześciej ludzie zaczynają pracować i tar się wywala.
Rsync robi pełną kopię w 3 dni, przynajmniej się nie wysypuje.

Jak można poradzić sobie z taką ilością danych w jedną noc? Możecie pomóc podać jakiś przykład link. Macierz która udostępnia te zasoby jest stara i można tylko po NFS, ma możliwość iSCSI, ale producent od 2016 roku zaniechał wsparcia iSCSI , a w tym roku ma go wyłączyć. Więc jesteśmy w czarnej du..... Macierz wydawała się rozwojowa i fajna, ale z upływem czasu chyba nie.

Może ktoś mi pomóc. Backup robiłem codziennie przyrostowy, a w piątki od 23:30 pełny, ale wszystko przestało działać po zwiększeniu rozmiaru skrzynek.
Myślałem o duplicity, ale robił dobę i nie zrobił więc odpada, nie zostawiłem go na dłużej więc nie wiem czy się wywali podczas korzystania z poczty czy zablokuje ludzikom pliki.

Dzięki za pomoc i wskazówki.

Piotrek

Ostatnio edytowany przez redelek (2017-02-16 08:39:34)

milyges · 2017-02-16 09:29:39

Hej,

Jesteś w stanie pokazać jakieś benchmarki zapisu/odczytu z tej macierzy?

Mam u jednego klienta obecnie 1.2TB poczty na serwerze zimbra i backupuje to (jak i inne serwery) BURPem: http://burp.grke.org/
Backup robi się tylko zmienionych danych i co jakiś czas na serwerze jest scalany z pełnym (aby nie robić co jakiś czas pełnych z serwera).
Czas wykonania kopii:
[quote=log burp]Start time: 2017-02-16 00:22:53
End time: 2017-02-16 01:56:25
Time taken: 01:33:32
New Changed Duplicate Deleted Total | Scanned
------------------------------------------------------------
Files: 6155 418 1345572 1237 1352145 | 1352145
Directories: 224 0 6109 12 6333 | 6333
Hard links: 2066 0 415084 87 417150 | 417150
Soft links: 0 0 2037 0 2037 | 2037
Special files: 0 0 36 0 36 | 36
Grand total: 8445 418 1768838 1336 1777701 | 1777701
------------------------------------------------------------

Messages: 0
Warnings: 0

Bytes estimated: 1341063522524 (1.22 TB)
Bytes in backup: 1341065419453 (1.22 TB)
Bytes received: 3476262072 (3.24 GB)
Bytes sent: 25934109 (24.73 MB)[/quote]
Sam długo szukałem narzędzia do backupu takich ilości danych z automatycznym rotowaniem kopii i łatwością odzyskiwania i skończyło się właśnie na burp. Używam od około roku, kilka razy odzyskiwałem dane z kopii i nie było z tym problemów.

Pozdrawiam.
milyges

redelek · 2017-02-16 11:05:48

sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync
1024+0 przeczytanych recordów
1024+0 zapisanych recordów
skopiowane 1073741824 bajty (1,1 GB), 9,66423 s, 111 MB/s

# dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 przeczytanych recordów
1024+0 zapisanych recordów
skopiowane 1073741824 bajty (1,1 GB), 7,72162 s, 139 MB/s

Tego narzędzia nie znam zaraz poczytam, dzięki

Ostatnio edytowany przez redelek (2017-02-16 11:06:32)

bobycob · 2017-02-17 08:52:17

Jesteś w stanie określić co jest wąskim gardłem?
Wydaje mi się poza magicznym 1TB ilość plików też jest spora.
Pytanie czy uruchomienie dwóch i więcej backapów równolegle rozwiąże problem.

Jacekalex · 2017-02-18 00:59:54

@redelek

Zamiast skryptologii tarem i innymi zabawkami zatrudnij Dovecota, ma wbudowany mechanizm replikacji na drugi serwer.

RTFM:
http://wiki.dovecot.org/Replication

PS.
Do ręcznej czy skryptologicznej synchronizacji skrzynek nieźle się sprawdza imapsync...

Ostatnio edytowany przez Jacekalex (2017-02-18 01:34:12)

bobycob · 2017-02-20 08:24:35

tyko replikacja != backup

Jacekalex · 2017-02-20 22:23:14

[quote=bobycob]tyko replikacja != backup[/quote]
Zgadza się, na problemy sprzętowe (padające dyski) idealna, na pacjenta, który kasuje ważne maile z głupoty (i to podwójnie, z odebranych i z kosza) już niekonieczne.

W sytuacji nr 2 Postix oferuje funkcje sender_bcc i recipient_bcc (które można wykorzystać do backupu), a Qmail ma do tego łapkę TAP.

urbinek · 2017-02-24 08:47:03

W jaki sposób robisz przyrostówki?, może inne podejście będzie wydajniejsze

rsync - http://www.admin-magazine.com/Articles/Using-rsync-for-Backups
incremental tar - https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html
albo jakiś soft w stylu bacula, zbakup itp

bobycob · 2017-03-13 15:57:20

backuppc :)

Time (s)	Query
0.00011	SET CHARSET latin2
0.00004	SET NAMES latin2
0.00097	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.142.53.151' WHERE u.id=1
0.00073	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.142.53.151', 1732454329)
0.00045	SELECT * FROM punbb_online WHERE logged<1732454029
0.00076	DELETE FROM punbb_online WHERE ident='54.36.149.6'
0.00077	SELECT topic_id FROM punbb_posts WHERE id=309368
0.00185	SELECT id FROM punbb_posts WHERE topic_id=29362 ORDER BY posted
0.00060	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29362 AND t.moved_to IS NULL
0.00005	SELECT search_for, replace_with FROM punbb_censoring
0.00082	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29362 ORDER BY p.id LIMIT 0,25
0.00073	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29362
Total query time: 0.00788 s

Forum Debian Users Gang

Ogłoszenie

#1 2017-02-16 08:38:05

redelek - Członek DUG

Backup email ponad 1T danych

#2 2017-02-16 09:29:39

milyges - inż.

Re: Backup email ponad 1T danych

#3 2017-02-16 11:05:48

redelek - Członek DUG

Re: Backup email ponad 1T danych

#4 2017-02-17 08:52:17

bobycob - Członek z Ramienia

Re: Backup email ponad 1T danych

#5 2017-02-18 00:59:54

Jacekalex - Podobno człowiek...;)

Re: Backup email ponad 1T danych

#6 2017-02-20 08:24:35

bobycob - Członek z Ramienia

Re: Backup email ponad 1T danych

#7 2017-02-20 22:23:14

Jacekalex - Podobno człowiek...;)

Re: Backup email ponad 1T danych

#8 2017-02-24 08:47:03

urbinek - Użytkownik

Re: Backup email ponad 1T danych

#9 2017-03-13 15:57:20

bobycob - Członek z Ramienia

Re: Backup email ponad 1T danych

Stopka forum

Informacje debugowania