Only reason why I'm considering it because with SAS I'd be almost getting 1TB, rather than 140GB SSD.
Hmm - in this position you should wait for the G9 RS, which will come in the next weeks or months. Just my suggestion, because the G9 RS will probably have much more ssd storage as the G8 RS. 
Manche Software ist einfach toll, das muss man schon sagen... 
root@nas:/storage/serverbackup/backups# borg info pvehost/
Repository ID: xxx
Location: /storage/serverbackup/backups/pvehost
Encrypted: No
Cache: /root/.cache/borg/xxx
Security dir: /root/.config/borg/security/xxx
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
All archives: 459.21 GB 202.84 GB 10.95 GB
Unique chunks Total chunks
Chunk index: 184284 7905056
root@nas:/storage/serverbackup/backups#Aus 460 GB mach 11 GB - ein Traum! 
Wie wundervoll... unser liebster Datensammler Google bekommt (hoffentlich) bald mal wieder schön eine auf die Finger! --> https://noyb.eu/de/beschwerde-…-id-eingereicht
Ist der Storage Space ähnlich, langsamer oder schneller als der Festplattenzugriff des Storage Servers?
Ich hätte Zugriff auf einen S1000 G7 und wie du ja gesehen hast auf einen Storagespace.
Wenn du mir explizit sagen könntest, welchen Benchmark du haben möchtest (im Optimalfall mit Befehl), dann kann ich dir da gerne mal die Werte zukommen lassen.
Abgesehen davon glaube ich aber nicht, dass die IOPS dein Bottleneck werden. Ich sehe das eher beim Netzwerkinterface, durch welchen dein Traffic bei beiden Varianten fließt.
Ich bin mir recht sicher, dass du zumindest mit einem S1000 G7 mit Seafile wohl eher weniger glücklich werden wirst. Wir betreiben da eine Nextcloud drauf und naja... es ist erträglich, aber unsere Nextcloud Instanzen auf Root Servern (SAS) sind deutlich schneller.
Also wenn du zum Storageserver greifst, solltest du da mal mindestens eine Nummer größer skalieren.
Wenn du den Storageserver als rsync Destination von Remote aus nimmst, wirst du dich sicher per SSH verbinden und rsync tunnelt da durch - und auch hier sehe ich ein Bottleneck, denn die SSH Verbindung könnte da echt ein Performancekiller sein.
In der Hinsicht ist der Storagespace mit NFS die bessere Wahl.
Was widerum nicht ganz so performant sein könnte, ist, wenn du das Datenbackend des Seafile auf einen Storagespace legst. Aber das habe ich so noch nie probiert, da kann ich nichts dazu sagen. Kann gut gehen, muss aber nicht.
Nice. Ubuntu 20.04 loggt das LUKS Passwort beim OS Setup im Klartext... einmal mit Profis.
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1878115
Zu dem gesagten von KB19 - der Traffic über das normale Interface Netcup intern wird genau wie raus ins Internet behandelt, also auf dein X TB Traffic Quota angerechnet.
Solltest du intern unlimitierten Traffic brauchen, dann solltest du zum Cloud VLAN greifen.
Sofern du mit deinem Traffic Quota klar kommst, kannst du deine Server aber z.B. auch per Wireguard miteinander verbinden. So mache ich es, da hat man dann ohne zusätzliche Kosten eine Verbindung mit GBit Peformance - man darf halt wie gesagt nicht das Quota sprengen, aber das soll auch erstmal einer schaffen.
Ein Kumpel hat mir gerade diese Seite empfohlen - sehr zu empfehlen.
Ich rieche da ganz viele Realitäten, über die ich jeden Tag bei der Arbeit drüber stolpere... 
Und, so sehe ich es gerade - die Inhalte sind von vor ca. 20 Jahren. Das war noch vor meiner Zeit. Seht her, Fortschritt! 
Ich lasse hier einfach mal ein Schreib-Benchmark von RS 8000 G8SE SSD auf Storagespace (per NFS) fallen.
root@server:/backup-storagespace/test# fio --name=job-w --rw=write --size=2G --ioengine=libaio --iodepth=4 --bs=128k --direct=1 --filename=bench.file --output-format=normal,terse
job-w: (g=0): rw=write, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=libaio, iodepth=4
fio-3.12
Starting 1 process
job-w: Laying out IO file (1 file / 2048MiB)
3;fio-3.12;job-w;0;0;0;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;1.000000%=0;5.000000%=0;10.000000%=0;20.000000%=0;30.000000%=0;40.000000%=0;50.000000%=0;60.000000%=0;70.000000%=0;80.000000%=0;90.000000%=0;95.000000%=0;99.000000%=0;99.500000%=0;99.900000%=0;99.950000%=0;99.990000%=0;0%=0;0%=0;0%=0;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;2097152;110813;865;18925;12;3204;58.768561;92.937655;554;215968;4554.574228;7240.499367;1.000000%=839;5.000000%=1187;10.000000%=1630;20.000000%=2539;30.000000%=3293;40.000000%=3751;50.000000%=4046;60.000000%=4292;70.000000%=4554;80.000000%=4947;90.000000%=5931;95.000000%=8847;99.000000%=18743;99.500000%=20578;99.900000%=78118;99.950000%=210763;99.990000%=214958;0%=0;0%=0;0%=0;622;216007;4614.177903;7240.633082;68864;122112;99.802394%;110594.027027;16123.990257;1.796660%;5.067639%;23974;0;11;0.1%;0.1%;100.0%;0.0%;0.0%;0.0%;0.0%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.41%;2.42%;10.90%;34.94%;46.94%;3.87%;0.40%;0.03%;0.10%;0.00%;0.00%;0.00%;0.00%;0.00%
job-w: (groupid=0, jobs=1): err= 0: pid=9500: Tue May 12 19:16:44 2020
write: IOPS=865, BW=108MiB/s (113MB/s)(2048MiB/18925msec); 0 zone resets
slat (usec): min=12, max=3204, avg=58.77, stdev=92.94
clat (usec): min=554, max=215968, avg=4554.57, stdev=7240.50
lat (usec): min=622, max=216007, avg=4614.18, stdev=7240.63
clat percentiles (usec):
| 1.00th=[ 840], 5.00th=[ 1188], 10.00th=[ 1631], 20.00th=[ 2540],
| 30.00th=[ 3294], 40.00th=[ 3752], 50.00th=[ 4047], 60.00th=[ 4293],
| 70.00th=[ 4555], 80.00th=[ 4948], 90.00th=[ 5932], 95.00th=[ 8848],
| 99.00th=[ 18744], 99.50th=[ 20579], 99.90th=[ 78119], 99.95th=[210764],
| 99.99th=[214959]
bw ( KiB/s): min=68864, max=122112, per=99.80%, avg=110594.03, stdev=16123.99, samples=37
iops : min= 538, max= 954, avg=864.00, stdev=125.97, samples=37
lat (usec) : 750=0.41%, 1000=2.42%
lat (msec) : 2=10.90%, 4=34.94%, 10=46.94%, 20=3.87%, 50=0.40%
lat (msec) : 100=0.03%, 250=0.10%
cpu : usr=1.80%, sys=5.07%, ctx=23974, majf=0, minf=11
IO depths : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,16384,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=4
Run status group 0 (all jobs):
WRITE: bw=108MiB/s (113MB/s), 108MiB/s-108MiB/s (113MB/s-113MB/s), io=2048MiB (2147MB), run=18925-18925msec
root@server:/backup-storagespace/test# fio --name=job-randw --rw=randwrite --size=2G --ioengine=libaio --iodepth=32 --bs=4k --direct=1 --filename=bench.file --output-format=normal,terse
job-randw: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process
3;fio-3.12;job-randw;0;0;0;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;1.000000%=0;5.000000%=0;10.000000%=0;20.000000%=0;30.000000%=0;40.000000%=0;50.000000%=0;60.000000%=0;70.000000%=0;80.000000%=0;90.000000%=0;95.000000%=0;99.000000%=0;99.500000%=0;99.900000%=0;99.950000%=0;99.990000%=0;0%=0;0%=0;0%=0;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;2097152;93190;23297;22504;1;13820;9.716282;38.549176;161;27379;1360.836167;865.968350;1.000000%=593;5.000000%=724;10.000000%=806;20.000000%=921;30.000000%=1019;40.000000%=1105;50.000000%=1204;60.000000%=1302;70.000000%=1433;80.000000%=1613;90.000000%=1957;95.000000%=2375;99.000000%=4145;99.500000%=5931;99.900000%=11730;99.950000%=14352;99.990000%=24510;0%=0;0%=0;0%=0;316;27382;1371.082564;866.144279;61912;116712;99.993633%;93184.066667;12363.489354;5.941430%;21.166067%;159773;0;9;0.1%;0.1%;0.1%;0.1%;0.1%;100.0%;0.0%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.01%;0.21%;5.95%;21.99%;62.69%;8.07%;0.93%;0.14%;0.02%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%
job-randw: (groupid=0, jobs=1): err= 0: pid=9547: Tue May 12 19:18:39 2020
write: IOPS=23.3k, BW=91.0MiB/s (95.4MB/s)(2048MiB/22504msec); 0 zone resets
slat (nsec): min=1643, max=13821k, avg=9716.28, stdev=38549.18
clat (usec): min=161, max=27379, avg=1360.84, stdev=865.97
lat (usec): min=316, max=27382, avg=1371.08, stdev=866.14
clat percentiles (usec):
| 1.00th=[ 594], 5.00th=[ 725], 10.00th=[ 807], 20.00th=[ 922],
| 30.00th=[ 1020], 40.00th=[ 1106], 50.00th=[ 1205], 60.00th=[ 1303],
| 70.00th=[ 1434], 80.00th=[ 1614], 90.00th=[ 1958], 95.00th=[ 2376],
| 99.00th=[ 4146], 99.50th=[ 5932], 99.90th=[11731], 99.95th=[14353],
| 99.99th=[24511]
bw ( KiB/s): min=61912, max=116712, per=99.99%, avg=93184.07, stdev=12363.49, samples=45
iops : min=15478, max=29178, avg=23296.00, stdev=3090.87, samples=45
lat (usec) : 250=0.01%, 500=0.21%, 750=5.95%, 1000=21.99%
lat (msec) : 2=62.69%, 4=8.07%, 10=0.93%, 20=0.14%, 50=0.02%
cpu : usr=5.94%, sys=21.17%, ctx=159773, majf=0, minf=9
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,524288,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=91.0MiB/s (95.4MB/s), 91.0MiB/s-91.0MiB/s (95.4MB/s-95.4MB/s), io=2048MiB (2147MB), run=22504-22504msecLinktip: Pi-hole v5.0 is here! ("Read all the notes before you make the jump, and make a backup!")
Arbeit! Wuhuu! Man hat ja sonst nichts zu tun!
Werde ich mir heute Abend mal anschauen.
Also ich habe goaccess aus eben jenem Grund bei mir rausgeschmissen... vielleicht ein paar einfache Bash Scripts schreiben?
Hi,
die VPS und RS sind unmanaged, was heißt, ihr habt die volle administrative Verantwortung und baut alles selbst auf. Demenstprechend kann man das so nicht beantworten - das ist im Endeffekt eure Entscheidung.
Bei managed Private Servern kann ich es nicht sagen. Hier würde ich euch empfehlen, den Support direkt zu fragen (sofern es nicht in der Produktbeschreibung steht).
Falls jemand sich mal gefragt hat, warum Thunderbird so komische zwei Bindestriche zwischen Mail und Signatur packt... hier ist die Antwort: RFC 3676, Absatz 4.3
Man lernt echt nie aus...
Aber wie bereits geschrieben habe ich nun einen Professionellen Provider wo alles von der ersten Sekunde gelaufen ist.
Das hat nicht unbedingt was mit professionell oder nicht zu zun - in Puncto Support vielleicht, da gebe ich dir Recht. Aber sei dir da bitte bei deinem neuen Providern nicht zu sicher, denn auch das Subnetz dieses Providers kann bei MS auf der Blocklist landen, wenn da irgendein Kunde Mist baut... da hat man aber als Provider keinen wirklichen Einfluss. Zumal man ja nicht wirklich testen kann, ob Microsoft da was blockt oder nicht. Alles in allem eine miese Situation, die in meinen Augen Microsofts Arroganz und Ignoranz und zudem auch der Inkompetenz von dessen indischen Billigsupport geschuldet ist.
Das hat jetzt nicht unbedingt was damit zu tun, dass ich Netcup in Schutz nehmen mag, sondern damit, dass du nicht nochmal enttäuscht wirst.
Ich frag mich ja eh, ob es Videotelefonie für geschäftliche Besprecungen ernsthaft braucht.
Meines Erachtens überhaupt nicht. Hier ist es eher relevant, die Videoübertragung zum Teilen des eigenen Bildschirms zu nutzen.
Wichtiger sehe ich es eher bei privateter Videotelefonie, damit die Oma auch mal die Enkel zu sehen bekommt in diesen Zeiten. Aber das sind dann ja nur zwei Teilnehmer.
Dann ist bzw. sollte es technisch gesehen p2p sein und das verursacht eher weniger Serverlast...
IP ist immer noch auf SPAM Support reagiert nicht, bzw. stellt immer die selbe Frage
Nanu - also ich bin mit meinem unmanaged Server zwar auch noch zu keiner Lösung gekommen, allerdings liegt das an Microsofts Ignoranz. Der Netcup Support hat mir hier immer geholfen und war sehr lösungorientiert.
Welche "selbe Frage" wurde dir denn gestellt, wenn man fragen darf?
Ob wohl ich sagen muss das ich absolut enttäuscht von netcup bin, finde ich dieses Forum und die Aktivitäten Super. Da Forum ist hier echt lebendig und hilfreich, daran könnte sich der Anbieter mal ein beispiel nehmen.
Ich fasse das mal als Lob auf und sage: Danke, immer gerne! 
Ich kann nur für AWS Cloudfront sprechen - wenn du auf einem Netcup Server hostest, dann ist der Weg folgender: Netcup Server -> dirty internet (komplette Strecke) -> Client
Bei AWS Cloudfront wäre es meines Wissens so: Netcup Server --> kurze Strecke dirty internet --> AWS Edge Location --> AWS Backbone --> Cloudfront in Region Frankfurt --> AWS Backbone --> AWS Edge Locations --> kurze Strecke dirty internet --> Client
Du würdest also vom Cache und der schnellen Infrastruktur profitieren... ich glaube allerdings, dass der Grad des Profitierens nicht wirklich hoch sein wird. Vielleicht sogar unspürbar...
Aus Sicht des Datenschutzes sollte man in meinen Augen aber sehr genau abwägen, ob ein CDN wirklich benötigt wird. Für Websites nur innerhalb von Deutschland würde ich noch nicht wirklich dazu raten... keep it straight and simple.
duckr Also MuPDF kann nur betrachten - der ist also schonmal raus.
Foxit lädt gerade herunter... die haben irgendwie nen ziemlichen Bambusupload auf ihren Servern.
Mit welcher Software kann man eigentlich unter Linux PDF Dateien richtig unterschreiben.
Richtig im Sinne von mit einem Stift auf einem Touchscreen.
Unter Windows geht das ja recht elegant mit dem Adobe Acrobat Reader dingsda - aber unter Linux konnte ich bisher noch keine elegante Lösung finden...
Naja, dann schrauben wir Spiegel dran und brauchen keine Straßenlaternen mehr.
Die Rolladenindustrie wird es freuen.
Am Ende holen wir uns noch eine Klimaerkältung, weil die Satelliten die Sonnenstrahlen abfangen.
Eventuell so? Gibt auch Grafana-Plugins. https://github.com/jitsi/jitsi-vi…c/statistics.md
Ich rieche Arbeit für heute Abend...
Danke!
