Backup of partition larger than local tmp and scratch space

[antunbalaz]

Hi,

I am using mondorescue for some time without any problems for backups and replication of local linux machines, thank you very much! However, now that the time has come to backup the laptop of my boss, problem appeared :(

I think I know what is causing it: I am trying to backup several partitions with the overall data size of approx. 80 GB to an NFS mount, but locally there is just 9 GB for scratch and tmp, and it seems that mondorescue wrongly checks if the partition on which tmp and scratch space are has enough space to store the whole amount of data that is being backed up.

Details: laptop has windows NTFS partition of 75 GB, and SuSE linux is installed on the rest of HDD, with 9 GB of empty space on Linux. Backup is done to an NFS mount. If windows partition is not backed up, no problems (i.e. small linux partition can be backed up successfully). If windows partition is included (-x /dev/sda2), I get "/dev/sda2: no such file" after I see in the log file that the number of slices is correctly calculated for /dev/sda2. This is misleading message and should be fixed (not enough space is more appropriate, although also not correct).

However, if I set scratch (-S) and tmp (-T) directory to be on the NFS mount (the same used for storing the backup iso images), then everything works, since on NFS mount there is enough space (200 GB+), wile on the local disk there is just 9 GB of free space. Of course, this is _very_ slow (15+ hours estimated), and in practice not feasible.

Now, I have verified that (with the size of iso images not specified, defaulting to CD size) tmp directory on NFS mount never grows over 150-170 MB, and scratch directory on NFS mount never over 650 MB (of course), which means that local scratch and tmp can be used easily, but for some reason mondorescue fails to realize that and gives up (this happens after backup of linux partitions is finished, at the start of the backup of windows partition as biggiefile).

Do you have any ideas how to easily fix this? Versions used:

mondo-2.2.4-1.suse10.2.i586.rpm mindi-busybox-1.2.2-3.suse10.2.i586.rpm mindi-1.2.4-1.suse10.2.i586.rpm

Thanks, Antun Balaz antun@…

[antunbalaz]

mondoarchive log file

[Bruno Cornec]

Did you try doing: mkdir /mondo and calling mondoarchive with -S /mondo -T /mondo ?

From your log, I think you let mondo chose what it wants no ? However the error is in that code:

if (!(fin = fopen(file_to_openin, "r"))) {

log_OS_error("Unable to openin biggie_filename"); sprintf(tmp, "Cannot archive bigfile '%s': not found",

biggie_filename);

[antunbalaz]

Hi Bruno,

The point is that locally there is not enough space, so setting -S and -T to some local directory did not help - same error. As I mentioned in the original post, if I set scratch and tmp space (with -S and -T) to be on an NFS mount (where there is enough space), mondo works, but unacceptable slow.

So, the problem is in checking - mondo checks if temp and scratch have enough space, but assumes that you will put everything there, while in fact just the size of the chosen media is required to be available...

Thanks, Antun

[Bruno Cornec]

The problem seems to come from that code:

mr_msg(1, "Opening in %s; slicing it and writing to CD/tape",

file_to_openin);

if (!(fin = fopen(file_to_openin, "r"))) {

log_OS_error("Unable to openin biggie_filename"); mr_asprintf(&tmp, "Cannot archive bigfile '%s': not found",

biggie_filename);

log_to_screen(tmp); mr_free(tmp); return (1);

}

Looking at that + the ntfsclone call just before, and the size of your device, I think there is a synchronization issue between the forked ntfsclone and the process trying to read a file which doesn't exist yet. Andree any idea on this ?

[LUPENunez32]

According to my analysis, billions of people in the world get the <a href="​http://bestfinance-blog.com/topics/home-loans">home loans</a> from various creditors. So, there's a good possibility to receive a term loan in all countries.