NOT ENOUGH FREE DISK SPACE (can't make backup)

[trawglodyte]

UPDATE - I did wind up getting Pupsave Backup to make a backup, but not exactly sure why it did or why it didn't to begin with. @geo_c and @mikewalsh helped me figure out an easy manual method. Important details, must be from ext4 to ext4 and add <-arv> to your cp command to keep file permissions and attributes. Good idea to do this from a different puppy or live boot a Puppy iso, rather than copying the save file from the Puppy OS you are operating in. from terminal

Code: Select all

cp -arv <pathtoyoursavefile/nameofyoursavefile> <pathtowhereyouwanttocopyitismounted>

It's also a good idea to rename the copy, something that helps you remember like date or description of the state of your OS when you made the copy.

original post below

It seems as if I've seen this before. I'm in BookwormPup64_10.0.4, I nitpicked around getting desktop how I like it and installed my favorite apps. OBS Studio, Shotcut, Audacity, LibreOffice, Krita. Now I want to make a backup so I can come back to this point if I do something stupid. But when I try to make a backup, I get this...

Screenshot.png (25.52 KiB) Viewed 1198 times

There's no issue with space on the USB where the OS lives, or space in RAM. I did a regular save and rebooted a couple times, but still get this error when I try to make a backup. Any ideas?

[trawglodyte]

I did have one idea. I used fstab to mount partitions on my hard drive to folders (Documents, Downloads, Music, Pictures, Videos) at /root/Documents, /root/Downloads, etc.... Is it possible the backup is attempting to save everything from those partitions now?

[sonny]

I normally create a second partition using gParted after flashing the ISO with Rufus.

viewtopic.php?p=106712#p106712

under the title

Wanna go beyond 4GB in the same medium and/or with different file system?

[Clarity]

Hello @trawglodyte. Are you working with saving your sessions as a folder or as a file.

Long ago, I stopped ever saving my sessions as a file. As a folder, I have better visibility of what my Persistence drive has in space, making space-management simpler.

If you are currently using save-files instead of save-folders, know this: The developers foresaw providing save-folders to eliminate the issues they had been witnessing with members running into savefile issues like the one you report.

This post ONLY applied if you are using savefiles. Further, its your choice for saving sessions; no matter what this post is offering.

[bigpup]

The first window that opens when you select to run Pupsave Backup.

The save backup to: can be selected to be anyplace you want.
Only places that are already mounted will be select-able.

Make sure to select a location that is not in the save.

Any place in /mnt/home/ (top layer of the partition the frugal install is on) or on another partition or drive is good.

Example:
My backup is going in the directory the frugal install is in.

Screenshot(1).jpg (24.35 KiB) Viewed 1114 times

[bigpup]

I did have one idea. I used fstab to mount partitions on my hard drive to folders (Documents, Downloads, Music, Pictures, Videos) at /root/Documents, /root/Downloads, etc.... Is it possible the backup is attempting to save everything from those partitions now?

Maybe

What does the info at the bottom of the first page of Pupsave Backup show for required and available space?

[trawglodyte]

This video shows my problem more clearly. https://odysee.com/@trawg:3/pupsave-backup:d

I now don't think the problem is due to my fstab entries, but I did try removing the fstab entries and rebooting to make sure. That got me to what shows in the following video. https://odysee.com/@trawg:3/pupsave-backup-b:6

I couldn't find relevant info in the link from @sonny but is there a 4G limit? I did add some apps and the folder I keep BookwormPup64_10.0.4 on says it's 5.3G.

Screenshot(1).png (87.76 KiB) Viewed 1073 times

[williwaw]

.

[trawglodyte]

I tried a couple things that didn't work. There's a pretty easy manual work-around I showed in this video https://odysee.com/@trawg:3/pupsave-bak:6 if anyone has this issue. Just open the partition or USB your pup is on and copy the save file. Paste it somewhere else and rename it.

@bigpup The part of the window about the space issue is partially blocked off. This is all I can see.

Screenshot(5).png (21.29 KiB) Viewed 1036 times

[mikewalsh]

@trawglodyte :-

Personally, I don't remember ever using the Backup utility in all the years I've run Puppy. And I never save backups to the same partition - or drive - where my Puppy installs live.

I always make backups to a totally independent drive; in my case, a 500GB Seagate USB 3.0 external HDD, formatted to ext3. And - I shall probably get castigated for saying this - all I do is to drag the save-file or save-folder across to the Seagate, and drop it where I want to save it. That's it; just a simple copy/paste, drag'n'drop operation.

Needless to say, you don't do this while the 'save' in question is in use. Always do so from another Puppy/OS (unless you LIKE giving yourself grief!)

It's never failed me. Puppy is the only Linux OS I know of where you can pull a stunt like this (and it'll work).......as far as I'm aware. Just another benefit of Puppy's highly modular nature. But don't take my word for it; try it for yourself, if you don't believe me.

