Issue at image backup Ubuntu/Debian

fnu · October 17, 2022, 6:29pm

Hello, I’m testing urbackup since while to replace my existing solution for my family “business” asap. Cool stuff btw. thanks. Actually I’m testing urbackup part of infscape appliance (free) and yes, it raises some questions.

Let’s start with one strange behaviour, since I’m only interessted in image backups for Windows and also Linux. My prefered Linux distros are Debian & Ubuntu. All my test machines are setup in Hyper-V actually, also infscape.

First attempt, testing image backup with dattodb, a nightmare, does only compile until kernel 5.4.0, produces a lot errors laters and does fill “/” to 100% after a few tries with fairly large uncleaned “.dattodb…” & “.overlay…” files. So, disqualifiying behaviour …

I don’t like to operate LVM on my Linux machines, so “DM snapshots”. Setup fairly good and easy, let migrate my root volume to device manager handling on both VM, then first urbackup image backup try, does work, crazy fast. But I still find a left over file “.era-meta…” albeit just 2MB, shouldn’t been left.

So, both very first full image backup of my Ubuntu & Debian test VMs using dm snapshots did work properly. I can mount those images within urbackup webif and do a walk thru incl. test downloads.

Level	Time	Message
Info 16.10.22 16:08 Starting scheduled full image backup of volume "C:"...
Info 16.10.22 16:08 Basing image backup on last incremental or full image backup
Warnings 16.10.22 16:08 Error retrieving last image backup. Doing full image backup instead.
Info 16.10.22 16:09 Transferred 4.00587 GB - Average speed: 1.05995 GBit/s
Info 16.10.22 16:09 Time taken for backing up client ubutest: 1m 2s
Info 16.10.22 16:09 Backup succeeded

Level	Time	Message
Info 16.10.22 18:42 Starting scheduled full image backup of volume "C:"...
Info 16.10.22 18:42 Basing image backup on last incremental or full image backup
Warnings 16.10.22 18:42 Error retrieving last image backup. Doing full image backup instead.
Info 16.10.22 18:43 Transferred 3.02387 GB - Average speed: 1.0211 GBit/s
Info 16.10.22 18:43 Time taken for backing up client debtest: 52s
Info 16.10.22 18:43 Backup succeeded

Ok, what is then the issue? Both machines are listed as “not supported” for “image backup status” and won’t be backed up again, what ever I do.

So, how does that work, succesful first attempt, but marked not supported in infscape/urbackup WebIF?

Possible to set it to “Ok” manually?

And don’t worry, file backup is deactivated meanwhile for all machines.

Regards

fnu · October 18, 2022, 11:01am

Ok, the issue Linux image backup doesn’t run anymore seems to be solved. I defined volumes “ALL_NONUSB” in global image backup settings and it looks like, that doesn’t work for Linux. So after setting it back to “C” individually for both test VMs and a appliance restart, scheduler did run an incremental image backup as planned.

Level	Time	Message
Info 17.10.22 21:06 Starting scheduled incremental image backup of volume "C:"...
Info 17.10.22 21:06 Basing image backup on last incremental or full image backup
Info 17.10.22 21:06 Creating writable snapshot of previous image backup...
Info 17.10.22 21:07 Transferred 197.107 MB - Average speed: 55.9619 MBit/s
Info 17.10.22 21:07 Time taken for backing up client ubutest: 52s
Info 17.10.22 21:07 Backup succeeded

Level	Time	Message
Info 17.10.22 21:06 Starting scheduled incremental image backup of volume "C:"...
Info 17.10.22 21:06 Basing image backup on last incremental or full image backup
Info 17.10.22 21:06 Creating writable snapshot of previous image backup...
Info 17.10.22 21:07 Transferred 85.7562 MB - Average speed: 31.1674 MBit/s
Info 17.10.22 21:07 Time taken for backing up client debtest: 52s
Info 17.10.22 21:07 Backup succeeded

But still “Not support” in overview …

The Debian test VM shows again a 2MB “.era-meta…” file in “/”

The Ubuntu test VM shows on top of that “.era-meta…” file, a 5GB “.overlay…” file in “/”, and that cannot be deleted “operation not permitted”. So I guess, that file hangs kind of in an unsuccessful ended, so still running DM snapshot …

Let’s see if it get’s cleanup on next schedule tonight or it ends in a comparable situation on my “dattodb” tries, filling up “/” to 100% making system stop working basically …

fnu · October 18, 2022, 12:29pm

So, quick check of the related urbackup snapshots scripts, I found how to release that “.overlay…” file and could delete it then.

And as long there’s just one “.era-meta…” file left and maintained (2MB) on the machines, its ok for me. As long as snapshot cleanup will be reliable … means not filling “/” unnecessary.

uroni · October 18, 2022, 8:41pm

The appliance is currently still based on UrBackup 2.4.x and at such it doesn’t completely support 2.5.x including the Linux image backup (e.g. you have that not supported, and will have trouble restoring the image backup).

W.r.t. dm-snapshot: I had an issue where it caused the test VM to freeze… that’ll be fixed with the next version. The .era-meta file is used for changed block tracking. Do not delete the .overlay or other files without deleting the snapshots first. This can cause the file system to be corrupted.
Another problem is that kernel updates won’t work (you’ll have to reboot to not using dm-snapshot before kernel update). So I’m not entirely happy with this one.

fnu · October 19, 2022, 10:12am

Ouch, wasn’t aware of it, I just guessed it has the actual version. Since I like that appliance approach, I’m curious when the appliance might be based on 2.5.x … ?

Good to hear, great.

Yes, I’m good with it, it seems left one per day, size 2MB.

Can you explain that a little more, what might get corrupted? I just followed your DM snapshot cleanup script, “chattr -i …” and “rm …”?

So, even the appliance is taking perfect full/incemental images of my 2 Linux test VMs, I cannot restore them?

Thanks in advance.

Regards