-
|
This morning I was trying out the --force option of zfs-autobackup. Shortly after that I noticed my user could no longer log in to our Linux systems. On further inspection I discovered that most of the users homes dirs/datasets (on the zfs-autobackup source) had lost their correct UID/GID and many of the dirs had lost most of their contents too so I'm currently rolling them all back 24 hours hoping that they'll all be fixed. I can only presume it has been me testing zfs-autobackups I've been working on the presumption that zfs-autobackup's syncs only work one way, from the source to the destination and not both ways, is that correct? That is the only way I want syncs to work if it can be forced. I have also been presuming that the only change zfs-autobackup could ever make to the source would be to create or destroy its own snapshots. Most of the users home dirs were set to UID:GID root:root after my experimenting with --force instead of their own , correct user and group ID. After rolling back the correct UID/GID have been restored. I didn't see any extra errors when using --force (with --verbose) that I didn't see when I wasn't using force, the output of zfs-autobackup led me to believe everything was OK. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
|
Thankfully the rollback was successful and all the files and uids/gids seem to have been restored to as they were yesterday morning, which pretty much proves to me that the damage has been caused it the last 24 hours and the blame can very likely be attributed to me testing --force. It would seem that me running zfs-autobackup without --force didn't cause any problems but --force has issues. Have I been making any incorrect assumptions about zfs-autobackup? |
Beta Was this translation helpful? Give feedback.
-
|
The command I used on the destination machine that I believe caused my problems was: zfs-autobackup --force --strip-path=1 --keep-source=1d90d,1w12w --keep-target=1d90d,1w12w --zfs-compressed --ssh-source [email protected] asteria-homedirs letome zfs-backup v3.2, Ubuntu 22.04 on both source and destination. |
Beta Was this translation helpful? Give feedback.
-
|
yes, zfs-autobackup will never change stuff on the source side, the only change there is to thin out its own snapshots. the --force does only do stuff on the target. the problem was at the source? maybe you forgot the specify ssh-target while experimenting or something? every homedir is a zfs mount? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the problem occurred on the source machine. Thats good news about --force only working on the target if its working correctly but it doesn't explain why things got trashed. Every home dir has its own dataset and mount yes. |
Beta Was this translation helpful? Give feedback.
-
|
I suppose what needs to happen here is I need to try running zfs-autobackup again soon with --force as well as --debug and --verbose. If this happens again then we might be able to catch the problem. |
Beta Was this translation helpful? Give feedback.
-
|
probbbaly nothing happens, and you can never reproduce it and always keep wondering what happend :P |
Beta Was this translation helpful? Give feedback.
-
|
Most likely yes. |
Beta Was this translation helpful? Give feedback.
-
|
I tried --force again last night and its not caused any problems on my source this time so I dunno what caused that last time. With autobackup 3.2, I have to run |
Beta Was this translation helpful? Give feedback.
-
|
yes, see #112 |
Beta Was this translation helpful? Give feedback.
yes, zfs-autobackup will never change stuff on the source side, the only change there is to thin out its own snapshots.
the --force does only do stuff on the target.
the problem was at the source? maybe you forgot the specify ssh-target while experimenting or something?
every homedir is a zfs mount?