Search results

one reason to NOT install the PBS on the PVE. Reading that I understood it to be a PBS that is close to the S3 storage. Yes it'll be slow, so my advoce would be to NOT use it for the actual PBS of first backup, but rather a PBS that is synchronizing the already backed up stuff, as a DR/failover...

Why do I keep missing that --debug option when I hve LXC failures :D

When/if you run ZFS with compression enabled, the zeroes are "compacted".. rather should be :D

Consider shutting down all apps, like the SQL server, and retry the sdelete -z Things like SQL could be the cause of lots of file writes which will "consume" storage if they aren't TRIM/zeroed

What I'd want to do in your situation (having had funs with virtioblock in the past without TRIM support, and having had to do similar): Attach a virtio-scsi device (enabling SSD & TRIM/etc. on the device) to the windows VM, copy the files of the current windows drives, and swap the drives...

known not to necessarily chose/use the best options for the underlying hardware, just the most common expected optimized values, so you need to know that yourself and check/tune accordingly. Especially newer SSD/NVMes you want ashift=13 (not 12 as in your case, good for 4k drives) else you have...

the command that is actually the one I believe is *needed*: reason: the writing of ZEROES, not just a TRIM command, as the values (especially the 1.13 compressratio) indicates that there are data in the "empty/deleted" portions of the VM's disk (like when you've done a defrag like above) and...

so no snapshots, which leaves the other possibility, that the disk layout might be a problem for some reason(s) perhaps related to ashift and volume settings. output of zfs get all tank/vm-200-disk-3 and zpool get all tank ?

*I* haven't yet tested/used it, so use at own risk(s), but make sure you do have your backups in place

YMMV as I see it still as beta and not battle/prod tested ;)

This makes it sound like you might have some snapshots still hanging around of that disk/image. please provide a `zfs list tank -t all | grep -i vm-200-disk-3` output, yes, it'll be long/etc. but would have the info to confirm/deny my suspicions a) ALWAYS enable compression on the ZFS - at...

yeah, the PCI/bus/etc. routing changes and that does mess up an already installed windows... should be doing it from the get go to install on SCSI virtio else you'll have that fun

hmmm... I wonder if you haven't had a once off event that got "fixed" ?? check/.report on the SMART values for those two HDDs you are complaining is failing...

nope, the setup is like a "stipe" from the moment you've attached the 2nd vdev (that being raidz1-1) and that means that if a vdev fails, ALL the data in the zpool is basically... gone (safe for your backups). In short, the zpool will balance to an extend, the data, so that (on average) both...

depending on your requirements, you could still sync, but for example only leave the last 2 or so on those with limited storage

No, it's the drives

replace with CMR drives? Hendrik's rules of computing: 1) Make a backup 2) Make *ANOTHER* backup 2b) At least one backup *off* provider (ie. a totally different DC/owner/etc.) 3) *CHECK* those backups Sorry, but it looks like those drives aren't in a good state w.r.t. ZFS.

Anybody arund here doing actual backups of the MinIO storage? I've contemplated using PVE->PBS backups of the nodes (currently I deploy using LXCs) but I'm concerned w.r.t. the sequential nature of the node backups. Which then brings me to the rclone mount type backups, ie. mount the bucket...

I've found the namespaces... not that "great" (though, I am using them in some cases), and have opted to rather do separate datastores for my "DCs"/clusters, even when on the same ZFS pool, at least I get better indications on the storage usage for each DC (which you won't see "Easily" in PBS...

seems like that might be the clue that you are using SMR and not CMR drives.