(Just because a utility for something exists, doesn't mean you HAVE to use it. The world won't fall apart if ya don't! As with so much in Linux, there's at least a dozen different ways of doing most things. This way has always worked for me.....though most long-term Linux veterans will look at you "gone out" if you have the audacity to suggest such a thing..! )

Mike.

[geo_c]

@trawglodyte :-

Personally, I don't remember ever using the Backup utility in all the years I've run Puppy. And I never save backups to the same partition - or drive - where my Puppy installs live.

I always make backups to a totally independent drive; in my case, a 500GB Seagate USB 3.0 external HDD, formatted to ext3. And - I shall probably get castigated for saying this - all I do is to drag the save-file or save-folder across to the Seagate, and drop it where I want to save it. That's it; just a simple copy/paste, drag'n'drop operation.

It's never failed me. Puppy is the only Linux OS I know of where you can pull a stunt like this (and it'll work).......as far as I'm aware. Just another benefit of Puppy's highly modular nature. But don't take my word for it; try it for yourself, if you don't believe me.

Mike.

Yes this is the beauty of the puppy setup. A savefile/savefolder can be copied anywhere and used, but I recommend doing that while NOT running from it! Though it probably works just fine, and @mikewalsh maybe that's how you do it. I think it's safer to close down the OS and copy it from another OS or while running from another save.

Using pupsave backup, shutdown isn't necessary at all and can be copied staightaway. I don't know what differences are in the backup, but I think you probably get the OS more or less in a shutdown state.

I have found it necessary when using F96 to copy a backup from one drive to another to use the cp -arv command from the terminal, because somehow copying from certain file managers breaks pulse audio. Maybe has something to do with attributes in links or permissions of components running as spot. But I never found that to be the case with fossapup64_9.5, which doesn't use pulseaudio of course.

[mikewalsh]

@geo_c :-

Ayup. Yes, I DID neglect to add that you should not do this from a running Puppy. That way lies corruption.....

Added this info to the above post. Good catch, mate.

