Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only the first backup in disklist is made #253

Open
ndias opened this issue Jan 31, 2024 · 4 comments
Open

Only the first backup in disklist is made #253

ndias opened this issue Jan 31, 2024 · 4 comments

Comments

@ndias
Copy link

ndias commented Jan 31, 2024

Because the issue #222 was closed and I can«t open again, and the suggest is to open a new issue.

The issue at @#222 is a bug that should be resolved, it's not true this

"Due to multiple DLE entries, amanda is using degraded mode for the backups. Using a holdingdisk is mandatory in degraded mode."

Like I wrote in the issue, if i use multiple DLEs and a physical TAPE the holdding disk is not necessary and amanda doesn't complain about not having an holding disk.

From the man pages ...
"The amanda.conf file may define one or more holding disks used as buffers to hold backup images before they are written to tape."

may ... not MUST so it's optional.

@ndias ndias changed the title amdump ignores diskname and uses the diskdevice Only the first backup in disklist is made Jan 31, 2024
@konidev20
Copy link

Hey @ndias,

We will check this out and see if there are any gaps in the documentation between 3.5.3 and 3.5.1. Thank you for your patience.

@tanstafel
Copy link

Just stumbled of the same issue. We upgraded from a CentOS 7 with amanda 3.3.3 to a Rocky9 with amanda 3.5.3 and our backup shows the same issue. We actually have a small holding disks to buffer some of the data from remote servers but most of the data to backup is already local. Now making the holdingdisk as large as the whole backup is ridiculous. This can't be right. Please provide a solution to this issue.

@tanstafel
Copy link

Just stumbled of the same issue. We upgraded from a CentOS 7 with amanda 3.3.3 to a Rocky9 with amanda 3.5.3 and our backup shows the same issue. We actually have a small holding disks to buffer some of the data from remote servers but most of the data to backup is already local. Now making the holdingdisk as large as the whole backup is ridiculous. This can't be right. Please provide a solution to this issue.

Ah, I made a mistake here. The DLEs that failed explicitly said "holdingdisk never". We did this because we did not want multiple parallel compressors (pigz) running which makes no real sense. For this I will find another solution or live with it. Sorry for the noise.

@tanstafel
Copy link

Just stumbled of the same issue. We upgraded from a CentOS 7 with amanda 3.3.3 to a Rocky9 with amanda 3.5.3 and our backup shows the same issue. We actually have a small holding disks to buffer some of the data from remote servers but most of the data to backup is already local. Now making the holdingdisk as large as the whole backup is ridiculous. This can't be right. Please provide a solution to this issue.

Ah, I made a mistake here. The DLEs that failed explicitly said "holdingdisk never". We did this because we did not want multiple parallel compressors (pigz) running which makes no real sense. For this I will find another solution or live with it. Sorry for the noise.

Spoke too soon: While removing the "holdingdisk never" is improved things - the large DLEs still do not work and complain with "out of holding space in degraded mode". So it looks like I really need a holding disk that fits the data of teh largest DLE. Most of this data is already present locally and it makes totally no sense that amanda copies this first to a holding disk and from there to the final destination. As I stated in my first post - this can't be right and there must be workable solution for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@ndias @konidev20 @tanstafel and others