Garbage Collect & Verify über NFS sehr langsam

[Frank666]

Hallo,

ich mache momentan eine wöchentliche Garbage Collection und Verification.
Bei einem lokalen Storage dauert das max. 30min.
Beim Storage, das über NFS angebunden ist dauert das momentan über 3 Tage.
Kennt jemand solche Probleme mit NFS?
In dem NFS Storage werden Backups von ca 25 VM's erstellt. Von jeder VM gibt es momentan ca. 30 Backups.

Angebunden ist das NFS Storage über 1GBit/s Ethernet.
Wenn ich ein Backup einer VM mache ist die Geschwindigkeit ok.
iperf3 gibt auch über 900mbit/s aus.

INFO: sata0: dirty-bitmap status: created new
INFO:   1% (336.0 MiB of 32.0 GiB) in 3s, read: 112.0 MiB/s, write: 69.3 MiB/s
INFO:   2% (716.0 MiB of 32.0 GiB) in 8s, read: 76.0 MiB/s, write: 76.0 MiB/s
INFO:   3% (1008.0 MiB of 32.0 GiB) in 11s, read: 97.3 MiB/s, write: 97.3 MiB/s
INFO:   4% (1.3 GiB of 32.0 GiB) in 15s, read: 83.0 MiB/s, write: 83.0 MiB/s
INFO:   5% (1.6 GiB of 32.0 GiB) in 20s, read: 69.6 MiB/s, write: 69.6 MiB/s
INFO:   6% (1.9 GiB of 32.0 GiB) in 23s, read: 98.7 MiB/s, write: 98.7 MiB/s
INFO:   7% (2.4 GiB of 32.0 GiB) in 27s, read: 108.0 MiB/s, write: 108.0 MiB/s
INFO:   8% (2.6 GiB of 32.0 GiB) in 30s, read: 92.0 MiB/s, write: 92.0 MiB/s
INFO:   9% (2.9 GiB of 32.0 GiB) in 33s, read: 88.0 MiB/s, write: 88.0 MiB/s
INFO:  10% (3.2 GiB of 32.0 GiB) in 37s, read: 92.0 MiB/s, write: 90.0 MiB/s
INFO:  11% (3.5 GiB of 32.0 GiB) in 40s, read: 100.0 MiB/s, write: 100.0 MiB/s
INFO:  12% (3.9 GiB of 32.0 GiB) in 43s, read: 112.0 MiB/s, write: 108.0 MiB/s
INFO:  13% (4.2 GiB of 32.0 GiB) in 46s, read: 102.7 MiB/s, write: 102.7 MiB/s
INFO:  14% (4.6 GiB of 32.0 GiB) in 50s, read: 102.0 MiB/s, write: 102.0 MiB/s
INFO:  15% (4.8 GiB of 32.0 GiB) in 53s, read: 93.3 MiB/s, write: 93.3 MiB/s
INFO:  16% (5.2 GiB of 32.0 GiB) in 57s, read: 96.0 MiB/s, write: 96.0 MiB/s
INFO:  17% (5.5 GiB of 32.0 GiB) in 1m, read: 93.3 MiB/s, write: 93.3 MiB/s
INFO:  18% (5.8 GiB of 32.0 GiB) in 1m 3s, read: 97.3 MiB/s, write: 97.3 MiB/s
INFO:  19% (6.2 GiB of 32.0 GiB) in 1m 7s, read: 109.0 MiB/s, write: 109.0 MiB/s
INFO:  20% (6.5 GiB of 32.0 GiB) in 1m 10s, read: 89.3 MiB/s, write: 89.3 MiB/s
INFO:  21% (6.7 GiB of 32.0 GiB) in 1m 15s, read: 56.0 MiB/s, write: 56.0 MiB/s
INFO:  22% (7.1 GiB of 32.0 GiB) in 1m 19s, read: 101.0 MiB/s, write: 101.0 MiB/s
INFO:  23% (7.5 GiB of 32.0 GiB) in 1m 22s, read: 110.7 MiB/s, write: 110.7 MiB/s
INFO:  24% (7.7 GiB of 32.0 GiB) in 1m 25s, read: 97.3 MiB/s, write: 97.3 MiB/s
INFO:  25% (8.0 GiB of 32.0 GiB) in 1m 28s, read: 97.3 MiB/s, write: 97.3 MiB/s
INFO:  26% (8.4 GiB of 32.0 GiB) in 1m 32s, read: 92.0 MiB/s, write: 92.0 MiB/s
INFO:  27% (8.7 GiB of 32.0 GiB) in 1m 35s, read: 98.7 MiB/s, write: 98.7 MiB/s
INFO:  28% (9.0 GiB of 32.0 GiB) in 1m 39s, read: 82.0 MiB/s, write: 82.0 MiB/s
INFO:  29% (9.3 GiB of 32.0 GiB) in 1m 42s, read: 105.3 MiB/s, write: 105.3 MiB/s
INFO:  30% (9.7 GiB of 32.0 GiB) in 1m 46s, read: 92.0 MiB/s, write: 92.0 MiB/s
INFO:  31% (9.9 GiB of 32.0 GiB) in 1m 49s, read: 98.7 MiB/s, write: 98.7 MiB/s
INFO:  32% (10.3 GiB of 32.0 GiB) in 1m 53s, read: 94.0 MiB/s, write: 94.0 MiB/s
INFO:  33% (10.8 GiB of 32.0 GiB) in 1m 56s, read: 169.3 MiB/s, write: 81.3 MiB/s
INFO:  34% (11.0 GiB of 32.0 GiB) in 1m 59s, read: 72.0 MiB/s, write: 72.0 MiB/s
INFO:  35% (11.4 GiB of 32.0 GiB) in 2m 2s, read: 133.3 MiB/s, write: 80.0 MiB/s
INFO:  39% (12.6 GiB of 32.0 GiB) in 2m 5s, read: 404.0 MiB/s, write: 98.7 MiB/s
INFO:  40% (12.9 GiB of 32.0 GiB) in 2m 8s, read: 90.7 MiB/s, write: 90.7 MiB/s
INFO:  41% (13.2 GiB of 32.0 GiB) in 2m 12s, read: 74.0 MiB/s, write: 74.0 MiB/s
INFO:  42% (13.5 GiB of 32.0 GiB) in 2m 16s, read: 78.0 MiB/s, write: 78.0 MiB/s
INFO:  43% (13.8 GiB of 32.0 GiB) in 2m 21s, read: 77.6 MiB/s, write: 77.6 MiB/s
INFO:  44% (14.1 GiB of 32.0 GiB) in 2m 24s, read: 96.0 MiB/s, write: 96.0 MiB/s
INFO:  45% (14.4 GiB of 32.0 GiB) in 2m 27s, read: 100.0 MiB/s, write: 100.0 MiB/s
INFO:  47% (15.1 GiB of 32.0 GiB) in 2m 30s, read: 220.0 MiB/s, write: 90.7 MiB/s
INFO:  61% (19.5 GiB of 32.0 GiB) in 2m 33s, read: 1.5 GiB/s, write: 0 B/s
INFO:  72% (23.4 GiB of 32.0 GiB) in 2m 36s, read: 1.3 GiB/s, write: 0 B/s
INFO:  89% (28.5 GiB of 32.0 GiB) in 2m 39s, read: 1.7 GiB/s, write: 0 B/s
INFO: 100% (32.0 GiB of 32.0 GiB) in 2m 41s, read: 1.8 GiB/s, write: 2.0 MiB/s
INFO: backup is sparse: 18.77 GiB (58%) total zero data
INFO: backup was done incrementally, reused 18.77 GiB (58%)
INFO: transferred 32.00 GiB in 161 seconds (203.5 MiB/s)

