Does a 3 nodes cluster + a Qdevice, allows a single PVE host to continue running VMs?

[Johannes S]

Thank you, yes, I know about the single point of failure, I have local backups on each node as well (I do them manually), also planning to add a removable datastore in PBS with an external USB disk, and schedule a second backup job there

Like Udo B. said manual backups have room for error. The external USB sounds like a good idea though since PBS has now support for external datastores.

Another option might be to spin up a PBS vm in your two-node cluster, just as additional backup. This PBS would then sync the actual backups from your NAS. I would also do a regular vzdump of your vms (weekly, bi-weekly or monthly depending on available storage space) with proxmox native backup function so you still have a working backup to restore from even if your PBS installs get lost. The external USB would be a good place for it.

You might also want to run PBS on a vserver or save the vzdumps in a cloud storage (PBS doesn't support saving to them at the moment) to have an offsite backup. Another option might be to have a PBS at some friends or family members place or have not one but two external drives. One of them is placed on an offsite location (e.g. your office or some friends place) and you swap them regulary and you would still have a backup even if your place has damage from water or fire.

 

[VictorSTS]

and schedule a second backup job there

Just do a sync job from your main datastore to the USB drive. Doing two backup jobs to two different PBS storages invalidates drity-map every time, voiding one of the advantages of using PBS.

 

[Johannes S]

Just do a sync job from your main datastore to the USB drive. Doing two backup jobs to two different PBS storages invalidates drity-map every time, voiding one of the advantages of using PBS.

Good point. It would also have the advantage that already pruned data on the main datastore won't be synced to the USB drive.

 

[VictorSTS]

already pruned data on the main datastore won't be synced to the USB drive.

Ideally you should have two, independent, prune policies so deletes on the main datastore do not propagate automatically to the other(s). Think about human error, a bug, malware, etc removing backups on the primary datastore.

 

[Johannes S]

Ideally you should have two, independent, prune policies so deletes on the main datastore do not propagate automatically to the other(s). Think about human error, a bug, malware, etc removing backups on the primary datastore.

Of course but let's assume you a policy with thirty daily backups on your main datastore and seven on your external drive. Your sync job runs daily but a backup is created every hour. Then your sync job to the external drive would only contain the daily backups not the hourly ones (which depending on the usecase might actually be what you want or not) or am I missing something?

 

[VictorSTS]

Not sure if I understand this right, but makes no sense to have hourly backups if your prune policy only keeps one daily backup. Would you mind to elaborate with a detailed example?

 

[Johannes S]

Not sure if I understand this right, but makes no sense to have hourly backups if your prune policy only keeps one daily backup. Would you mind to elaborate with a detailed example?

I often to a backup before i changing something at the vms so I can restore them. But I don't need to keep them for a long time. For similiar reasons I keep 12 hourly backups per day. But I don't need them on my offsite PBS. Thus I first to a sync to another local namespace (called remote-sync) and prune this namespace to get rid of the hourly backups before syncing the remaining ones to the offsite PBS.

 

[VictorSTS]

Using an intermediate namespace is how I do similar tasks... sometimes, but not always: typically the amount of space used by those "expendable" snapshots is so low that is not worth the hassle and I simply use an adequate mount of "Last" and "Daily" numbers in the prune policy.

 

[LnxBil]

This is really a catch 22 case.

Thank you for that reference, I wan't aware of the term.