(I'll always back-up the rest of the kennels from one Pup.....then boot into another to back-up this final one.)

Mike.

[trawglodyte]

@mikewalsh

That's what I would up doing. I just renamed the bakup "dpupbw64save-nvidia-apps-desktop" to remind myself I made the save after installing nvidia pet, my favorite apps, and tweaking the desktop how I like it.

IDK, I imagine if I changed hardware on my machine, modified my partition scheme, etc.... it might not work to restore. But I think that's true for any sort of backup, whether manual or with an app. There probably is a terminal command to insure you preserve permissions. I didn't do that.

[trawglodyte]

Yah, I'm getting tons of "failed to preserve ownership" errors, and when I dragged and dropped it I got something like 6,000 errors too that now I'm sure were failures to copy file attributes. I'm using cp with options like -p -a and --preserve=all none of which are helping.

Considering tarring the save file before moving it, but I don't know if that preserves attributes either. I also don't know if it failing to preserve attributes is all bad, I guess it depends on what they default to when it's not preserved?

I also got some videos moved out of the filesystem so my save file is 3.0G now, but still getting error from GUI about filesize limits. dunno..... I'm in Debian at the moment, let me reboot and go back to BookwormPup and try the GUI again. If filesize was the problem it shouldn't matter now.

[geo_c]

@mikewalsh

That's what I would up doing. I just renamed the bakup "dpupbw64save-nvidia-apps-desktop" to remind myself I made the save after installing nvidia pet, my favorite apps, and tweaking the desktop how I like it.

IDK, I imagine if I changed hardware on my machine, modified my partition scheme, etc.... it might not work to restore. But I think that's true for any sort of backup, whether manual or with an app. There probably is a terminal command to insure you preserve permissions. I didn't do that.

If you have certain configurations for certain hardware, for instance a dual montior setup, and you make a pupsave backup, and subsequently copy it to another machine with a single montior and boot, this won't break the OS. The OS will load the drivers for the hardware it finds, but your desktop icons that were spread across dual monitors would be forced onto the single monitor. Configurations like that, and wifi connections on a different network router would need to be reset etc...not a big deal once you get a save and transfer procedure down.

I run pupsave backup on my home computer, rename it to reflect what is inside, copy it to a USB drives and then copy to new machines. All of my machines are essentially running the same OS configuratioon because they are copied to each other. In this way I could take my most recent master savefolder from home and copy it to my machine at work, boot it up with the new savefolder, configure the network and monitors, (maybe soundcard choices and other particulars) and do a backup save from the work machine. I copy that work save to USB and bring it back home and copy it to the home computer. Now my savefolder has configurations for both networks. When I boot it it will find the right network automatically since both are saved, depending on which network manager is installed. Older pups may require switching manually.

It's why I use puppy and never have bothered with mainstream full install distributions. Puppy is portable in the trues sense of the word. Of course you could just boot off USB all the time if you like, and never copy the savefolder. But I'm a bit of a stickler when it comes to having backups everywhere and on different media and in different locations.

For instance, I just recently began to delete a folder of a KLV-airedale install from my USB stick, only I wasn't watching closely and was actually deleting the OS I was currently running from my hard drive. Not just the save, the entire directory of system files. CRAP! Not to worry though. I have that OS copied on three other USB hardrives and 4 laptops. So I shutdown immediately and booted into another puppy OS, plugged in another USB drive and put it back the way it was.

I don't think you could pull that off with a full install Arch.

[geo_c]

Yah, I'm getting tons of "failed to preserve ownership" errors, and when I dragged and dropped it I got something like 6,000 errors too that now I'm sure were failures to copy file attributes. I'm using cp with options like -p -a and --preserve=all none of which are helping.

Considering tarring the save file before moving it, but I don't know if that preserves attributes either. I also don't know if it failing to preserve attributes is all bad, I guess it depends on what they default to when it's not preserved?

I also got some videos moved out of the filesystem so my save file is 3.0G now, but still getting error from GUI about filesize limits. dunno..... I'm in Debian at the moment, let me reboot and go back to BookwormPup and try the GUI again. If filesize was the problem it shouldn't matter now.

Hmm, are you copying from an ext formatted drive to a an ext formatted drive, preferrably ext4? Or it may be Debian doesn't want to copy with root permissions.

edit: I always use cp -arv from a puppy-linuxOS run-as-root setup and it always works, but my partitons are all ext4.

[trawglodyte]

Hmm, are you copying from an ext formatted drive to a an ext formatted drive, preferrably ext4?

That might be the problem. I was copying from a USB formatted ext4, but to a USB formatted exfat. When I booted back into BookwormPup64_10.0.4 the GUI worked for me and I made a backup in the default place. I'm still really confused why it worked and didn't before though. My only guess is that I had a backup already when I tried before, and this time I had that backup deleted. But I really don't know.

Another source of confusion is I moved videos and other files off the file directory and onto other partitions, I thought I got my save file down to about 3G, when I looked at properties from Debian I think that's what it said. But when I did the backup here it still said 4.4G. dunno why.

[wizard]

You can drag and drop the save file/folder you're using IF you are in pupmode 13, but as @geo_c pointed out if it's a folder you may get copy errors.

Personally I just right click a Puppy save folder and use Packit (or some other archiver) to compress it and then move that to wherever you want including NTFS partitions. Again, you can do it live in pupmode 13 or of course, reboot without a save and do it.

wizard

[trawglodyte]

@geo_c I just tried it over, this time from BookwormPup64_10.0.4 (I know there was some concern about the operating system it's from, but that file should be out of the filesystem and pupmode 13 I'm in RAM and it's on my USB) I mean, dunno, not a bad rule of thumb to boot a live iso to do it or something, but I thought it was okay so I tried it from BookwormPup.

Anyway, the important part is this time it was from my ext4 USB and to an ext4 partition on my hard drive using <cp -arv> as you suggested. It was blazing fast with no error messages. thank you!!

[trawglodyte]

Personally I just right click a Puppy save folder and use Packit (or some other archiver) to compress it and then move that to wherever you want including NTFS partitions.

Okay, so I think what you're telling me is compressing a folder maintains the file attributes and permissions? Then you can move it around, but when you put it back and extract the permissions and attributes will be preserved? I was wondering about that.

[wizard]

@trawglodyte

Okay, so I think what you're telling me is compressing a folder maintains the file attributes and permissions? Then you can move it around, but when you put it back and extract the permissions and attributes will be preserved? I was wondering about that.

Yes

wizard

[mikeslr]

trawglodyte, I don't use the backup program. With all my Puppys including Bookworm what I do is boot pfix=ram. [Copying a SaveFile or SaveFolder while it's in use will generate errors. The backup program is supposed to avoid this. But copying a SaveFile/Folder NOT in use always does].

Having booted pfix=ram, I right-click the file/folder, Select Duplicate and give the 'Duplicate' a unique name: e.g. dpupbw64-Jan21(.sfs if a SaveFile) vs. dpupbw64-Jan01(.sfs if a SaveFile).

Left in the location next to the original, on boot-up Puppy will interrupt booting and wait until I choose which Save to use or none. But while not in use it can be moved anywhere. Or compressed using Menu>Utilities>packit.

[geo_c]

@trawglodyte

Okay, so I think what you're telling me is compressing a folder maintains the file attributes and permissions? Then you can move it around, but when you put it back and extract the permissions and attributes will be preserved? I was wondering about that.

Yes

wizard

Well wait a minute, it will maintain the attributes and permissions ONLY on a linux (ext) formatted partition, unless NTFS has changed since I last used it 4 years ago.

I'm pretty sure the reason the copy of a savefolder works now is because you changed to ext4 for the copy target.

And you made a comment about copying from the operating system, or some operating system, but I'm not sure which concern you were referencing. What I said earlier about copying your running system is explained below:

You boot up BookwormPup64_10.0.4 and it loads the savefolder, now you're running from that save folder. There's nothing stopping you from going to the directory the save folder is located and running a copy command on it while you're running from it, BUT, I don't think it's advisable. (edit: as I see @wizard reiterated.)

HOWEVER, if while still in BookwormPup64 you use pupsave-backup and make a backup save, now you can stay running in the BookwormPup save instance you booted into and made the backup with, and then use the cp -arv command to copy that backup anywhere you like, as long as it's a partition that can retain linux permissions and attriibutes etc.

[wizard]

@geo_c

Well wait a minute, it will maintain the attributes and permissions ONLY on a linux (ext) formatted partition, unless NTFS has changed since I last used it 4 years ago

True, except in this case we're talking about a Puppy folder that's inside a compressed container. The container doesn't care about the file system where it's stored.

wizard

[geo_c]

@geo_c

Well wait a minute, it will maintain the attributes and permissions ONLY on a linux (ext) formatted partition, unless NTFS has changed since I last used it 4 years ago

True, except in this case we're talking about a Puppy folder that's inside a compressed container. The container doesn't care about the file system where it's stored.

wizard

Yes, but to be clear he was asking about whether uncompressing it would still retain attributes, so if he uncompresses on somekind of exfat/NTFS then that's where it fails.

[wizard]

@geo_c

Yes, but to be clear he was asking about whether uncompressing it would still retain attributes, so if he uncompresses on somekind of exfat/NTFS then that's where it fails.

You are correct, the compressed file can be stored on any format partition, but it must only be unpacked on a Linux ext partition.

wizard

[trawglodyte]

And you made a comment about copying from the operating system, or some operating system, but I'm not sure which concern you were referencing. What I said earlier about copying your running system is explained below:

You boot up BookwormPup64_10.0.4 and it loads the savefolder, now you're running from that save folder. There's nothing stopping you from going to the directory the save folder is located and running a copy command on it while you're running from it, BUT, I don't think it's advisable. (edit: as I see @wizard reiterated.)

Yes, this is what I was talking about, and something I've been trying to wrap my head around lately. The general rule would certainly be you don't want to mess with something that you're operating from. But I'm pretty sure with pupmode 13, you aren't operating from that savefile. It loads into RAM on startup and you're operating from a copy of it in RAM. The savefile is sitting on your partition doing nothing until you do another pupsave.

It worked for me this time to copy the savefile on disk from the OS in pupmode13 that loaded into RAM from the same savefile, but that isn't proof that it will always work or that it's a good idea.

The method you described of booting from another Linux with same "root" permission structure or even a live .iso or something is probably the surest way to do it.

[williwaw]

The method you described of booting from another Linux with same "root" permission structure or even a live .iso or something is probably the surest way to do it.

do you have more than one save folder in the storage directory? If there were more than one, you would get a choice at boot time, and one of the choices would be "0" or booting without any save ie "ram".

if you do not have an additional savefolder, just go to the storage directory and create a directory with the name
dpupsave-0, or anything you choose after the -. (bookworm is looking for the "dpupsave" preceding to - to see it as an additional save which is required to make the boot-time menu appear.)

[geo_c]

Yes, this is what I was talking about, and something I've been trying to wrap my head around lately. The general rule would certainly be you don't want to mess with something that you're operating from. But I'm pretty sure with pupmode 13, you aren't operating from that savefile. It loads into RAM on startup and you're operating from a copy of it in RAM. The savefile is sitting on your partition doing nothing until you do another pupsave.

Yes you are correct.

If you're running from a savefile, and it's loaded into ram, and you write changes to it using the "save" button, then it's safe to copy that file from a running system. In the case of the save folder, most of the time it's simply mounted and being written to on the fly.

So that's one of the advantages of the savefile. It's possible to run from a savefolder in the pupmode that doesn't write on the fly. (I can never remember the numbers, because I never run that way -- always I'm working from an uncompressed savefolder in realtime.)

There are lot of ways to run puppies.

[trawglodyte]

@williwaw Easier for me to show than tell you to answer your question >>>https://disk.yandex.com/i/beXuo_jTbM9g_Q