gibt es eventuell Tricks beim Einbinden des NFS Storage für die Performance?
Die fstab sieht auf dem PBS so aus.

192.168.x.x:/mnt/Daten/pbs /mnt/xxxnfs rw,noac,actimeo=0 0 0

Das NFS Storage ist eine aktuelle TrueNAS Version.
Hat jemand Tipps wegen der langen Dauer der Garbage Collection?

 

[Frank666]

Hier wie es jetzt aktuell ist

()
2021-10-23T04:15:00+02:00: starting garbage collection on store xxx
2021-10-23T04:15:00+02:00: task triggered by schedule 'sat 04:15'
2021-10-23T04:15:00+02:00: Start GC phase1 (mark used chunks)
2021-10-23T04:47:50+02:00: marked 1% (11 of 1079 index files)
2021-10-23T05:04:28+02:00: marked 2% (22 of 1079 index files)
2021-10-23T05:16:43+02:00: marked 3% (33 of 1079 index files)
2021-10-23T05:40:46+02:00: marked 4% (44 of 1079 index files)
2021-10-23T05:58:23+02:00: marked 5% (54 of 1079 index files)
2021-10-23T06:14:14+02:00: marked 6% (65 of 1079 index files)
2021-10-23T06:35:44+02:00: marked 7% (76 of 1079 index files)
2021-10-23T06:59:46+02:00: marked 8% (87 of 1079 index files)
2021-10-23T07:19:11+02:00: marked 9% (98 of 1079 index files)
2021-10-23T07:33:55+02:00: marked 10% (108 of 1079 index files)
2021-10-23T07:48:53+02:00: marked 11% (119 of 1079 index files)
2021-10-23T08:07:08+02:00: marked 12% (130 of 1079 index files)
2021-10-23T08:23:50+02:00: marked 13% (141 of 1079 index files)
2021-10-23T08:45:52+02:00: marked 14% (152 of 1079 index files)
2021-10-23T09:24:57+02:00: marked 15% (162 of 1079 index files)
2021-10-23T09:51:08+02:00: marked 16% (173 of 1079 index files)
2021-10-23T11:16:22+02:00: marked 17% (184 of 1079 index files)
2021-10-23T14:34:03+02:00: marked 18% (195 of 1079 index files)
2021-10-23T17:31:22+02:00: marked 19% (206 of 1079 index files)
2021-10-23T19:13:11+02:00: marked 20% (216 of 1079 index files)
2021-10-23T22:21:29+02:00: marked 21% (227 of 1079 index files)
2021-10-23T23:14:52+02:00: marked 22% (238 of 1079 index files)
2021-10-24T00:50:51+02:00: marked 23% (249 of 1079 index files)
2021-10-24T03:45:38+02:00: marked 24% (259 of 1079 index files)
2021-10-24T04:40:13+02:00: marked 25% (270 of 1079 index files)
2021-10-24T05:10:52+02:00: marked 26% (281 of 1079 index files)
2021-10-24T05:36:07+02:00: marked 27% (292 of 1079 index files)
2021-10-24T06:28:39+02:00: marked 28% (303 of 1079 index files)
2021-10-24T07:15:16+02:00: marked 29% (313 of 1079 index files)
2021-10-24T08:09:02+02:00: marked 30% (324 of 1079 index files)
2021-10-24T10:36:29+02:00: marked 31% (335 of 1079 index files)
2021-10-24T13:21:49+02:00: marked 32% (346 of 1079 index files)
2021-10-24T16:19:33+02:00: marked 33% (357 of 1079 index files)
2021-10-24T20:46:10+02:00: marked 34% (367 of 1079 index files)
2021-10-24T22:51:27+02:00: marked 35% (378 of 1079 index files)
2021-10-25T01:08:50+02:00: marked 36% (389 of 1079 index files)
2021-10-25T02:36:23+02:00: marked 37% (400 of 1079 index files)
2021-10-25T04:42:14+02:00: marked 38% (411 of 1079 index files)
2021-10-25T06:49:49+02:00: marked 39% (421 of 1079 index files)
2021-10-25T08:32:50+02:00: marked 40% (432 of 1079 index files)
2021-10-25T10:14:22+02:00: marked 41% (443 of 1079 index files)
2021-10-25T11:54:07+02:00: marked 42% (454 of 1079 index files)
2021-10-25T12:45:54+02:00: marked 43% (464 of 1079 index files)
2021-10-25T13:25:25+02:00: marked 44% (475 of 1079 index files)
2021-10-25T13:36:58+02:00: marked 45% (486 of 1079 index files)
2021-10-25T13:39:01+02:00: marked 46% (497 of 1079 index files)
2021-10-25T13:42:04+02:00: marked 47% (508 of 1079 index files)
2021-10-25T13:44:10+02:00: marked 48% (518 of 1079 index files)
2021-10-25T13:47:23+02:00: marked 49% (529 of 1079 index files)
2021-10-25T13:49:22+02:00: marked 50% (540 of 1079 index files)
2021-10-25T13:51:43+02:00: marked 51% (551 of 1079 index files)
2021-10-25T13:52:35+02:00: marked 52% (562 of 1079 index files)
2021-10-25T13:53:15+02:00: marked 53% (572 of 1079 index files)
2021-10-25T13:54:03+02:00: marked 54% (583 of 1079 index files)
2021-10-25T14:16:58+02:00: marked 55% (594 of 1079 index files)
2021-10-25T14:39:36+02:00: marked 56% (605 of 1079 index files)
2021-10-25T15:01:05+02:00: marked 57% (616 of 1079 index files)
2021-10-25T15:36:00+02:00: marked 58% (626 of 1079 index files)
2021-10-25T15:56:30+02:00: marked 59% (637 of 1079 index files)
2021-10-25T16:16:14+02:00: marked 60% (648 of 1079 index files)
2021-10-25T16:48:15+02:00: marked 61% (659 of 1079 index files)
2021-10-25T17:14:09+02:00: marked 62% (669 of 1079 index files)
2021-10-25T17:35:40+02:00: marked 63% (680 of 1079 index files)
2021-10-25T18:02:24+02:00: marked 64% (691 of 1079 index files)
2021-10-25T18:20:16+02:00: marked 65% (702 of 1079 index files)
2021-10-25T18:31:03+02:00: marked 66% (713 of 1079 index files)
2021-10-25T18:43:44+02:00: marked 67% (723 of 1079 index files)
2021-10-25T18:51:08+02:00: marked 68% (734 of 1079 index files)
2021-10-25T18:54:45+02:00: marked 69% (745 of 1079 index files)
2021-10-25T18:57:41+02:00: marked 70% (756 of 1079 index files)
2021-10-25T19:23:01+02:00: marked 71% (767 of 1079 index files)
2021-10-25T19:31:11+02:00: marked 72% (777 of 1079 index files)
2021-10-25T19:44:41+02:00: marked 73% (788 of 1079 index files)
2021-10-25T20:08:05+02:00: marked 74% (799 of 1079 index files)
2021-10-25T20:28:36+02:00: marked 75% (810 of 1079 index files)
2021-10-25T20:52:58+02:00: marked 76% (821 of 1079 index files)
2021-10-25T21:13:04+02:00: marked 77% (831 of 1079 index files)
2021-10-25T21:36:12+02:00: marked 78% (842 of 1079 index files)
2021-10-25T21:49:22+02:00: marked 79% (853 of 1079 index files)
2021-10-25T22:01:33+02:00: marked 80% (864 of 1079 index files)
2021-10-25T22:28:53+02:00: marked 81% (874 of 1079 index files)
2021-10-25T22:54:41+02:00: marked 82% (885 of 1079 index files)
2021-10-25T23:10:51+02:00: marked 83% (896 of 1079 index files)
2021-10-25T23:31:49+02:00: marked 84% (907 of 1079 index files)
2021-10-25T23:36:39+02:00: marked 85% (918 of 1079 index files)
2021-10-25T23:39:16+02:00: marked 86% (928 of 1079 index files)
2021-10-25T23:42:48+02:00: marked 87% (939 of 1079 index files)
2021-10-25T23:43:31+02:00: marked 88% (950 of 1079 index files)
2021-10-25T23:43:53+02:00: marked 89% (961 of 1079 index files)
2021-10-25T23:44:12+02:00: marked 90% (972 of 1079 index files)
2021-10-25T23:44:47+02:00: marked 91% (982 of 1079 index files)
2021-10-25T23:45:02+02:00: marked 92% (993 of 1079 index files)
2021-10-25T23:45:26+02:00: marked 93% (1004 of 1079 index files)
2021-10-25T23:47:25+02:00: marked 94% (1015 of 1079 index files)
2021-10-25T23:48:05+02:00: marked 95% (1026 of 1079 index files)
2021-10-25T23:48:37+02:00: marked 96% (1036 of 1079 index files)
2021-10-25T23:49:51+02:00: marked 97% (1047 of 1079 index files)
2021-10-25T23:50:41+02:00: marked 98% (1058 of 1079 index files)
2021-10-25T23:51:57+02:00: marked 99% (1069 of 1079 index files)
2021-10-25T23:52:45+02:00: marked 100% (1079 of 1079 index files)
2021-10-25T23:52:45+02:00: Start GC phase2 (sweep unused chunks)
2021-10-25T23:54:30+02:00: processed 1% (17537 chunks)
2021-10-25T23:56:17+02:00: processed 2% (35411 chunks)
2021-10-25T23:58:25+02:00: processed 3% (53104 chunks)
2021-10-26T01:52:28+02:00: processed 4% (70716 chunks)
2021-10-26T02:20:49+02:00: processed 5% (88504 chunks)
2021-10-26T02:23:56+02:00: processed 6% (106574 chunks)
2021-10-26T02:26:47+02:00: processed 7% (124337 chunks)
2021-10-26T02:29:32+02:00: processed 8% (142289 chunks)
2021-10-26T02:31:39+02:00: processed 9% (159975 chunks)
2021-10-26T02:33:13+02:00: processed 10% (177832 chunks)
2021-10-26T02:34:44+02:00: processed 11% (195687 chunks)
2021-10-26T02:36:17+02:00: processed 12% (213451 chunks)
2021-10-26T02:37:58+02:00: processed 13% (231390 chunks)
2021-10-26T02:40:05+02:00: processed 14% (249490 chunks)
2021-10-26T02:42:17+02:00: processed 15% (267245 chunks)
2021-10-26T02:44:18+02:00: processed 16% (284922 chunks)
2021-10-26T02:45:59+02:00: processed 17% (302952 chunks)
2021-10-26T02:47:55+02:00: processed 18% (320869 chunks)
2021-10-26T02:50:00+02:00: processed 19% (338566 chunks)
2021-10-26T02:52:08+02:00: processed 20% (356516 chunks)
2021-10-26T02:54:11+02:00: processed 21% (374358 chunks)
2021-10-26T02:56:16+02:00: processed 22% (392120 chunks)
2021-10-26T02:58:17+02:00: processed 23% (409919 chunks)
2021-10-26T02:59:59+02:00: processed 24% (427861 chunks)
2021-10-26T03:02:39+02:00: processed 25% (445679 chunks)
2021-10-26T03:05:03+02:00: processed 26% (463631 chunks)
2021-10-26T03:07:42+02:00: processed 27% (481450 chunks)
2021-10-26T03:09:49+02:00: processed 28% (499426 chunks)
2021-10-26T03:12:14+02:00: processed 29% (517618 chunks)
2021-10-26T03:15:06+02:00: processed 30% (535399 chunks)
2021-10-26T03:18:32+02:00: processed 31% (553318 chunks)
2021-10-26T03:21:51+02:00: processed 32% (571263 chunks)
2021-10-26T03:25:17+02:00: processed 33% (589275 chunks)
2021-10-26T03:28:39+02:00: processed 34% (607066 chunks)
2021-10-26T03:32:17+02:00: processed 35% (625054 chunks)
2021-10-26T03:36:03+02:00: processed 36% (643186 chunks)
2021-10-26T03:39:51+02:00: processed 37% (661290 chunks)
2021-10-26T03:42:54+02:00: processed 38% (679077 chunks)
2021-10-26T03:46:11+02:00: processed 39% (697080 chunks)
2021-10-26T03:49:18+02:00: processed 40% (714988 chunks)
2021-10-26T03:52:50+02:00: processed 41% (732804 chunks)
2021-10-26T03:56:11+02:00: processed 42% (751020 chunks)
2021-10-26T03:59:18+02:00: processed 43% (768789 chunks)
2021-10-26T04:02:57+02:00: processed 44% (786621 chunks)
2021-10-26T04:06:20+02:00: processed 45% (804726 chunks)
2021-10-26T04:09:35+02:00: processed 46% (822753 chunks)
2021-10-26T04:12:46+02:00: processed 47% (840820 chunks)
2021-10-26T04:15:57+02:00: processed 48% (858795 chunks)
2021-10-26T04:18:11+02:00: processed 49% (876771 chunks)
2021-10-26T04:20:05+02:00: processed 50% (894765 chunks)
2021-10-26T04:22:08+02:00: processed 51% (912727 chunks)
2021-10-26T04:24:14+02:00: processed 52% (930762 chunks)
2021-10-26T04:26:16+02:00: processed 53% (948727 chunks)
2021-10-26T04:28:22+02:00: processed 54% (966512 chunks)
2021-10-26T04:30:28+02:00: processed 55% (984369 chunks)
2021-10-26T04:32:32+02:00: processed 56% (1002468 chunks)
2021-10-26T04:34:40+02:00: processed 57% (1020711 chunks)
2021-10-26T04:36:35+02:00: processed 58% (1038462 chunks)
2021-10-26T04:38:37+02:00: processed 59% (1056708 chunks)
2021-10-26T04:40:42+02:00: processed 60% (1074650 chunks)
2021-10-26T04:42:46+02:00: processed 61% (1092666 chunks)
2021-10-26T04:44:46+02:00: processed 62% (1110698 chunks)
2021-10-26T04:46:48+02:00: processed 63% (1128629 chunks)
2021-10-26T04:48:52+02:00: processed 64% (1146393 chunks)
2021-10-26T04:50:59+02:00: processed 65% (1164335 chunks)
2021-10-26T04:53:04+02:00: processed 66% (1182313 chunks)
2021-10-26T04:55:06+02:00: processed 67% (1200555 chunks)
2021-10-26T04:57:11+02:00: processed 68% (1218389 chunks)
2021-10-26T04:59:12+02:00: processed 69% (1236230 chunks)
2021-10-26T05:01:16+02:00: processed 70% (1254171 chunks)
2021-10-26T05:03:18+02:00: processed 71% (1272249 chunks)
2021-10-26T05:05:22+02:00: processed 72% (1290356 chunks)
2021-10-26T05:07:28+02:00: processed 73% (1308441 chunks)
2021-10-26T05:09:33+02:00: processed 74% (1326328 chunks)
2021-10-26T05:11:41+02:00: processed 75% (1344026 chunks)
2021-10-26T05:13:55+02:00: processed 76% (1362313 chunks)
2021-10-26T05:16:09+02:00: processed 77% (1380375 chunks)
2021-10-26T05:18:20+02:00: processed 78% (1398344 chunks)
2021-10-26T05:20:33+02:00: processed 79% (1415979 chunks)
2021-10-26T05:22:37+02:00: processed 80% (1433753 chunks)
2021-10-26T05:24:33+02:00: processed 81% (1451571 chunks)
2021-10-26T05:26:12+02:00: processed 82% (1469368 chunks)
2021-10-26T05:27:53+02:00: processed 83% (1487354 chunks)
2021-10-26T05:29:26+02:00: processed 84% (1505105 chunks)
2021-10-26T05:31:12+02:00: processed 85% (1523179 chunks)
2021-10-26T05:32:51+02:00: processed 86% (1540999 chunks)
2021-10-26T05:34:34+02:00: processed 87% (1558850 chunks)
2021-10-26T05:36:14+02:00: processed 88% (1576709 chunks)
2021-10-26T05:37:50+02:00: processed 89% (1594615 chunks)
2021-10-26T05:39:28+02:00: processed 90% (1612743 chunks)
2021-10-26T05:41:17+02:00: processed 91% (1630657 chunks)
2021-10-26T05:42:53+02:00: processed 92% (1648860 chunks)
2021-10-26T05:44:39+02:00: processed 93% (1666835 chunks)
2021-10-26T05:46:22+02:00: processed 94% (1684887 chunks)
2021-10-26T05:47:57+02:00: processed 95% (1702836 chunks)
2021-10-26T05:49:39+02:00: processed 96% (1720774 chunks)
2021-10-26T05:51:22+02:00: processed 97% (1738774 chunks)
2021-10-26T05:53:04+02:00: processed 98% (1756569 chunks)
2021-10-26T05:54:45+02:00: processed 99% (1774619 chunks)
2021-10-26T05:56:29+02:00: Removed garbage: 252.79 GiB
2021-10-26T05:56:29+02:00: Removed chunks: 147870
2021-10-26T05:56:29+02:00: Pending removals: 546.64 KiB (in 1 chunks)
2021-10-26T05:56:29+02:00: Original data usage: 39.95 TiB
2021-10-26T05:56:29+02:00: On-Disk usage: 2.79 TiB (6.99%)
2021-10-26T05:56:29+02:00: On-Disk chunks: 1644460
2021-10-26T05:56:29+02:00: Deduplication factor: 14.31
2021-10-26T05:56:29+02:00: Average chunk size: 1.78 MiB
2021-10-26T05:56:29+02:00: TASK OK

 

