Search results

So, because I was unable to solve this issue, I set the backup job to use Notification mode: "notification center" and in there I set the a match based on severity with all but info and notice, and there I only use gmail as target.

So to summarize where we currently are: Setting "Default (Auto)" for a backup notification, defaults to the disabled sendmail instead of the enabled SMTP. At least that is what I think is happening.

@Onslow, could you delete the other one too? You find it be searching for ::2 It is not a huge deal, since it does not allow any incoming traffic anyway. I would also not care if it were my ISP (I have public DNS anyway) but it is the IP of one of my clients.

Ups, forget the censor that IP, would you mind editing your text? But thank you for that hint, I think I now know what went wrong. PVE used sendmail (with its IPv6) instead of the gmail smtp server to send the mail to me. But why? It is disabled after all.

Yes it does. Maybe it was a hiccup between with gmail and outlook? Because sending a test mail does work. Here is a the full mail that informed me about the error. The mail was sent from mail@gmail.com to mail@mydomain.com (Exchange). This is the mail system at host pve.home.arpa. I'm sorry...

nope, just run the exe. You do need a reboot though. And as always, I recommend taking a ZFS Snapshot before doing any major update, like this one.

Hi mario Sure, here you go smtp: gmail from-address mymail@gmail.com mailto-user root@pam mode tls server smtp.gmail.com username mymail@gmail.com matcher: default-matcher comment all notifications with gmail mode all target...

Not sure if I am misunderstanding something, or if there is a bug. I have a backup job. That job has "Default (Auto)" as notification mode. Send mail to mymail@mail.com and on failure only. Yesterday I had a backup error. I did get this mail: This is the mail system at host pve.home.arpa...

There is not technical limitation AFAIK, but it is just not very smart. The root issue is as already mentioned that you have data in blockstorage instead of files. (at least that is my guess with the limited information you provided). This comes with all the drawbacks of blockstorage. These...

Since we have no idea about your use case, it is hard to tell. I would seriously reconsider if you actually need shared storage. Because IMHO in most cases it is not worth the downsides. If migration does not have to be real time, you can also simply create a backup to a NFS destination and...

This is just my opinion: You should use RAW on top of ZFS. All local, no network shenanigans. You should not use (and I don't think it is even possible) use RAW over NFS, where the NFS is on top of ZFS. You should not use RAW over iSCSI, where the iSCSI is on top of ZFS. You should not use...

Yesterday I wasted way too much hours migrating some VMs from Windows 10 to Windows 11, since I ran into some obscure problems. Maybe this helps someone else, because I could not find good information on my specific problems in the forums nor on reddit. What was "special" about my migration...

I simply base that on the number of lines of code. At least openvpn is more insecure, simply because it is a bloated beast. But since we are hopefully working with 2FA, API tokens and we only allow connections from the static /56 or /48 prefix, it is pretty secure anyway.

Just a heads up, not sure if this applies to you too. Today I setup a remote PBS and forgot to open up the new IPv6 WAN rule on the remote firewall. Instead of a "could not connect to remote" or something like that error, I got a "permission denied" error. So what I am trying to say is, don't...

I could be very wrong, but this is how I understand file size / record size / compression in PBS: - Backups on the host are done in 4MB chunks. - With compression enabled by default, ZSTD might compress them a little bit. - With compression enabled by default on a PBS destination that uses...

Does PBS actually make use of atime? Or is it just inherited because of ZFS upstream? TrueNAS disables atime by default for performance reasons.

That makes it even worse by introducing another abstraction layer. No. Why should that be the case? So you want to move of the storage from PVE to a ZFS box and access it over NFS? So then the no copy on write happens on your PVE host but you still have copy on write twice, plus you added NFS...

Nutzt du kein LVM? Ansonsten funktioniert vielleicht eine offline Methode: https://pve.proxmox.com/wiki/Resize_disks#Online_for_Linux_Guests

Based on your questions asked, and not even describing a clear performance goal, I would also recommend you a partner. Or you get a system that is on the save side, meaning having at least the RAM amount you have know, CPU performance you have know and combine that with a ZFS 3 way SSD mirrors...

That is a long outdated and not very good to begin with rule. Just as the old and not very good rule "don't fill your pool over 80%". My problem with both rules is that they are way too general and ignoring the actual use case. For some use cases, the rules are way too strict, and for others...