Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
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)
Offline
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
Offline
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)
Offline
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.
Offline
@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)
Offline
tyko replikacja != backup
Offline
[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.
Offline
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
Offline
backuppc :)
Offline
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00003 | SET NAMES latin2 |
0.00160 | 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.136.19.124' WHERE u.id=1 |
0.00103 | UPDATE punbb_online SET logged=1732504633 WHERE ident='3.136.19.124' |
0.00052 | SELECT * FROM punbb_online WHERE logged<1732504333 |
0.00065 | DELETE FROM punbb_online WHERE ident='3.138.125.86' |
0.00074 | SELECT topic_id FROM punbb_posts WHERE id=308716 |
0.00175 | SELECT id FROM punbb_posts WHERE topic_id=29362 ORDER BY posted |
0.00058 | 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.00079 | 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.00082 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29362 |
Total query time: 0.00866 s |