[RolandK]

nfs ist denkbar ungünstig für ein pbs storage repo.

der workload von pbs ist metadata zentrisch. ein solcher workload ist über nfs grundsätzlich lahm.

selbst mit normalen disks ist man bei pbs schnell am limit (was ich selber übrigens sehr bedauerlich finde. ich will kein ssd-only oder special-vdev auf ssd für backup einsetzen. bislang halte ich mich mit zfs + l2arc + secondarycache=metadata noch über wasser)

https://serverfault.com/questions/1...e-transfers-so-slow-with-multiple-small-files

https://pbs.proxmox.com/docs/installation.html#recommended-server-system-requirements

 

[Dunuin]

Ist dein lokaler datastore vielleicht auch auf SSDs und der über NFS auf HDDs? HDDs haben ja generell ein ein Problem mit all den IOs vom GC. Das ganze dann mit Overhead vom NFS und hohe Latenz wegen Netzwerkkommunikation macht es dann natürlich nicht besser.

 

[Frank666]

alle Datastores sund auf normalen HDD's
inzwischen habe ich auch tägliche Abbrüche bei den Backups über NFS

 

[Falk R.]

Mein bescheidener Tip. Wenn du unbedingt ein NAS als Backup target nutzen willst, hänge es direkt im PVE ein. Da funktioniert das ganz gut seine Dumps auf ein NFS zu schieben. Der PBS funktioniert ein wenig anders und hat andere Ansprüche an die Disks. Wenn PBS dann bitte mit local Disks.
SSDs finde ich ein wenig to much für den Standarduser, das wird eher im Enterprise Umfeld gemacht.
Ein NAS ist fast immer deutlich langsamer als lokale Disks.

 

[Frank666]

ich werde es erstmal so lassen, da überwiegen für mich noch bei weitem die Vorteile des PBS, gegenüber dem Backup über PVE.
Ist schon klar, dass das über NS langsamer ist als über lokale Platten.
Ohne irgendwas geändetr zu haben gab es die letzten beiden Tage kein einzigen Fehler bei allen Backups...
Werde es einfach weiter beobachten

 

[Dunuin]

Was wäre zu bevorzugen wenn man die 2 Optionen hätte?
1.) Datastore auf Zvol auf einer einzelnen lokalen HDD
2.) Datastore auf NFS, aber NFS server läuft lokal in VM und hat ein raidz1 auf 4x HDDs + special device mirror

Einerseits ist NFS ja ungünstig und fehleranfälliger. Andererseits wäre bandbreite und ausfallsicherheit wegen raid sehr nett und GC wegen special device vmrl. viel schneller.

 

[Falk R.]

Dazu hätte ich gern mehr Infos. Wenn dein NFS auf deinem PVE liegt, wovon du VMs sicherst, ist das eine schlechte Idee. Ich sichere auch lieber auf meine USB Disk an meinem RasPi, um das Backup auf externer Hardware zu haben.
Alle wichtigen Daten, werden bei mir auch noch zusätzlich in die Cloud gesichert.

Sobald man damit Geld verdient, gibt's bei mir immer nur dedizierte HW.

Zu deinem Setup, wo laufen das Zvol und das RaidZ?

 

[Dunuin]

Sind nur meine Heimserver die mich ausschließlich viel Geld kosten.
PBS läuft bei mir gerade als VM auf einem Bare Metal TrueNAS, damit es eben nicht auf dem PVE Server laufen muss. Datastore liegt auf einem Dataset des TrueNAS Servers was dann per NFS in die PBS VM gebracht wird. Da könnte ich jetzt zwar noch statt NFS auch der VM ein zvol zum Speichern des Datastores geben, aber ich wollte in ferner Zukunft gerne den TrueNAS Server einmotten und diesen auf einem neuen größeren PVE Server virtualisieren. Sobald das TrueNAS virtualisiert wäre, hätte ich da dann ja höchstens noch NFS als Option um auf die Datasets der TrueNAS VM zu kommen, wenn da PBS nicht mehr vom TrueNAS virtualisiert wird. Weil die TrueNAS VM hätte dann alle Laufwerke direkt über zwei durchgereichte HBAs.
Wo ich das PBS dann laufen lasse weiß ich noch nicht so genau. Vermutlich auf dem PVE auf dem dann auch die TrueNAS VM läuft. Ist dann natürlich ungüstig, wenn da dann das PVE ausfällt, auf dem auch die PBS und TrueNAS VMs laufen.
Ich hätte da dann aber noch einen dritten (Bare Metal TrueNAS) Server der nur 1 mal die Woche kurz angeht um eine Replikation anzunehmen. Auf dem könnte ich dann eigentlich eine zweite PBS VM laufen lassen und der ein zvol als Datastore geben. Dann könnte meine Haupt PBS VM einmal die Woche kurz den Datastore rüber zur Backup PBS VM replizieren. Dann hätte ich einen immer laufenden PBS für die täglichen PVE Backups und einen langsameren Backup PBS den ich zur Not anwerfen könnte, wenn das PVE mit dem Haupt PBS mal ausfällt. Und ein Backup vom Backup wäre damit dann ja auch gleich gelöst.

 

[Falk R.]

Da hast du für dich ja schon die optimalste/flexibelste Konfiguration gewählt. Ich sehe bei dir jetzt auf Anhieb auch keinen besseren Vorschlag.
Ich habe meinen PBS nicht mehr am laufen, da er mir keine großen Vorteile bringt. Mein Backup DataStore ist ja auch per NFS angebunden und da laufen die VZDumps performant. Die anderen Sachen wie M365 Backup und so mache ich eh mit Veeam. Das läuft auch als VM, mit dem RasPi als Target, aber Veeam ist da auch nicht so anspruchsvoll wie PBS.
Ich betreue auch eine Stadtverwaltung mit einigen Schulen, die haben da nur 2 Windows Server und der Rest alles Linux. da macht PVE mit PBS richtig Sinn und da hat man dann auch die passende Größe für einen vernünftigen, dedizierten PBS.

 

[Dunuin]

Ich mag den PBS vorallem wegen der Deduplikation die kaum RAM Anforderung hat (läuft hier super mit 3GB RAM). Mit Vzdump musste ich immer gucken, dass ich da nicht zu viele Backups behalte. Mit PBS tut sich da ja vom Platz her nicht mehr viel, ob ich da nun 1 Backup oder 30 Backups jeder VM habe. Da lasse ich dann gleich 14 tägliche + 8 wöchentliche + 12 monatliche + 3 jährliche Backups speichern. Nimmt mir dann auch nicht mehr Platz weg als 2 wöchentliche Vzdump Backups und ich konnte die ZFS Snapshots dafür deaktivieren, die zusätzlich nochmal ziemlich viel Platz gefressen haben.
Im Endeffekt habe ich dann jetzt 30 volle Backups jeder VM die weniger Platz brauchen als 1-2 Vzdump Backups, wenn man die Ersparnis der Snapshots einberechnet. Und die ZFS Snapshots hatten mir wertvollen Enterprise SSD Platz geraubt. Backups kann ich ja auf billige HDDs legen.

Den Veeam Windows Agent habe ich auch gerade seit 2 Wochen testweise in Nutzung. So richtig konnte ich mich mit dem aber noch nicht anfreunden. Meine Windows Workstation sichert die Backups mit dem halt auf ein SMB Share und wenn der Windows Rechner mal von Ransomware befallen wäre, dann würde die Ransomware ja auch gleich die Backups mitverschlüsseln und das ganze Backup wäre sinnlos. Um das zu umgehen sehe ich da nur 2 Optionen:
1.) mein SMB Share mit ZFS Snapshots sichern die eine lange (2 Monate) Retention haben. Ist aber recht unschön da man ja wohl bei Veeam "Active Full Backups" oder wenigstens "Full Backup File Maintaince" aktivieren sollte, das mit das Backup über die Zeit nicht fragmentiert und dann langsamer und größer wird. Beides sorgt dann aber dafür, dass da immer das komplette Backup mehrfach geschrieben werden muss. Ist bei der "Full Backup Maintaince" zwar nur temporär, aber wenn da ZFS Snapshots im Hintergrund laufen, können dieses riesigen temporären Daten ja auch für Monate nicht gelöscht werden. Ist dann unschön wenn ich da 1 TB an Backups habe und und dann noch 2 oder 3 TB an extra Daten anfallen, die einfach blockiert sind wegen Snapshots.
2.) Was mir am meisten zusagen würde wäre das Veeam Backup & Replication als Server, dass da der Veeam Agent direkt die Backups an den schickt und sich dann der Server um die Retention und Rechte kümmert, dass da meine Clients zwar Backups wiederherstellen und erstellen aber nicht ändern oder löschen können. Wenn ich das richtig verstanden habe läuft das aber nur auf Windows und hätte gerne um die 12GB RAM oder mehr als minimale Hardwareanforderung. RAM und CPU ist bei mir eh immer knapp, da würde ich nur ungerne zusätzlich noch eine VM mit 12GB RAM und 4 Cores anwerfen, die nichts anderes tut als meine 2 Windows Rechner zu sichern.

TrueNAS hätte da noch einen Modus für SMB Shares, wo Dateien nur innerhalb der ersten 5 Minuten geändert werden können. Danach wären die Backups read-only. Das sollte ja prinzipiell für "Active Full Backups" + inkrementelle Backups klappen, solange man da nicht "Full Backup Maintaince" benutzt, aber leider speichert Veeam ja die Backup-Konfig auch in dem SMB Share. Wäre die VBM-Datei readonly könnte man ja die Backups nicht mehr verwalten. Und mit automatischer Backup Retention wäre dann auch nichts, die würde man dann manuell per CLI direkt vom NAS aus löschen müssen.

Und die inkrementellen Snapshots scheinen bei Veeam immer recht viel Platz zu brauchen. Ich habe hier gute 400GB an zu sichernden Daten und jedes inkrementelle Backup (z.B. wenn ich eines jede Stunde mache) braucht immer mindestens 17GB, selbst wenn sich höchstens einige MB geändert haben. Das in Kombination mit langen ZFS Snapshots kommt echt übel. Wenn ich die ZFS Snapshot Retention auf 2 Monate setze und Veeam die Backups 2 Wochen behalten soll und jedes tägliche inkrementelle Backup mindestens 17GB braucht, dann wären das ja schon 74x 17GB, also 1,3TB an reinem Overhead, nur um tägliche Backups für 2 Wochen von 400GB an Daten zu haben. Alle echten Datenänderungen würde dann ja da noch oben drauf kommen. Und dann noch 2x 400GB an nicht löschbaren temporären Daten im Falle von "Full Backup Maintaince". Da wäre ich dann schon mindestens bei 2,5TB an verlorenem Speicherplatz, selbst wenn sich kein Byte geändert hat, wenn ich eigentlich nur 400GB sichern will.

Habe mir da gerade erst Duplicati, UrBackup, Rsync, BackupPC und Restic angeguckt, aber die haben da alle ihre Macken und würden entweder nicht gegen Ransomware schützen, zu viel Speicherplatz verschwenden, konnten kein VSS vom Client nutzen um verschlüsselte/geöffnete Daten zu sichern oder haben andere Probleme verursacht. Sowas wie PBS für Windows Clients wäre echt ideal, aber das wird ja wohl leider nie kommen.

 

[Falk R.]

Ich mag den PBS vorallem wegen der Deduplikation die kaum RAM Anforderung hat (läuft hier super mit 3GB RAM).

Ja das ist echt ein großer Vorteil, aber bei mir zuhause ist das Datenaufkommen nicht so hoch.

2.) Was mir am meisten zusagen würde wäre das Veeam Backup & Replication als Server, dass da der Veeam Agent direkt die Backups an den schickt und sich dann der Server um die Retention und Rechte kümmert, dass da meine Clients zwar Backups wiederherstellen und erstellen aber nicht ändern oder löschen können. Wenn ich das richtig verstanden habe läuft das aber nur auf Windows und hätte gerne um die 12GB RAM oder mehr als minimale Hardwareanforderung. RAM und CPU ist bei mir eh immer knapp, da würde ich nur ungerne zusätzlich noch eine VM mit 12GB RAM und 4 Cores anwerfen, die nichts anderes tut als meine 2 Windows Rechner zu sichern.

Ich habe eine VM mit B&R (2vCPU / 8GB Ram) Bei mir ist RAM kein Problem. mit weniger RAM wird es etwas langsamer, aber zuhause ist das ja egal.
Mit B&R kannst du das Linux Hardened Repository nutzen und da habe ich generell XFS mit reflink am laufen. Meine erste Installation des LHR hat derzeit 450TB Backupdaten (30 Tage / 12 Wochen / 12 Monate) derzeit auf 100TB usage on Disk geschrieben. Rattenschnell ist das mit Kernel 5.4+ auch noch.

Und die inkrementellen Snapshots scheinen bei Veeam immer recht viel Platz zu brauchen. Ich habe hier gute 400GB an zu sichernden Daten und jedes inkrementelle Backup (z.B. wenn ich eines jede Stunde mache) braucht immer mindestens 17GB, selbst wenn sich höchstens einige MB geändert haben.

Auf meinem RasPi funktioniert das LHR leider nicht (nur x86) aber mit Reflink Support (XFS / BTRFS) kann man eine Menge raus holen.